| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #848
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: | WIN32 |
Summary: | Fl_Window::xclass() as documented does nothing in win32 environment |
Version: | 1.1-current |
Created By: | sdchen |
Assigned To: | matt |
Fix Version: | 1.1.7 (SVN: v4455) |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | sdchen 13:58 May 09, 2005 |
| According to the 1.1.x online documentation, the Fl_Window::xclass() method is supposed to let the programmer set the class name of the created window [via the Win32 WNDCLASSEX structure and RegisterClassEx() function]. However, the code in Fl_win32.cxx of 1.1.x and win/x.cxx of 1.2 hardcodes the class name to be "FLTK". It looks like the code to use xclass() was put in, but is currently commented out.
One use of Fl_Window::xclass() as advertised is to set the window's class name to a unique name (e.g. "Test123"). A call to the win32 FindWindowEx(NULL, NULL, "Test123", NULL) would return a handle to this window, if it was created, or NULL if it was not. This behavior can be used to test whether an instance of the application is currently running or not.
I have tested this functionality successfully by uncommenting the aforementioned code in Fl_win32.cxx and rebuilding FLTK 1.1.6. However, without knowing why the original code was commented out as it was, I will not make a general request to uncomment it in future releases...
Current code (v1.1.6, v1.2):
const char* class_name = /*w->xclass(); if (!class_name) class_name =*/ "FLTK"; // create a "FLTK" WNDCLASS
Code with comment removed:
const char* class_name = w->xclass(); if (!class_name) class_name = "FLTK"; // create a "FLTK" WNDCLASS | |
|
#2 | mike 06:07 May 16, 2005 |
| [From Bill]
On Tuesday 10 May 2005 07:52 am, you wrote:
>> According to "svn blame", Bill commented this code out in r774 >> after 1.0.6 was released. The specific note is: >> >> 2. Fl_win32 ignores the value of window->xclass(). This seemed >> to cause problems when windows had different xclass() in the >> same app and did not have any useful effect on windows. This >> value is changed to set the icon of the app on X. >> >> Bill, do you remember what the problem was on WIN32? >> >> My preference is to restore the xclass() code on WIN32, and if there >> are side-effects for using multiple xclass's then we should stick >> with the first shown window's xclass, with the default xclass being >> "FLTK".
I don't remember what the problem was. I think maybe the problem was with creating more than one class with the same name and the code by default created many "fltk" ones. Using the first window's xclass as the Windows class sounds acceptable. | |
|
#3 | matt 12:08 Jul 24, 2005 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |