Win64 version crashing (1 Viewer)

[pdanes]

I have several apps making use of Lebans' picture box class. They have worked great for many years, but they have started bombing as users have switched to 64-bit systems. I've tracked it down to the following code, which run great on 32-bit machines and causes Access to shut down on 64-bit ones. If I code around to skip this routine, it bombs anyway. I have no idea why this routine is here, or what to do about it crashing Access. Does anyone know why this would be here in the first place, and more importantly, how to make it work in 64 bits?

'Scheduled ShutDown of GDI+ handle to avoid memory leaks
Private Sub AutoShutDown()
'Set to 5 seconds for next shutdown
'That's IMO appropriate for looped routines  - but configure for your own purposes
If lGDIP <> 0 Then
    ReDim Preserve tVarTimer(lCounter)
    tVarTimer(lCounter) = SetTimer(0&, 0&, 5000, AddressOf TimerProc)
End If
lCounter = lCounter + 1
End Sub

 

[The_Doc_Man]

The issue will be to convert whatever is crashing to use PtrSafe declarations in the call sequence that is your devil. I would suggest that you search this forum for changing 32-bit calls to 64-bit calls. Many articles exist to help you.

I'm going to suggest that one of the bugaboos is the use of "AddressOf" which is NOT a valid element of VBA syntax. But here is an article that might help. I'm going to guess that SetTimer is involved in a class module since you suggested that you got this from Lebans.

VBA: Workaround To Emulate AddressOf Operator In A Class Module

I need make use of several Windows API functions in a Class that I am developing, for a hobby project. Several of these functions require the use of the AddressOf Operator, but as per Microsoft

stackoverflow.com

 

[tvanstiphout]

The callback should be in a Standard Module, not a class module.
*Maybe* if it is a Static Class it would work too.

 

[pdanes]

The issue will be to convert whatever is crashing to use PtrSafe declarations in the call sequence that is your devil. I would suggest that you search this forum for changing 32-bit calls to 64-bit calls. Many articles exist to help you.

I'm going to suggest that one of the bugaboos is the use of "AddressOf" which is NOT a valid element of VBA syntax. But here is an article that might help. I'm going to guess that SetTimer is involved in a class module since you suggested that you got this from Lebans.

VBA: Workaround To Emulate AddressOf Operator In A Class Module

I need make use of several Windows API functions in a Class that I am developing, for a hobby project. Several of these functions require the use of the AddressOf Operator, but as per Microsoft

stackoverflow.com

Yes, I suspect it is that. I've put in conditional compilations for 64, but no luck yet. It's hard to work on, because every failed attempt crashes the app, and it's kind of a pig to start.

Some of the code is in a class module, some in a regular.

 

[pdanes]

The callback should be in a Standard Module, not a class module.
*Maybe* if it is a Static Class it would work too.

If you mean this:

tVarTimer(lCounter) = SetTimer(0&, 0&, 5000, AddressOf TimerProc)

then that is is a regular module. I don't know what a static class would be.

 

[CJ_London]

Tom is saying timerproc needs to be a sub in a standard module, not in a class module

 

[pdanes]

Tom is saying timerproc needs to be a sub in a standard module, not in a class module

Ah, thank you. It is, though - it's the very next routine after this AutoShutDown.

Private Sub TimerProc(ByVal hWnd As Long, ByVal uMsg As Long, ByVal idEvent As Long, ByVal dwTime As Long)
ShutDownGDIP
End Sub

One of the things I've tried is changing the parameters here to LongPtr and LongLong, according to some examples I found on StackOverflow. No change - still crashes.

 

[tvanstiphout]

Private???
That should be Public.

And if you don't follow the advice already given about PtrSafe and data types, crashes will continue to occur, perhaps randomly.

 

[pdanes]

Private???
That should be Public.

And if you don't follow the advice already given about PtrSafe and data types, crashes will continue to occur, perhaps randomly.

Why should it be public? Lebans wrote it as private and it has been working that way without a hitch for at least fifteen years. In any case, I just tried making it so, and no difference - still crashes.

