Re: Another Win32lib problem, and this may not be fixable. Fixed - sort of.....
- Posted by ChrisB (moderator) Sep 06, 2023
- 1196 views
Hi
So after many a late nights and thinking time driving back and forth to work, I nailed the problem to winspool.drv, DocumentPropertiesA, being a non returning blocking function in the winspool.drv. My suspicion is that it's a winspool.drv installed by the old printer installation, which is in actual fact causing problems for all 32 bit programs using it.
So the solution is not to call these functions, by setting a flag in w32lib that says either allow or disallow winspool calls, and so far, touch wood it works - tested on various w32 lib programs, and the mother IDE too. At least I can create win32 forms using the IDE now.
Most users will set WINSPOOL_ALLOWED to 1, but if your w32 program freezes (not crashes), try setting it to 0. There is some debugging stuff left in there too if you get curious, and look in w32winspool.ew w32dll.ew and w32resources.ew (although the errors don't happen there, a lot of calls to printer functions are in there)
I will upload this to my box.net, with WINSPOOL_ALLOWED = 1 set, so for most people no difference.
I was a little curious myself - this seems faster
if funcid = spoolFuncs[1][1] or funcid = spoolFuncs[2][1] or funcid = spoolFuncs[3][1] or funcid = spoolFuncs[4][1] or funcid = spoolFuncs[5][1] or funcid = spoolFuncs[6][1] or funcid = spoolFuncs[7][1] then WINSPOOL_FUNCTION_FOUND = 1 end if
as opposed to
for i = 1 to 7 do if funcid = spoolFuncs[i][1] then --showspoolFunc(i) WINSPOOL_FUNCTION_FOUND = 1 exit end if end for
Is it?
Remember there will be a lot of iterations of this (every time a c_func (w32Func) is called), and the loop just seemed slower to me (especially with the IDE).
Feedback / issues appreciated. Adding on to that if anyone else has made any changes, would be happy to incorporate them if you want.
Link https://app.box.com/s/aobv6tpdkk5suz5g66xk4p7iwujfd0cv
Cheers
Chris