Robert Roessler:
> Nonetheless, you have elected to join them on this trek - so how much
> (or little) will we need to do?
I'm feeling like fudging the whole issue as "too much trouble".
Perhaps with a note in the documentation saying that you should only
use 16 bit ID values and not pointers. The struct does need to change
on Windows at least.
> 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).
There is an additional problem on GTK+ where both the Scintilla
signals, command and notify, are marshaled as (int, pointer) with the
int containing the ID or for EN_*, an int combining the ID with a
code. Changing marshaling is more intrusive as the function signature
in client code must change. For example, SciTE::NotifySignal would
have to change.
void SciTEGTK::NotifySignal(GtkWidget *, gint /*wParam*/, gpointer
lParam, SciTEGTK *scitew) {
to
void SciTEGTK::NotifySignal(GtkWidget *, gpointer /*wParam*/, gpointer
lParam, SciTEGTK *scitew) {
or similar. I don't know if glib has a marshaling equivalent to
uptr_t and would be a bit worried that declaring the first signal
argument as a pointer could lead to code checking that it really is a
pointer through the equivalent of IsBadReadPtr.
Neil
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
