Search results

Usually you can't instantiate a class in a referenced Access lib database with the 'New' keyword. But you can make your class in the referenced lib database a static class. Then there always exists a static default instance of that class which you can access by its name and call a procedure...

No, my procedures are rather short, if possible.

@Edgar_ : I'll have to see if and how I deal with it. So far I've been able to do without it. @Isaac: There is no 'declarations area' in my codes. I do not declare variables in the head of a procedure, but where I need them for the first time. @jwcolby54: This is not hungarian notation...

@Josef P. : Thanks for the links, I already knew them ;) I agree with you. I use long variable- and procedurenames (I like reading code like a book), don't use prefixes like "lng", "str" and so on (what unfortunately has been misunderstood as Hungarian Notation decades ago) and have my coding...

A negative aspect of code sharing is that it usually creates a mess. If I want to use external code, I usually rework it completely so that, for example, the naming and most importantly the casing (we all know the problem) fits for me. I pay a lot of attention to this, it's a real PITA. Is that...

If John would like to proceed this way, why not. These you posted here are not 64-bit capable (the ones I customized were). But as I wrote here the first five of your list can be omitted completely.

@Gasman : If you mean me, I have to admit that I don't quite follow. :) @jwcolby54 : Since your code is primarily exemplary, you could, for example, replace the API routines for determining the computer and user name with the following simple code for the sake of simplicity: Public Function...

You could try to do without any bitness-specific code in your examples. It is not needed for the pure teaching of class programming anyway.

@jwcolby54 : I use my one solution (which isn't so well integrated yet), but here you can watch a presentation of a widely used Access add-in by Adam Waller:

I didn't know that, sorry. I just downloaded your accdb, corrected and uploaded it. You could export both versions to text files (as you mentioned GitHub you seem to know how this can be done) and compare the text files. It's not much work. Then you can correct the text files on GitHub by hand...

No, not much. It also seemed that not all procedures using APIs declarations are used at all. And some could be replaced by other techniques, but I just corrected the API declarations.

Correct. I didn't say anything else.

Press the About Access button. The following dialog will shot the bitness of your Microsoft Office installation. Edit: If you want to check the bitness in VBA use such a function: Public Function MicrosoftAccessIs64bit() As Boolean #If Win64 Then MicrosoftAccessIs64bit = True...

@jwcolby54 , @isladogs : I updated the api declarations to be compatible for 64-bit too. Seems to work (at least the ones really being used). I agree. :-)

Can you try (with a copy of your database/environment) to create a minimally reproducible environment by deleting more and more until only essential objects really remain in the database to be able to reproduce the problem? In the best case, perhaps only one table and one form that are causing...

Yes, as far as I know, it only depends on the installation technique of Microsoft Office: MSI installations receive updates through Windows Update and C2R (click-to-run) installations through the dedicated C2R update mechanism.

@cheekybuddha : For me the most important part of support are security updates. But also functional updates are included. @isladogs : As far as I can see both, 2016 and 2019 have extended support until Oct 14, 2025. But I agree, it seems that "extended support" only contains security updates...

@Josef P. : I have had this topic on my radar for a long time and am very interested in it. However, I haven't yet found the time to familiarize myself with it. But I am very grateful for your monologue ;)

Thanks a lot for this validated information, @isladogs , @sonic8 and the Access team! The only 'problem' is that it is estimated that only around a third of our customers use Access 365 (if at all), the rest use the still supported versions 2016 - 2024. Unfortunately, they cannot verify a...

The Microsoft Office Subject Interface Packages for Digitally Signing VBA Projects (https://www.microsoft.com/en-us/download/details.aspx?id=56617) sounded very interesting, but unfortunately it seems not to support Microsoft Access: SUPPORTED FILE FORMATS MSOSIP: Excel: .xla...