And I am trying very hard to track down all the instances of data types, but nothing yet has helped.

 

[tvanstiphout]

I did not check Lebans code, but you can take that to the bank.
Of course he wrote it before 64-bit was a thing.
I thought you were trying to define a callback for SetTimer, the Windows API call.
If this is an internal call, then by all means it can be private.

 

[pdanes]

I did not check Lebans code, but you can take that to the bank.
Of course he wrote it before 64-bit was a thing.
I thought you were trying to define a callback for SetTimer, the Windows API call.
If this is an internal call, then by all means it can be private.

I'm not sure about all that. There is a good deal of stuff in his code that I flat do not understand. This is one of those things. I have no idea why I need a timer at all, when what I am doing is painting a screen image, but I doubt he put it in just for a lark. The code works in 32-bit machines, and crashes in 64-bit machines, and also crashes in 64-bit machines when that timer call is bypassed.

I have no idea why any of that is the case, and honestly, all I want right now is to get it working. The nuts and bolts of Lebans' code is fascinating, and would love to understand it better, but right now, I have a rather unhappy customer, and that has priority over my academic curiosity. I also dearly wish he had not retired from supporting this stuff. I got stuck a few times using his code back when he was still active, and he always answered my questions promptly, clearly and correctly. I'm sure he could figure this out in less time than it takes me to describe it, but he's no longer an option. I'm hoping someone somewhere has some clue on this, hence my post. Otherwise, I'm just randomly picking away at things that look somewhat like something described in various forums and trying it. But that is slow, frustrating and pretty much just fumbling around in the dark.

 

[CJ_London]

Ah, thank you. It is, though - it's the very next routine after this AutoShutDown.

So far as I am aware the call to the ‘address of’ needs to be in a class module.

So your autoshutdown sub is in a class module (which might be a form module) whilst TimerProc would be in a standard module

 

[theDBguy]

I'm not sure about all that. There is a good deal of stuff in his code that I flat do not understand. This is one of those things. I have no idea why I need a timer at all, when what I am doing is painting a screen image, but I doubt he put it in just for a lark. The code works in 32-bit machines, and crashes in 64-bit machines, and also crashes in 64-bit machines when that timer call is bypassed.

I have no idea why any of that is the case, and honestly, all I want right now is to get it working. The nuts and bolts of Lebans' code is fascinating, and would love to understand it better, but right now, I have a rather unhappy customer, and that has priority over my academic curiosity. I also dearly wish he had not retired from supporting this stuff. I got stuck a few times using his code back when he was still active, and he always answered my questions promptly, clearly and correctly. I'm sure he could figure this out in less time than it takes me to describe it, but he's no longer an option. I'm hoping someone somewhere has some clue on this, hence my post. Otherwise, I'm just randomly picking away at things that look somewhat like something described in various forums and trying it. But that is slow, frustrating and pretty much just fumbling around in the dark.

Hello. I really have nothing to contribute. I only want to share an experience regarding the same dilemma not too long ago. We have several Access databases at work that use Leban's API popup calendar. It worked very well. Unfortunately, it also died when we converted our system to 64-bit recently. I tried so hard to make it work and even asked for assistance here, but I ended up removing Leban's code and replacing it with the one from Allen Browne. I wish I got it to work; but although I came close, I couldn't convert the whole thing into a working version.

If you are doing this for a customer, perhaps you might consider paying someone else to do the conversion for you. I think I know someone here who offers that service. I didn't go that route because my issue was for a work database. Just a thought...

 

[arnelgp]

the code from your first post is responsible for showing "images" to your custom ribbon.
it has nothing to do with what you are experiencing. i have been using that code (actually there are lots more of it than the fragment you showed) without any problem. the problem is with Leban's picture box class. it is not yet ported to x64 code. there is similar code (both compatible with x32 and x64) on VTools.

 

[pdanes]

