Neil Hodgson wrote:
Robert Roessler:
...
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!
Well, yes... knowing that control "id" values are often treated as /
assumed to be ints (or shorter), is one of the reasons I have been a
bit skeptical of this change - so it seemed a bit bizarre that
Microsoft would even start down this road.
Nonetheless, you have elected to join them on this trek - so how much
(or little) will we need to do?
For the purposes of the GTK widget IDs, we *could* just leave them as
ints, and accept that when running on an architecture with 64-bit
pointers, we are only using the low 32 bits in this NMHDR field when
transmitting widget IDs. I suppose. Actually, you sort of implied
this earlier (I think).
OTOH, Windows ["native"] apps using Scintilla could be in the position
of actually using this *as* a control ID (in the sense of receiving it
in one Windows call and needing to use it in another)... they will
presumably need to follow the ULONG_PTR convention more closely.
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
