Robert Roessler:
I am not sure what is going on exactly - this field is [apparently] used as the GTK widget "id" value, which is clearly some kind of an int (signed or otherwise). But the [already committed] change seems incompatible with this usage.
It is still compatible with being used as an int holding control ID values. On Windows, controls can be addressed by their ID as well as their handle. For Win64 Microsoft decided to make the ID value be 64 bits. It is 64 bits when calling CreateWindow and is stored in a long ptr slot GWLP_ID. If you are using small integer IDs as is common then the widening should not be a problem. I expect a reason for Microsoft to widen this field is that some applications may be storing pointers in it. Once the slot is 64 bits then all downstream use such as NMHDR have to be widened.
Reviewing the recent ("64-bit fixes") thread dealing with this, it seems that Neil is maintaining [I think] that the relevant PSDK header file has changed the *actual* idFrom declaration from UINT to UINT_PTR, without Microsoft changing the *documented* description of this structure.
Yes, and the SDK changes have been there for quite some time: the Borland 5.5 headers are from mid 2000 and have this change. The Mingw headers which are unlicensed and created through supposedly clean room techniques don't.
Does this sum things up? I find no mention of this change when googling (other than our own Scintilla thread)... did Microsoft really intend this [fairly sweeping change] to be unconditionally applied to all environments?
The whole 64 bit change is reasonably well documented but some pieces haven't been updated. The old definition is still in the online MSDN so its not just that I'm using an old installation. Searching the net finds hits from the expected projects: WINE and Tk patch lists.
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.
Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
