Lebans PictureBox on Win64

[pdanes]

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?

 

[isladogs]

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:

Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As LongPtr)

 

[pdanes]

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?

 

[sonic8]

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.

 

[GaP42]

There are many threads relating to the migration/ update of vba to 64bit which contain references to tool that can be used to assist - one where I had issues as but one eg

Struggle with Migrating to 64bit | Access World Forums (access-programmers.co.uk)

 

[isladogs]

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)

Content retirement

The content that you're looking for is now retired.

learn.microsoft.com

This MS article is useful:

Compatibility between the 32-bit and 64-bit versions of Office

Find out how the 32-bit version of Office is compatible with the 64-bit version of Office.

learn.microsoft.com

I use the Windows API Viewer / Cconverter for Excel that used to be available at Ron de Bruin's website:

History | Ron de Bruin

Welcome to https://www.rondebruin.nl

www.rondebruin.nl

However, I couldn't find it when I just checked

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

https://www.thememydatabase.co.uk/access32to64.html

There are many good YouTube videos and Access articles on the subject including this one by @sonic8

Windows API declarations in VBA for 64-bit

How to convert your API Declarations to 64-bit. - Common myths debunked, key factors explained!

codekabinett.com

 

[Uncle Gizmo]

This is the only API link I have a website which may or may not be useful:-

Download Office 2010 Help Files: Win32API_PtrSafe with 64-bit Support from Official Microsoft Download Center

Windows API Declarations and Constants for Visual Basic (Updated for the 64-bit version of Microsoft Office 2010) provides declarations for Microsoft Visual Basic programmers who want to call Windows API routines. This file is updated to include calls to the 64-bit version of Microsoft Office 2010.

www.microsoft.com

 

[pdanes]

Thanks, lots of stuff to look through there. I'll get to work.

 

[pdanes]

Thanks, I'll take a look.