Re: [fltk.development] RFC: win32 Fl_Window::icon()vs Fl_Window::xclass()
Just as a side note; I was using the VS7 (ancient) compiler to do the above tests (I still use VS7 for building my commercial apps), but double checked in VS 2010 as well. Both compilers seemed consistent, so if MS did change something, it would've predated VS7. (Entirely possible, as our docs are much older than that, lol) Yes, indeed. I'm thinking, if MS did change something, it likely is not in the compiler toolchain, but in some system lib or DLL...? So, to track this down, we'd need a bunch of systems with different Windows versions, with different service packs applied, to see if we could see where the behaviour changed... Or, you know, just not. :-) Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: win32 Fl_Window::icon() vs Fl_Window::xclass()
I just noticed a few things on win32: [1] If an app sets the window's xclass() *before* it sets the icon(), the icon won't show up in the title bar. Hmm, odd. I did not know that... We have kinda changed the way the xclass is done, more recently than the icon stuff was done. That may be relevant? [2] In the win32 osissues page, under Setting the Icon of a Window there's a NOTE: that reads: You must call Fl_Window::show(int argc, char** argv) for the icon to be used. The Fl_Window::show() method does not bind the icon to the window. This no longer seems to be true, at least empirically. And I think Albrecht once commented he noticed this as well, and wondered aloud if this comment was outdated, if ever true. ISTR it *was* true at some point (though may date back to NT4 or early XP) so things may well have changed. Indeed, the changes to the way we handle xclass in WIN32 might even have had an effect here? Is [1] known behavior that should be documented? Is [2] really obsolete and should be removed, or are the empirical observations simply undefined behaviour? Dunno! Regarding [1], it was driving me nuts today, so if it really is order dependent, we should document to prevent insanity. Yup! In fact, I think when the following three calls are being used together, they have to appear in this specific order or they won't work right.. at least on win32 anyway: 1) icon() -- if used with xclass(), this must be first 2) xclass() -- if used with icon(), this must come after icon() 3) show() -- if any of the above are used, this must come last I guess the code has diverged a bit from the docs, or MS has changed things whilst we were nto looking... Also, I do think we should look again at STR #2816, as that improves the icon handling on *all* platforms anyway, and may be useful here. Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: win32 Fl_Window::icon()vs Fl_Window::xclass()
On 04/16/13 01:57, MacArthur, Ian (Selex ES, UK) wrote: In fact, I think when the following three calls are being used together, they have to appear in this specific order or they won't work right.. at least on win32 anyway: 1) icon() -- if used with xclass(), this must be first 2) xclass() -- if used with icon(), this must come after icon() 3) show() -- if any of the above are used, this must come last I guess the code has diverged a bit from the docs, or MS has changed things whilst we were not looking... Just as a side note; I was using the VS7 (ancient) compiler to do the above tests (I still use VS7 for building my commercial apps), but double checked in VS 2010 as well. Both compilers seemed consistent, so if MS did change something, it would've predated VS7. (Entirely possible, as our docs are much older than that, lol) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] RFC: win32 Fl_Window::icon() vs Fl_Window::xclass()
I just noticed a few things on win32: [1] If an app sets the window's xclass() *before* it sets the icon(), the icon won't show up in the title bar. [2] In the win32 osissues page, under Setting the Icon of a Window there's a NOTE: that reads: You must call Fl_Window::show(int argc, char** argv) for the icon to be used. The Fl_Window::show() method does not bind the icon to the window. This no longer seems to be true, at least empirically. And I think Albrecht once commented he noticed this as well, and wondered aloud if this comment was outdated, if ever true. Is [1] known behavior that should be documented? Is [2] really obsolete and should be removed, or are the empirical observations simply undefined behavior? Regarding [1], it was driving me nuts today, so if it really is order dependent, we should document to prevent insanity. In fact, I think when the following three calls are being used together, they have to appear in this specific order or they won't work right.. at least on win32 anyway: 1) icon() -- if used with xclass(), this must be first 2) xclass() -- if used with icon(), this must come after icon() 3) show() -- if any of the above are used, this must come last ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
