We use AllowSpecialKeys=false in our vba-Access-databases to disable the "stop" commands in the version we deploy to the customers.

This works fine in Windows <=10 and office 16.

Now we want to change to Windows 11 and office 365. Unfortunately it seems like microsoft changed the functionality of AllowSpecialKeys and the code breaks at the stop command and opens the VBA-Development-Enviroment. This is nothing our customer should see.

Do you know anything about this? Any information about a workaround?

We use AllowSpecialKeys=false in our vba-Access-databases to disable the "stop" commands in the version we deploy to the customers.

https://learn.microsoft/de-de/office/vba/access/concepts/miscellaneous/allowspecialkeys-property

This works fine in Windows <=10 and office 16.

Now we want to change to Windows 11 and office 365. Unfortunately it seems like microsoft changed the functionality of AllowSpecialKeys and the code breaks at the stop command and opens the VBA-Development-Enviroment. This is nothing our customer should see.

Do you know anything about this? Any information about a workaround?

• vba
• ms-access
• debugging

• Why not run the application in runtime mode? A quick test is to rename the application file from application.accdb to application.accdr. – Gustav Commented Nov 19, 2024 at 11:32
• It still hat the .mdb-extention. To change this would be a lot of work. – Gener4tor Commented Nov 19, 2024 at 12:02
• Then it will be appliaction.mdr. Just for a test. But, on a higher level, what is stop command, and why do users have access to such one? There should be no way for users to "stop" an application, only to quit it. – Gustav Commented Nov 19, 2024 at 13:49
• @Gustav: A "Stop"-comand is this: learn.microsoft/en-us/office/vba/Language/Reference/… Its used vor us to have permanent breakpoints (The VBE does not save breakpoints otherwise). And until Windows 11 and office 365 we were able to deaktivate them in the deployment-version. Exactly this does not work anymore. This is what my question is about. – Gener4tor Commented Nov 19, 2024 at 14:19
• 1 Interesting. With my 30+ years with Access, I've never seen Stop used for anything else than debugging during development or for experiments. – Gustav Commented Nov 19, 2024 at 18:25

3 Answers 3

It's not all that hard to implement an optional "Developer" mode for debugging code. Of course, if you've deployed multiple applications with STOP left hanging out in your code, it will require some amount of refactoring. I suppose that will have to happen anyway, though.

In your intialization Function, which can be invoked from an AutoExec macro, add these two lines:

Global Const booDebug As Boolean = False
'Global Const booDebug As Boolean = True

Wherever your code has a Stop, change it to

If BooDebug Then Stop

During development and debugging, you comment out the "False" option and uncomment the "True" option.

For deployment, of course, you uncomment the "True" option and comment out the "False" option. No further code modifications are required for deployment.

This is a one-time effort, but as noted above, you'll need to address the problem in the code anyway....

This is intentional and relates to Access, not Windows.

Last year a developer reported to Microsoft that setting the Allow Special Keys option to No was preventing VBA from stopping at breakpoints set by a developer, which was obviously undesirable.

Thas was fixed, so now setting Allow Special Keys to No prevents a user from breaking into code with Ctrl+Break, but does not prevent VBA from stopping at breakpoints, or Stop statements.

So, this change was intentional, and is a demonstration of how making any change, even if it is obviously correct, can cause someone some pain.

So, this someone is you, and I guess you'll have to adapt, as most developers, including me, as well as Microsoft will vote for the current behaviour not to be reverted.

As the person responsible for reporting the unwanted behaviour with Special Keys last year, I'm happy to take responsibility for the change that led to your current issue.

The fix done by the team solved a long-standing issue with unwanted behaviour affecting many developers / users when the use of special keys was disabled.

Specifically, problems can occur if special keys are disabled during development work. For example, unticking Allow special keys prevents the use of Ctrl+Break to stop code. This is intentional.

However it has the unintended side effect of preventing breakpoints and the use of Stop from pausing execution.

This means you cannot debug code for problems with the special keys option unticked. For full context to this issue, please see my article: https://isladogs.co.uk/breakpoint-special-keys/

By comparison, your usage seems very marginal / unusual

I'm confident what you are seeing has nothing to do with Windows 11. That observation may be coincidental with the fix being applied in Access version 2305 (released on 1 June 2023)