linedda from gdi32
Code: Select all
BOOL LineDDA(
_In_ int nXStart,
_In_ int nYStart,
_In_ int nXEnd,
_In_ int nYEnd,
_In_ LINEDDAPROC lpLineFunc,
_In_ LPARAM lpData
);
Code: Select all
BOOL LineDDA(
_In_ int nXStart,
_In_ int nYStart,
_In_ int nXEnd,
_In_ int nYEnd,
_In_ LINEDDAPROC lpLineFunc,
_In_ LPARAM lpData
);
Code: Select all
Procedure callback(x, y, lParam)
Debug Str(x)+", "+Str(y)
EndProcedure
LineDD_(0,0,100,160,@callback(),0)
Code: Select all
CompilerIf #PB_Compiler_Unicode = #True
Import "gdi32.lib"
LineDDA(x1, y1, x2, y2, *callback, lParam)
EndImport
CompilerElse
Macro LineDDA
LineDD_
EndMacro
CompilerEndIf
Procedure callback(x, y, lParam)
Debug Str(x)+", "+Str(y)
EndProcedure
LineDDA(0,0,100,160,@callback(),0)
Thanks, works perfectly, but could you just briefly clarify what's the issue in this case?netmaestro wrote:Ok, I see the issue you're referring to. Here's a version that will work under unicode or ascii:
It's actually quite a common problem that crops up from time to time. If you have the "Compiler Options -> Create Unicode Executable" checked then the linker will search for a unicode version of the function from the library (with the name usually ending in "W"), as opposed to the name ending in "A" which is the ascii version. If you check gdi32.lib you will see that there is no "LineDDW" version of this function, all there is is the ascii one. But when you compile under unicode the linker won't link the ascii version in with your exe - you have to force it using code like I posted. If you think about what the function does, there really is no need for MS to have included a unicode-ready version - no strings involved. But PB could utilize a macro or something to get the function into the program seamlessly. It actually could be considered a bug, losing access to a non-string function because you flipped the Unicode switch.could you just briefly clarify what's the issue in this case?
Hi netmaestro, thank you very much for your explanation.netmaestro wrote:It's actually quite a common problem that crops up from time to time. If you have the "Compiler Options -> Create Unicode Executable" checked then the linker will search for a unicode version of the function from the library (with the name usually ending in "W"), as opposed to the name ending in "A" which is the ascii version. If you check gdi32.lib you will see that there is no "LineDDW" version of this function, all there is is the ascii one. But when you compile under unicode the linker won't link the ascii version in with your exe - you have to force it using code like I posted. If you think about what the function does, there really is no need for MS to have included a unicode-ready version - no strings involved. But PB could utilize a macro or something to get the function into the program seamlessly. It actually could be considered a bug, losing access to a non-string function because you flipped the Unicode switch.could you just briefly clarify what's the issue in this case?
bbanelli wrote: how should one tell from Microsoft documentation that this is ASCII/ANSI only version of function, usually under "Requirements" tab is says something like "Unicode and ANSI names" so you can tell. But I can't see anything similar with this function, though...
Oh, OK, that's where I got confused, probably because "DD" is capitalized so it's harder to "figure out" than MessageBoxA/W, for example.DontTalkToMe wrote:For some reason PB thinks the function is named LineDD instead (so LineDD_ in PB) and thinks there should be an ascii (LineDDA) and a unicode (LineDDW) version of it.