I just had great success migrating some of my code from using oldwinapi to using the newer winm module. Much applause for the author of winim ! ! ! ! ! ! ! !
Mostly it was changing identifiers back to their originals as published by msdn.
Also since my project does not use unicode (nor utf8) in any way, I needed to compile using the nim option:
-d:winascii
To get the result to link edit when cross compiling from Linux to MS binary, I changed a line (about #11) in the ---/.nimble/pkgs/winim-2.5.1/winim/inc winim package (after you install it) from:
const winimPrivateDir = parentDir(currentSourcePath()) & "/../lib/"
to:
const winimPrivateDir = parentDir(currentSourcePath()) & r"..lib"
Below is a list of the changes I had to make (to MY sources) during the migration. This no doubt needs to be extended by other programmer's experiences. Please feel free to do so.
oldwinapi winim module comment
------------- ------------- --------------- ---------------------
LPITEMIDLIST LPCITEMIDLIST inc/objbase.nim
HINST HINSTANCE inc/windef.nim
WINUINT UINT inc/windef.nim
TopLeft.x left inc/windef.nim IN RECT
TopLeft.y top inc/windef.nim IN RECT
BottomRight.x right inc/windef.nim IN RECT
BottomRight.y bottom inc/windef.nim IN RECT
TOPENFILENAME OPENFILENAME inc/commdlg.nim
flags Flags inc/commdlg.nim in OPENFILENAME
TLOGFONT LOGFONT inc/wingdi.nim
lfItalic lfItalic inc/wingdi.nim cast to BYTE
TCHOOSEFONT TCHOOSEFONT inc/commdlg.nim NOTE the T prefix is kept.
Had used UncheckedArray[RGBQUAD] instead of array[0..0,RGBQUAD] in my code to solve a problem
better solved by {.boundChecks: off.}
make sure 4th parameter of CreateDIBSection is of type: ptr pointer and just just pointer
When using SendMessage, it may be necessary to coerce the 3rd param into WPARAM whenever
that param is an int (e.g. any kind of HANDLE). This is because HANDLE is int whereas
WPARAM is uint32 (when winimCpu32)
See above, but for 4th SendMessage param LPARAM
In SendMessage(---,WM_CTLCOLOREDIT,---,---) return value had to coerce HBRUSH into LRESULT, because
HBRUSH was HANDLE is int but LRESULT is LONG_PTR is int32 (when winimCpu32)
Mostly it was changing identifiers back to their originals as published by msdn.
I've said it before but winim should really have used lowerCase for the procs like our style guide recommends. Many Nim programmers read UpperCase as type names nowadays.
Well . . . it's Microsoft vs the world. I'm inclined to side with Microsoft when it is their library, but then try to hide the irritating proc names in my own module.
That has the benefit(?) of clearly marking what is Microsoft stuff as opposed to my own code - when I look back at the code months later.