Hello. I really have nothing to contribute. I only want to share an experience regarding the same dilemma not too long ago. We have several Access databases at work that use Leban's API popup calendar. It worked very well. Unfortunately, it also died when we converted our system to 64-bit recently. I tried so hard to make it work and even asked for assistance here, but I ended up removing Leban's code and replacing it with the one from Allen Browne. I wish I got it to work; but although I came close, I couldn't convert the whole thing into a working version.

If you are doing this for a customer, perhaps you might consider paying someone else to do the conversion for you. I think I know someone here who offers that service. I didn't go that route because my issue was for a work database. Just a thought...

Who is that someone you think you know?

 

[pdanes]

the code from your first post is responsible for showing "images" to your custom ribbon.
it has nothing to do with what you are experiencing. i have been using that code (actually there are lots more of it than the fragment you showed) without any problem. the problem is with Leban's picture box class. it is not yet ported to x64 code. there is similar code (both compatible with x32 and x64) on VTools.

Well, maybe, but that is where it crashes. I do have some custom images on the ribbon that serves that form. There are three principal forms in the app, and the one using the picture box class also has some custom images in the ribbon - the only one of the three to have either. But when I bypass the code that loads the ribbon images, it still crashes. Somewhere else - I haven't tracked down exactly where yet.

So you're telling me that this is hopeless, that the Lebans' PictureBox class simply wont work here? I have a little trouble believing it's just that. The customer had Office 2019 on this same machine earlier, and it worked there. It stopped working when he switched to Office 365. I earlier re-installed 2019 myself, when it was crashing on something else (turned out to be a language incompatibility issue) and don't recall any option during the installation process to select 32 or 64 bit versions, but maybe he already had a 32-bit install version - he purchased it several years ago.

Might it be possible to simply install a 32-bit version of Office 365? I don't have the time (or probably the expertise, at least not without a LOT more research) to work my way through all of Lebans' code trying to figure out how to make it work in 64 bits. But if I can bounce the Office installation back down to a 32-bit version, that would solve the problem.

 

[isladogs]

Whilst searching for similar threads, I just discovered an older thread you posted last year on exactly the same subject.
Have a(nother) look at the links I provided in post #6 to assist with the conversion

Lebans PictureBox on Win64

I have several apps in the field using Stephen Lebans' PictureBox class to draw various thing on the screen, generally a map with some selected information from the database shown on that map. All has worked well for many years, but one of my users now has a 64-bit machine, and the class no...

www.access-programmers.co.uk

 

[pdanes]

Whilst searching for similar threads, I just discovered an older thread you posted last year on exactly the same subject.
Have a(nother) look at the links I provided in post #6 to assist with the conversion

Lebans PictureBox on Win64

I have several apps in the field using Stephen Lebans' PictureBox class to draw various thing on the screen, generally a map with some selected information from the database shown on that map. All has worked well for many years, but one of my users now has a 64-bit machine, and the class no...

www.access-programmers.co.uk

Yes, that was me. I have been working on this for a while. The problem cropped up, then became irrelevant because of some other circumstances, but now it's serious. I did look at those links, both back then and again recently, when this showed up again. They do provide a great deal of interesting information, but unfortunately, none have yet led me to to a solution.

 

[gemma-the-husky]

I doubt whether converting some processes to 64 bit access is always as simple as "just" adding ptrsafe declarations. Those parameters used with settimer () may not work in 64 bit. That might be the issue.

 

[isladogs]

The links I gave should provide the 64-bit version of each API declaration & type statement.

The author of the Windows API Viewer / Converter tool has kindly allowed me to host his utility - it is now available for free via my website:

32 to 64-bit Conversion

This article provides links to various web pages & utilities to assist with converting VBA code for use in 64-bit applications.

www.isladogs.co.uk

If the conversion is that important to you, I suggest you pay Peter Cole to do the conversion for you - his website is https://thememydatabase.co.uk.

However, although Stephen Lebans' website contains lots of very clever code, I would also check whether the functionality in his PictureBox utility is now available in Access itself or in other 64-bit compatible code