Show Menus/Toolbars on Startup

[cefrancke]

I have set the Startup properties to the following...

All menus, toolbars, etc are turned off plus these are unchecked
Allow Full Menus
Allow Built-in Toolbars
Allow Default Shortcut Menus
Allow Toolbar/Menu Changes
Use Access Special Keys

For admin users...
I would like to run some VB code in my Main startup form (OnOpen) to
show the default menu/toolbars as if the startup properties were not
set.
However I would like to leave the startup properties in tact, in case a
non-admin user logs in.

I use...

If Admin then
CommandBars("Database").Visible = True ' Trying to show a menu
else 'non-admin
'non-admin code
end if


The issues are...

1. The CommandBar "Menu Bar" is displayed after the Main form is
visible, even with the startup properties set to turn off all
menus/toolbars. The menu seems limited and only related to forms and
records. The menu is definately not like the standard startup menu for
an Access database.
This seems to contradict what the startup properties suggest.

2. Using CommandBars("Database").Visible = True in the OnOpen event for
the case of admins does not show the toolbar or any other toolbar,
though I have not tried them all. I tried "Form View", "Formatting
(Form/Report)".

I do notice that the menus show up for a short duration along with the
normal default menus and then disappear after the Main form is visible.
It seems that the startup properties take effect after the Main form is
visible.

However, without restarting Access, if I restart the form (I enabled
the database window) the menus show up as coded.
But, the menus dont behave appropriately to the context of the window,
ie the "Form View" menu remains even if I click on the Database window.


Is there a way to bring up the default menu behavior for the admin case
without having to reset the startup properties and restarting?

TIA

 

[Albert D. Kallal]

I would like to run some VB code in my Main startup form (OnOpen) to

show the default menu/toolbars as if the startup properties were not
set.

Hum, the above is not the best, and not much workable. The problem here is
that you are setting up a application to hide all of the ms-access
interface. This ob ilairy assumes that you might be considering using the
runtime package, but even if you are not, it does hint that your "end" users
are not required to be ms-access developers. (it seems kind of silly to
produce a product to users, and then turn around and tell them they have to
go off and take some ms-access courses here). If users need full menus etc,
then these types of users are a GRAND CANYON of differencing then end users.

It is not clear at all what these "power" users need in terms of modifying
the application, but as a general rule, this approach does not work very
well. If you spend any amount of time developing in ms-access, then you will
quickly lean that end users should get a mde. (and, I assume you split your
application, as how else would update, and fix bugs in your
application????).

So, are you distributing a mde to your users (and why not?).

I have set the Startup properties to the following...

All menus, toolbars, etc are turned off plus these are unchecked
Allow Full Menus
Allow Built-in Toolbars
Allow Default Shortcut Menus
Allow Toolbar/Menu Changes
Use Access Special Keys

If you turned everything off, then the best approach here is make custom
menus for everything. It makes NO sense to try and design an application
where you sort of use some custom menus..and then all of a sudden want to
use the built in menus. It is not clear if you provided a custom menu after
turinong evertong off as above (how will your appction work??). So, there is
no NO reason to expose the built in menus if you are tyring to hide them in
the first palce.

1. The CommandBar "Menu Bar" is displayed after the Main form is
visible, even with the startup properties set to turn off all
menus/toolbars. The menu seems limited and only related to forms and
records. The menu is definately not like the standard startup menu for
an Access database.
This seems to contradict what the startup properties suggest.

If you are turning everything off, then it is assumed you are also supplying
your OWN custom menu bar. If you forget that step, then disabling all the
built in menus leaves ms-access complete confused as to what it should
display. I have a simply example with some custom menu bars that threw
together in a VERY short time. Try downloading and running my example here:

http://www.members.shaw.ca/AlbertKallal/msaccess/DownLoad.htm


Grab the 3rd one. "ms-access inteface hidden"

Try running this example.
Note how all of the ms-access interface is hidden, and NO CODE was required.
If you have to start writing a whole whack of code to hide, and un-hide
menus..then you take a costly approach, and with the example above you can
see it not needed.

2. Using CommandBars("Database").Visible = True in the OnOpen event for
the case of admins does not show the toolbar or any other toolbar,
though I have not tried them all. I tried "Form View", "Formatting
(Form/Report)".

As I mentioned, you went and turned off all the options in the
tools->startup..so, what would you expect?

Is there a way to bring up the default menu behavior for the admin case
without having to reset the startup properties and restarting?

Hum, you could check your startup properties..and allow built in menus, but
STILL specify a main application menu in the startup. This should allow you
to toggle on/off built in menus, but not show the built in ones at startup.
So, I think the trick/solution to your woes is to specify a application menu
bar in the startup.

I think the best solution here is to simply build a few of the extra menus
that you need..and then don't worry about the built in ones. This also works
better with a mde, and in fact even better if you every decide to package
the program with the royalty free runtime system (that allows you to install
your application without ms-access previously being installed on the target
computer).

Anway...try that sample of mine....

And, here is some more screen shots of ms-access menus that I made.., and
some hints of why I like menus

http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm

 

[cefrancke]

Hummm...You are insulting and silly...you need to go away...and work on
your english.

The question is plain and clear.
However, Your explanations are as wordy as your web site.
You make too many assumptions.
If you have a question about my question, then ask it.
You tend to spend more time criticizing what you think my purpose is
instead of answering the question.

You need to stay focused.
Do you have problems getting along with others at work?
Do they tend to keep you separated from interaction with others?

It's non of your business "WHY" I'm doing it, the question regards
whether or
or not it can be done.

You spent more time conjecturing on what I'm up to rather than address
any of the issues.
Thanks for ruining my post. Now everyone thinks it's been answered.

