AllowFullMenus=False: Putting "Export" back on "File" Menu?

[PeteCresswell]

Citrix environment.

Some users's MS Access' "File" menus lack a number of choices - among
them "Export".

I've got some AutoExec code that runs depending on user's privileges
and that's where the problem appears to be.

For some users, I have been setting AllowFullMenus=False, which makes
Export and a few other options disappear from the File dropdown.

There are other menu items that I want suppressed for those users, but
everybody needs File | Export.

Is there some more granular method? Maybe something where I set
AllowFullMenus=False and then go back and patch up the File menu?
------------------------------------------------------------------------------------------------------------------------------------------
Public Sub DeveloperMenusToggle(ByVal theVisibilitySwitch As Boolean)
1000 DebugStackPush mModuleName & ": DeveloperMenusToggle"
1001 On Error GoTo DeveloperMenusToggle_err

' PURPOSE: To give/remove user access to the various things used by
' developer - like DB window, F11, Immediate, Code...and
so-forth
' ACCEPTS: Visibility switch: True=Show, False=Hide

1003 Dim myToolBarSwitch As Long

1010 If theVisibilitySwitch = True Then
1011 myToolBarSwitch = acToolbarYes
1012 Application.SetOption "Key Assignment Macro", "AutoKeys"
1013 Else
1014 myToolBarSwitch = acToolbarNo
1015 Application.SetOption "Key Assignment Macro", ""
1019 End If

1020 With DoCmd
1021 .ShowToolbar "Database", myToolBarSwitch
1022 .ShowToolbar "Form View", myToolBarSwitch
1023 .ShowToolbar "Query Design", myToolBarSwitch
1024 .ShowToolbar "Formatting (form/report)", myToolBarSwitch
1029 End With

1991 With CurrentDb
1992 .Properties("AllowFullMenus") = theVisibilitySwitch
1993 .Properties("AllowSpecialKeys") = theVisibilitySwitch
1994 .Properties("AllowBuiltinToolbars") = theVisibilitySwitch
1999 End With

DeveloperMenusToggle_xit:
DebugStackPop
On Error Resume Next
Exit Sub

DeveloperMenusToggle_err:
BugAlert True, ""
Resume DeveloperMenusToggle_xit
End Sub
------------------------------------------------------------------------------------------------------------------------------------------

 

[Albert D. Kallal]

I'm not sure if I really have a great simple solution for you. I can only
say that I have quite a few applications I deployed over the years to many
clients where I use custom menus.

I think the key concept in the above point was I've always build my own
custom menus, and of trying to mess around with a built in ones is something
I just avoided.

I also believe the above is less code. In my startup code in these
applications that I have deployed commercially for many years, I've never
actually had any startup code that hides any the built in menus. I simply
specify a main menu in the startup, and away I go. There's a few little tips
and tricks you have to use during the development process to ensure that
stray menus and toolbars don't show, but once that's done, then simply
setting the custom menu bar in the startup options does the trick for me.

For any additional special menu options, I simply enable or disabled a few
of the options in the custom menu bars (For those users that have additional
rights and privileges). For the most part I don't use code to hide or show a
full menu bars - especially the built in ones.

I cannot say the above is going to help your situation, but no one else's
jumped into this post yet, so I can only give you my 2¢ worth here. The
above 2¢ worth might not be of help to you, but that's the approach that's
worked well for me. I just never had great luck with hiding and showing and
having a whole bunch of code to control what "built in" menu bars will be
displayed. Simply hide them all, and build your own custom ones, and then
you'll have better control. Not only will you have better control, but your
whole application will Seamlessly in the runtime environment.

 

[PeteCresswell]

I'm not sure if I really have a great simple solution for you. I can only
say that I have quite a few applications I deployed over the years to many
clients where I use custom menus.

I cannot say the above is going to help your situation, but no one else's
jumped into this post yet, so I can only give you my 2¢ worth here. The
above 2¢ worth might not be of help to you, but that's the approach that's
worked well for me. I just never had great luck with hiding and showing and
having a whole bunch of code to control what "built in" menu bars will be
displayed. Simply hide them all, and build your own custom ones, and then
you'll have better control. Not only will you have better control, but your
whole application will Seamlessly in the runtime environment.

Thanks.

Actually that *was* helpful bc until now I have avoided custom menus
for the reverse of the reasons you stated: i.e. I figured they were
needlessly complicating the app..... all the better to bill more
hours, but not in the service of my valued customers.

I guess it's time for Yours Truly to start re-thinking his
assumptions.

Just a quickie: Do you have any apps where you have just one menu/
set of menus (I'm not sure of the proper syntax...) and use the same
menu/set of menus for each and every screen?

 

[Albert D. Kallal]

Just a quickie: Do you have any apps where you have just one menu/

set of menus (I'm not sure of the proper syntax...) and use the same
menu/set of menus for each and every screen?

The above is actually a really great question.

I don't use the same set of menus for in each and every screen, but I can
say in an applications where say I have lots of forms, I might have 3 or 4
major forms with a speical featuress. in other words and most applications
would use the wind up with one form that has quite a bit code and as a
significant amount of heavy lifting in terms of the application features.
this form will likely have a custom menu built just for that form, and
remember I tend to use the drag and drop ability of access to build those
custom menus, I don't use code. furthermore for these menus, I always use
the other property sheet of the form to set what custom menu is to be
displayed. the reason for this is very simple, I want different forms when
they show or the user has several forms open at the same time, simply
bringing the focus to different forms what automatically switch the menu
bars for you without any coding. so when possible, I do use the other
property sheet to set what menu is going to be displayed for a given form.

So, now, given the above, your question was to lay off to specify the same
menu bar for many forms?

In the above I mention we have 3-4 very rich customized forms, but the
application might have another 25 simple basic forms that has for the most
part just basic data entry features on the form. In these cases almost all
these forms actually have the same menu bar specified. That menu bar will
have the basic "edit/cut/paste".

Here is some screen shots:

Just take a quick look at 1st screen shot (custom menu) and then the LAST
one..that is a menu bar I use for almost every other form in the applcaion.

Here is anohter custom menu bar with the delete option:

http://www.kallal.ca/ridestutorialp/drivers.htm

The last screen shot shows a simple menu bar.

One last tip:

All of my custom menu bars tend to run VBA code in the appropriate form. So,
all my forms have a routine called

Public function MyDelete()

In the above when the user selects the option to delete records in the
custom menu bar, the code for the delete which run will be from the form
that has the focus. If the form that has the focus does not have this
routine, then a standard module is searched and that routine is then run.
What this means is that for ten forms I can have a global catch all delete
routine that is generic and works for almost all forms when they choose
edit-->delete reocrd.

For the one special form that's completely different and has to check
special things such as child records etc, or perhaps certain information
that does not allow deletion of the record, then I simply place the special
deletion code inside of the forms code module and that function will run.

So the above in a nutshell is why you can use one typical custom menu for
most all your forms or a at least vast majority of them. And, you can have
different code run for the custom menu by simply placing the code in the
form's code module as opposed to a standard regular module .

Keep in mind you never place/use the forms qualifier in the on-action. so,
just use the function name in the on-action like:

=MyDelete()

The above will then run a public function in the current format has the
focus, and as mentioned if the current form doesn't have that routine called
mydelete(), then that same name is run from a standard code module.
Essentially what this means is then you can code all of your features for
your menu bar in a global module for "most" of the forms that are standard,
and for the few exceptions, put the same function names and speical code in
the forms code module....