Lebans PictureBox on Win64 (1 Viewer)

pdanes

Registered User.
Joined
Apr 12, 2011
Messages
142
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 longer works. It bombs on the APICopyMemory call. I imagine there is something there that needs to be updated to the LongPtr type, but I have no idea which one(s). Lebans wrote some insane code, but left no documentation on how he did it, and has completely bailed on it all.

Does anyone have any idea on how to update this class to work on Win64?
 
Last edited:
Having provided numerous example apps for developers over many years, Stephen decided to retire over 15 years but he was kind enough to keep the site running to assist other developers make use of his code.
I totally disagree that he
'completely bailed on it all'

Although I have used/adapted many of Stephen's examples, I have never looked at his PictureBox example and don't know what other API calls it contains. I suggest you try & do the conversions yourself using one of the various conversion utilities available

As for CopyMemory, the 64-bit version is:

Code:
Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As LongPtr)
 
I meant that he just quit working on it. He wrote that himself, that he was going to do other things and would no longer respond to any communication regarding Access. He left the website up, but as far as I know, it has remained a completely static site. And he left no docs on where he got the info on how to do his magic. I wrote him a few times back when he was still active, and he always quickly helped me fix whatever I was having trouble with, but he absolutely refused to ever answer any questions about his own sources.

In any case, the APICopyMemory call was wrong - I had that last parameter as Long, instead of LongPtr. However, correcting it did not fix the problem - the app still bombs when that call is made. No error; Access just shuts down. I suspect that maybe there are some other preparatory calls to other routines that have this same mistake, but I have no idea how to find them. Is there some way to determine which parameters and function returns must be converted to LongPtr, and which ones remain Long? Could I just make ALL of them LongPtr? I tried that, but it still bombs, so I don't know if maybe I fixed what needed to be fixed, but also broke something that should not have been changed, or if there is something else altogether that is making this happen.

You mention conversion utilities. I know of such things from the old .mdb format to .accdb, but I don't need that - this has been in .accdb format since 2007 first came out. There are things that convert to SQL Server and various non-Access forms, but again, that doesn't apply here. Could you maybe point me to something specific, or at least, exactly what sort of 'conversion utility' I should be searching for?
 
Lebans wrote some isane code, but left no documentation on how he did it, [...]
[...] but he absolutely refused to ever answer any questions about his own sources.
Seriously?!
Did you even look at the code of clsPictureBox?
It contains a ton of comments explaining in quite some detail what he is doing in the code and why.
It also contains a "Credits" section where he names at least some of his sources.
 
Yes. its a static site as is Allen Browne's but that's what retirement means! No further activity on the site.
At least we still have access to both of their enormous contributions to the Access community!

I agree with @sonic8 that the code for each utility contains a lot of helpful information.
Most of Stephen's code is based heavily on API calls, some of which are relatively obscure
As you are using 64-bit Office, you will have to bite the bullet and do the conversions if you wish to use them


Is there some way to determine which parameters and function returns must be converted to LongPtr, and which ones remain Long? Could I just make ALL of them LongPtr? I tried that, but it still bombs, so I don't know if maybe I fixed what needed to be fixed, but also broke something that should not have been changed, or if there is something else altogether that is making this happen.

You mention conversion utilities. I know of such things from the old .mdb format to .accdb, but I don't need that - this has been in .accdb format since 2007 first came out. There are things that convert to SQL Server and various non-Access forms, but again, that doesn't apply here. Could you maybe point me to something specific, or at least, exactly what sort of 'conversion utility' I should be searching for?
No, you cannot just convert them all to LongPtr.
I tried doing exactly that back in 2014 when I first had to convert my code to 64-bit. It won't error but nor can you expect it to work.

The MS text document in this link contains many of the APIs for 64-bit (but not all)

This MS article is useful:

I use the Windows API Viewer / Cconverter for Excel that used to be available at Ron de Bruin's website:
However, I couldn't find it when I just checked

Peter Cole has a very comprehensive 64-bit converter app:

There are many good YouTube videos and Access articles on the subject including this one by @sonic8
 
This is the only API link I have a website which may or may not be useful:-

 

Users who are viewing this thread

Top Bottom