Win64 version crashing

[theDBguy]

Who is that someone you think you know?

Good morning. Looks like @isladogs already beat me to it. Good luck!

 

[pdanes]

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

Thank you, I'll see what I can get done with that converter. Back to work.

I admit, I had not thought of using Access's built-in stuff. The PictureBox class does a great deal, but I don't need most of the functionality that Stephen put into it, and have removed the code that never got called. I have a background image, a grid of horizontal and vertical lines, various symbols in the resulting boxes and around the periphery of the grid, and the ability to react to a mouse-click with access to where on the image the click happened. It is on a form now, with an attendant ribbon. But forms and reports have a rather severe limit on how many controls you can add and remove during its lifetime (754), before you have to do a C & R to clean out the rubbish. I ran into that many years ago, when I tried doing just that with a text-only database. Fortunately, I was doing LOTS of adds, so I ran into the problem pretty quickly, learned the limitation and went on to do the whole thing a another way. If adding each of the symbols counts as a separate control, I would crash very quickly, and possibly not even be able to display the busier pictures at all.

 

[cheekybuddha]

I haven't looked at the Leban's code, but it uses proper subclassing (e.g. GetWindowProc() ) then you can not have the VBA editor open while the code runs. It will always crash Access.

 

[pdanes]

I haven't looked at the Leban's code, but it uses proper subclassing (e.g. GetWindowProc() ) then you can not have the VBA editor open while the code runs. It will always crash Access.

Some stuff you cannot, some you can. But what I'm running into crashes either way, although of course, I cannot tell if it might be crashing differently when I step it. When I step it, the crash comes at the point of calling the timer routine, and it crashes the same way regardless of whether I actually call the routine or not - Access just shuts down.

 

[isladogs]

For what its worth:
1. The quoted limit of 754 controls has long since been out of date - depending on your version & bitness it is now well over 1000. See my article:

Access Specification issues

Microsoft publishes a list of Access specifications and limits. Most of the information is correct. This article discusses some specification items that are misleading, out-of-date or inaccurate

www.isladogs.co.uk

2. Compact & repair does not reset the lifetime limit of controls on a form / report

 

[pdanes]

For what its worth:
1. The quoted limit of 754 controls has long since been out of date - depending on your version & bitness it is now well over 1000. See my article:

Access Specification issues

Microsoft publishes a list of Access specifications and limits. Most of the information is correct. This article discusses some specification items that are misleading, out-of-date or inaccurate

www.isladogs.co.uk

2. Compact & repair does not reset the lifetime limit of controls on a form / report

1. Okay, I didn't realize that had been changed, but it's still not many for my purposes in this app. There are 679 squares in the grid that can potentially contain a symbol, and some instances will have most or maybe even all of them filled. And that is even before the lines to form the grid, the numbers around the grid, and some other miscellaneous graphic clutter. I could not even create two such images before hitting the limit.

2. It did for me, back when I first hit this limit. The code creating the controls on the form would crash when it hit the limit. I would close with C & R, re-open and could again create controls, until I again hit the limit. But that was quite a few years ago, I think around the time 2007 was first coming out. It may be different now.

 

[xavier.batlle]

Here it's the vba7/64 bit version of the PictureBox database by Lebans. I hope it would be useful/helpful.

 

[theDBguy]

Here it's the vba7/64 bit version of the PictureBox database by Lebans. I hope it would be useful/helpful.

Hi @xavier.batlle Would you happen to have a 64-bit version of Leban's API calendar? Thanks!

 

[pdanes]

Here it's the vba7/64 bit version of the PictureBox database by Lebans. I hope it would be useful/helpful.

Jesus - WHERE did you get this? I'm going to try this right away. If it works, I am forever in your debt. Thank you.

 

[pdanes]

Here it's the vba7/64 bit version of the PictureBox database by Lebans. I hope it would be useful/helpful.

Well, I tried the complete package and it works perfectly on my machine, so now I need to get to work porting the code into my app. Maybe I'll even figure out along the way exactly what the problem is with my current setup.

Many thanks - if you ever make it to Prague, the beers are on me.

 

[isladogs]

Jesus - WHERE did you get this? I'm going to try this right away. If it works, I am forever in your debt. Thank you.

