I have done a bit more investigation with regard to the value returned by OpenWindow(#PB_Any
Values returned by the asm and C-backend compilers are very different in size. Here is a small test program:
Code: Select all
w.i=OpenWindow(#PB_Any,#PB_Ignore,#PB_Ignore,640,480,"Test",#PB_Window_SystemMenu | #PB_Window_ScreenCentered)
Debug w
Debug WindowID(w)
Repeat
Until WaitWindowEvent()=#PB_Event_CloseWindow
If I run this in PB 5.73, 64-bit I get values like:
36780352
5180402
If I run it in PB6.00 alpha 3 using the C backend compiler:
4536640
4197196
When I run the same program in PB6.00 alpha3 using the asm compiler:
2665121528128
3606486
The first value appears to be an identification number generated by PB. It is not the handle.
The second value is the actual handle.
The problem is the
huge difference in the values between the asm and C-backend compilers and the previous versions of PB which use ASM. I can compensate the integer type in my own code but I am also using code libraries developed by others here on the forum.
This change (?) could affect other libraries and software graciously offered on this forum. In particular PurePDF. I have not been able to get this to work in PB6. It compiles but run-time memory errors are generated when trying to produce a pdf. This happens for
both the asm and c compilers. I'm not bright enough to work out the solution. Works perfectly in PB5.73 and earlier. I am sure others on the forum use this excellent library. Maybe someone else here could solve it?