| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #111
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | X11 |
|---|
| Summary: | environment DISPLAY is assigned later then using it in XOpenDisplay |
|---|
| Version: | 1.1.4rc1 |
|---|
| Created By: | guenther.striges |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | 1.1.4rc2 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | guenther.striges
01:23 Jul 22, 2003 |
| when the option -display is given the environment variable DISPLAY is correctly set- but too late, the toolkit opens the Display earlier then setting DISPLAY,and therefore may fail to open it,
apply's to X11 only | |
| |
| #2 | mike
19:04 Jul 28, 2003 |
| Please post a short example program that demonstrates this problem; many calls require the display to be opened, so any calls to FLTK functions before the arguments are processed can cause the wrong display to be used. | |
| |
| #3 | guenther.striges
06:42 Jul 29, 2003 |
| Please see the file message.c, forget the getopt-stuff, this is done to work around the problem described,
whenever the call to top->show() is executed FLTK says
'Can't open display:<nothing>', because DISPLAY is empty (I call messager from inittab), I tried to call top->show() with args (-display :0.0) with some test-printf's in FLTK and it shows that it first opens the display and then puts the DISPLAY into the environment ... (yes it does !) | |
| |
| #4 | mike
08:09 Jul 29, 2003 |
| OK, thanks, found and fixed the problem in Fl_Window::show()... | |
[ Return to Bugs & Features ]
|
| |