I can tell you that Xavier (Xevi) did the conversion himself using Peter Cole's conversion utility from my link as a guide.
I am aware of at least one big issue that he needed to overcome in doing the conversion.

As there are so many APIs in the code, I expect it took him a long time to do
However, you could have done this yourself from the links I provided last summer.

 

[isladogs]

I haven't looked at the Leban's code, but it uses proper subclassing (e.g. GetWindowProc() ) then you can not have the VBA editor open while the code runs. It will always crash Access.

Just tested this statement. It works perfectly with the VBE open

 

[xavier.batlle]

Hi @xavier.batlle Would you happen to have a 64-bit version of Leban's API calendar? Thanks!

Hi @theDBguy,
No unfortunately I don't have a 64-bit version of Leban's API calendar.

 

[pdanes]

I can tell you that Xavier (Xevi) did the conversion himself using Peter Cole's conversion utility from my link as a guide.
I am aware of at least one big issue that he needed to overcome in doing the conversion.

As there are so many APIs in the code, I expect it took him a long time to do
However, you could have done this yourself from the links I provided last summer.

Well, then he's better at this than I am. I looked at all those things, and tried all sorts of things, and failed. It's hard to make much progress when you don't really understand what the calls do, what the exact problem is, and every failed attempt crashes the app.

Xavier is much better, or much more patient, or more thoroughly educated in Access obscurities than I am - maybe all of those things. However, I intend to study what he did when porting it in - maybe I'll learn where I went wrong.

 

[theDBguy]

Hi @theDBguy,
No unfortunately I don't have a 64-bit version of Leban's API calendar.

Thanks for checking. Please keep me in mind if you ever convert it in the future. Cheers!

 

[xavier.batlle]

Thanks for checking. Please keep me in mind if you ever convert it in the future. Cheers!

Ok, perhaps I'll try to convert it, but as you know it's not a piece of cake! ;-)

 

[xavier.batlle]

This is a new version of the PictureBox converted to x64.
In the first version there were two buttons that didn't work because they depend on a call (VarPtrArray) used in VB5 (msvbvm50.dll), now I've changed that reference for another one than comes with VBA7. (VBE7.dll)
Now, I think the sample is fully functional.

 

[cheekybuddha]

Just tested this statement. It works perfectly with the VBE open

My statement was missing an 'if'

It should have read:

but if it uses proper subclassing (e.g. GetWindowProc() ) then you can not have the VBA editor open while the code runs. It will always crash Access.

I looked at the code just now - it doesn't use proper subclassing (e.g. GetWindowProc() ), so my point was not relevant.

 

[pdanes]

This is a new version of the PictureBox converted to x64.
In the first version there were two buttons that didn't work because they depend on a call (VarPtrArray) used in VB5 (msvbvm50.dll), now I've changed that reference for another one than comes with VBA7. (VBE7.dll)
Now, I think the sample is fully functional.

I got everything working, tested it all on every machine I have available, decompiling and recompiling on every machine, and testing that freshly compiled version on every other machine. All worked perfectly everywhere, so I installed it on the customer's machine and returned it to him. Customer is stoked and so am I. One more database in the field at another customer that uses this code, and I will now convert that one as well.

There was one place in the original version it bombed, where you left a Len instead of a LenB - I fixed it, then discovered you had corrected it in the newer version anyway. There were many places in the code that needed converting from Long to LongPtr. Some are obvious, but some are not, or not to me, at any rate - I doubt very much that I would have ever found them all, even with the help of the tools and links that other people have posted here.

I wonder if this will repeat down the road, when processors and operating systems start switching from that archaic 64-bit design to the stylish new 128-bit versions. Will there be a LongLongPtr, or a QuadLongPtr data type to make everyone's life miserable all over again?

In any case, I remain in your debt. Once again, many, many thanks.

 

[xavier.batlle]

In any case, I remain in your debt. Once again, many, many thanks.

You are welcome!
It has been an interesting challenge to convert it and I'm happy to have solved your problem.

I wonder if this will repeat down the road, when processors and operating systems start switching from that archaic 64-bit d
esign to the stylish new 128-bit versions. Will there be a LongLongPtr, or a QuadLongPtr data type to make everyone's life miserable all over again?

I don't think we see it! ;-)