Robert Roessler: > I found one "interesting" use of [a] ctrlID in PlatWin.cxx(1644): > > reinterpret_cast<HMENU>(ctrlID), > > which clearly expects ctrlID to be able to hold a handle, which have > been pointers for quite a while now.
That one is for autocompletion lists so doesn't affect Scintilla notifications but it does point to one of the uglier aspects of IDs. I originally started writing an aside to a previous mail but thought there'd be too much snickering from the Linux guys. On Windows, the same slot is used to hold the control ID and the menu handle, and this is normally OK as the sorts of controls you want to access by IDs like edit texts or buttons are unlikely to have menus. You have to understand this and not try to pass an ID in the hMenu parameter of CreateWindow when the window does display a menu. Last year I worked on porting a set of OS/2 applications to Windows and on OS/2 there are separate menu and ID slots. Even worse, the code would want to do things like create a window with an ID and without a menu and then flick its menu flag. > I get 16 hits on "ctrlID" uses: 6 in src, 1 in include, and the rest > [as expected] in win32 and gtk. My quick take is that, yes, they all > need to deal with the "new" ctrlID... if you could take a look at > these and verify that they are indeed involved, then I will do the > actual edits and test builds (well, my normal "vcbuild" stuff for > Windows XP and my GTK widget build of Scintilla, anyway). There are some problems here. In the system headers, GetDlgCtrlID returns an int which means it will truncate on Win64 although we can retrieve the correct information through GetWindowLongPtr(w, GWLP_ID). For the EN_CHANGE, EN_SETFOCUS, and EN_KILLFOCUS notifications, the ID is packed along with the notification type into a WPARAM assuming they are only 16 bits! Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
