Menu Bar doesn't stay disabled
Greetings, reader of this question,
I use Access8 (1997) to set up a small registration system. To avoid users to ravage my application, I created my own toolbars and disabled the build in commandbar called "Menu Bar". This "Menu Bar" isn't a menubar at all, it's a toolbar.
Now, to disable this menubar I used the "Start up" function in the "Extra" menu (I hope your local versions use these menu and function names), but also included in th starting up forms this code:
Application.Commandbars("M
Then, I told my forms to use my toolbars. Now, this works quite nice. But, when mistakenly touching the "Alt" button, the menu reappears, menu item by menu item. Same story for the "F10" button. First you see a small rectangle, then when you start moving the cursor buttons, the whole menu becomes visible AND ACTIVE!
So I've tried a few things. I chose to disable ALL commanbars. This however, resulted in a disappearing of commandbars for the next person to use Access97, whether this person used my app or not. Next, I created my own menubar and told my app to use it, but that meant constantly two 30 point bars on screen, one menu bar and one filled with toolbars, not forgetting the 12 point title bar that should not be removed at all. Three of these bars clutter my screen and the screen really isn't that big. Besides, the menubar is hardly filled (two items) so it takes up empty room.
Question: do you know an elegant way to dispose of this built in menu bar, so that even a misfortunate "Alt" button doesn't activate it? The "F10" key can be silenced using an AutoKeys macro, but the "Alt" key cannot. Also, keep in mind that not every person has a Developpers Kit (I don't), so not everyone is able to create runtime versions (I'm not). However, I'd like to know whether runtime versions show the same problem or not.
Imagine!
I use Access8 (1997) to set up a small registration system. To avoid users to ravage my application, I created my own toolbars and disabled the build in commandbar called "Menu Bar". This "Menu Bar" isn't a menubar at all, it's a toolbar.
Now, to disable this menubar I used the "Start up" function in the "Extra" menu (I hope your local versions use these menu and function names), but also included in th starting up forms this code:
Application.Commandbars("M
Then, I told my forms to use my toolbars. Now, this works quite nice. But, when mistakenly touching the "Alt" button, the menu reappears, menu item by menu item. Same story for the "F10" button. First you see a small rectangle, then when you start moving the cursor buttons, the whole menu becomes visible AND ACTIVE!
So I've tried a few things. I chose to disable ALL commanbars. This however, resulted in a disappearing of commandbars for the next person to use Access97, whether this person used my app or not. Next, I created my own menubar and told my app to use it, but that meant constantly two 30 point bars on screen, one menu bar and one filled with toolbars, not forgetting the 12 point title bar that should not be removed at all. Three of these bars clutter my screen and the screen really isn't that big. Besides, the menubar is hardly filled (two items) so it takes up empty room.
Question: do you know an elegant way to dispose of this built in menu bar, so that even a misfortunate "Alt" button doesn't activate it? The "F10" key can be silenced using an AutoKeys macro, but the "Alt" key cannot. Also, keep in mind that not every person has a Developpers Kit (I don't), so not everyone is able to create runtime versions (I'm not). However, I'd like to know whether runtime versions show the same problem or not.
Imagine!
ASKER
Thank you, perove,
But this kind of wavering already came to mind. It works, but it is not elegant. What I'm looking for is not a workaround, it's a solution. Workarounds have to be unworkarounded, and if the app isn't shut down correctly, I can't get the settings back the way they should.
Imagine!
But this kind of wavering already came to mind. It works, but it is not elegant. What I'm looking for is not a workaround, it's a solution. Workarounds have to be unworkarounded, and if the app isn't shut down correctly, I can't get the settings back the way they should.
Imagine!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Greetings, brewdog,
This works!
KeyPreview = True
Altkey needs to be handled: it isn't vbKeyAlt or something, Access didn't create any constants for it. But it has an integer KeyCode: number 18!
So, in KeyDown, I code:
If KeyCode = 18 then KeyCode = 0
and the alt key is disabled!
Now to all other users of Access: keep it in mind! This menu bar breach is a serious breach in Access security!
You want to know why I didn't come up with the KeyPreview property? I use the Dutch version. Translated from Dutch, the name of this property is KeyExample (Dutch: "Toetsvoorbeeld"). Seriously Microsoft, an example ain't no preview in this context!
More translation problems: KeyCode constants are words Access uses to name keys from the keyboard. It is translated, however, as if the Key were a key to open a lock or a door, or as if it were some sort of primary key. I hope Microsoft takes care of their translations in the NEAR future.
Many thanks, brewdog,
Imagine!
This works!
KeyPreview = True
Altkey needs to be handled: it isn't vbKeyAlt or something, Access didn't create any constants for it. But it has an integer KeyCode: number 18!
So, in KeyDown, I code:
If KeyCode = 18 then KeyCode = 0
and the alt key is disabled!
Now to all other users of Access: keep it in mind! This menu bar breach is a serious breach in Access security!
You want to know why I didn't come up with the KeyPreview property? I use the Dutch version. Translated from Dutch, the name of this property is KeyExample (Dutch: "Toetsvoorbeeld"). Seriously Microsoft, an example ain't no preview in this context!
More translation problems: KeyCode constants are words Access uses to name keys from the keyboard. It is translated, however, as if the Key were a key to open a lock or a door, or as if it were some sort of primary key. I hope Microsoft takes care of their translations in the NEAR future.
Many thanks, brewdog,
Imagine!
(you cannot see it in the list but ...)
perove