Please learn from this and dont waste our time with your philosophy.
If you know the answer then answer, otherwise, let it go, your not
obligated to respond.

 

[ik]

I have set the Startup properties to the following...

All menus, toolbars, etc are turned off plus these are unchecked
Allow Full Menus
Allow Built-in Toolbars
Allow Default Shortcut Menus
Allow Toolbar/Menu Changes
Use Access Special Keys

For admin users...
I would like to run some VB code in my Main startup form (OnOpen) to
show the default menu/toolbars as if the startup properties were not
set.
However I would like to leave the startup properties in tact, in case a
non-admin user logs in.

I use...

If Admin then
CommandBars("Database").Visible = True ' Trying to show a menu
else 'non-admin
'non-admin code
end if


The issues are...

1. The CommandBar "Menu Bar" is displayed after the Main form is
visible, even with the startup properties set to turn off all
menus/toolbars. The menu seems limited and only related to forms and
records. The menu is definately not like the standard startup menu for
an Access database.
This seems to contradict what the startup properties suggest.

2. Using CommandBars("Database").Visible = True in the OnOpen event for
the case of admins does not show the toolbar or any other toolbar,
though I have not tried them all. I tried "Form View", "Formatting
(Form/Report)".

I do notice that the menus show up for a short duration along with the
normal default menus and then disappear after the Main form is visible.
It seems that the startup properties take effect after the Main form is
visible.

However, without restarting Access, if I restart the form (I enabled
the database window) the menus show up as coded.
But, the menus dont behave appropriately to the context of the window,
ie the "Form View" menu remains even if I click on the Database window.


Is there a way to bring up the default menu behavior for the admin case
without having to reset the startup properties and restarting?

TIA

 

[Albert D. Kallal]

Thanks for ruining my post. Now everyone thinks it's been answered.

Oh, gee, end of the world is it? Your post had not been answered by anyone
for a day..and was well in the queue for scrolling off the screen. I decided
to take a stab at it. Nothing is stopping you from asking again. The fact
of the matter is that 90%+ of the posts that are CLEAR and MAKE SENSE get
answers IN LESS THEN ONE HOUR. So, one has to ask why your post went for 24+
hours with NO one answer here? Further, you are free to take my advice, or
dump it. However, do remember that this advice is free...and it would not be
a good idea to bite the hand that is using free time here.

If you have a question about my question, then ask it.

I certainly did have a question...in fact a had a few, and you seem to be
willing to waste even more time here.....

The questions I had were:

Are you running a split database? This has MUCH ramifications on solutions
to your problem. For example, you might consider distribution two
versions..one for admin users, and another for regular users. Or, even
better would be to maintain ONE version, but distribute a mde to those users
that are to see none of the ms-access interfaces (or, at the very least NOT
be able to modify forms/reports). . Either way, this is a significant
question, and speaks volumes about your development process. There is a old
saying about bringing a horse to water.......

So, have you consider some the possible solutions by using a split database,
and further possibilities arise by distributing a mde, or mdb to those
users? And, further, some of my advice needs to know if you are using a
split database (or are willing to consider a split data...which is a MUST do
if you are going multi user). Again, why should I give a whole ton of advice
based on a particular setup that you might not even have!! So, as far as you
criticizing me for making assuming...no, I shorted my post
significantly..and
asked for clarification on the split issue (for some reason...this question
went
right over your head.....and worse, I did not make a pre judgment on if you
split...but I clearly did ask if you are running a split system).

Another question mine was:

It is not clear at all what these "power" users need in terms of modifying

the application, but as a general rule, this approach does not work very
well

Once again, you make no efforts as to what, or why some users need more
menus, and thus don't answer the above question. I simply asked for
clarification on why some users need to use the ms-access menus.

You are asking me to please answer the question. That is like a patient
going
to a doctor, and asking for pain killers. It might in fact be good that
the doctor asks where the pain is coming from before giving out the pain
killers (the patient then answers that the nail current pierced through the
foot is the source of the pain).

So, be it medicine, or the software development process, the answer is going
to be based on a series of questions. To think that all medicine can be
answer with a simple question, or questions concerning software can be
simply
answered is a VERY poor approach on your part. I could be a crappy
doctor, and just write out the prescription for pain kills...but I am
sorry..that is just not my style. In fact, it is impossible to give good
advice without first ascertaining some reasons as to what the problem is.

You tend to spend more time criticizing what you think my purpose is
instead of answering the question.

Gee, and you now made zero efforts to answer any of my questions? Did you
not just spend a whole post criticizing me? (gee, what is that saying about
calling the kettle black??...yikes..time to hold up a mirror eh??). I would
have say you also spend more time critiquing advice, and only want to hear
what you want!!

It's non of your business "WHY" I'm doing it, the question regards
whether or
or not it can be done.

In fact, good advise does requite I ask questions. As the bad doctor example
shows, you can't take the mentally of a two year old here, and simply ask
for the pain killers. A good doctor, or a good consultant WILL IN FACT ask
why, and ask more questions, as that is the ONLY WAY to give a good answer.
I feel sad, and sorry if you can't understand this concept at all.

If you know the answer then answer, otherwise, let it go, your not
obligated to respond.

My answer to the question was that you should make a custom main menu..and
that SHOULD enable you to better control, and better turn off/on the built
in menus. I will repeat that answer:

Hum, you could check your startup properties..and allow built in menus, but

STILL specify a main application menu in the startup. This should allow you
to toggle on/off built in menus, but not show the built in ones at startup.
So, I think the trick/solution to your woes is to specify a application menu
bar in the startup.
<quote>

So, the above is about the best answer...and in fact is THE ONLY answer you
got.

However, I don't want to rain to much on your pride here, and nothing is
stopping you from trying another post....

 

[felix marrero]