If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
AllowFullMenus=False: Putting "Export" back on "File" Menu?
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 ------------------------------------------------------------------------------------------------------------------------------------------ |
#2
|
|||
|
|||
AllowFullMenus=False: Putting "Export" back on "File" Menu?
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. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#3
|
|||
|
|||
AllowFullMenus=False: Putting "Export" back on "File" Menu?
On Jul 9, 2:34*pm, "Albert D. Kallal"
wrote: 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? |
#4
|
|||
|
|||
AllowFullMenus=False: Putting "Export" back on "File" Menu?
"PeteCresswell" wrote in message
news:7e892f59-4578-4d1a-a164- 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.... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
Thread Tools | |
Display Modes | |
|
|