On Apr 13, 2005, at 15:01, Tim Rowledge wrote:
So let's just drop the no longer needed macro.
Sorry -- my confusion. The macro is still in there. (To support non-inlined compilation I undef it in my sqPlatformSpecific.h. A more compatible approach would be to test for SQ_VI_BYTES_PER_WORD defined and undef the macro conditionally. I took it out initially, then put it back with the sqPlatSpec undef before comitting.) The only issue remaining is the extra field in keyboard events to send a 32-bit wide char value.
The remaining confusion (and roll-back to 32-bit-only code) seems to have come from John's implementation of SVN which happily committed a stale sq.h against a newer version in the repository. John fixed this and I'm about to commit the 1-liner for keyboard events and then we should be up to date again and compiling cleanly in 64-bit mode.
I guess the lesson here is: please (please [please]), before committing anything to the trunk, make sure you are not committing a modified stale source file against a newer version in the repository. FWIW (this won't fix procedural problems with GUI-based interfaces ;-) here's what I do before committing anything (to any repo, anywhere, for any project):
- run 'svn st -u' in the dir I'm committing - if any files have '*' before them, they've changed in the repo since I last updated + move the local version aside (deleting the original name) + update just the conflicting file with 'svn update originalName.whatever', to get a fresh copy from the repo + diff the updated original version against my modified copy + copy (or propagated changes from) the new version back into the original version - svn commit -m 'hopefully without inadvertent roll-back'
If a GUI-based SVN cannot support this kind of caution by immitating the 'svn st -u' step then please be extra careful before committing (or just open a terminal window and run the status check manually ;-).
Thanks! Ian