Neil Hodgson wrote:
Robert Roessler:
...
If so, does this mean that the GTK widget interface needs to be
adjusted also? It matters to my OCaml GTK widget wrapper for
Scintilla, as I would have to change the wrapped representation of
this field to a type which is likely to track POINTER sizes rather
than one which tracks INTEGER sizes.
Yes, there are potential issues like this which is why I mentioned
it. For Windows, this change has to be done as otherwise, generic NMHDR
code would choke on Scintilla's version. On GTK+ it is less certain. My
decision (which can be revoked following sufficient protest) was based
on the current scarcity of 64 bit use versus the long term cost of
supporting different code on different environments.
The change could be extended further to say that this field may be
used for pointers and modify scintilla_set_id to take a uptr_t.
There is indeed a fair amount of "ripple" here - but if [sort of]
supporting 64-bit is getting rolling, then yeah, it has to happen.
So I looked at scintilla_set_id... and then at the broader use of
"ctrlID" - and the ripple from that.
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.
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).
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
