Basing a menu item on a procedure instead of a function?

[Richard Hollenbeck]

Back in the old days before I started learning about menubars (the day
before yesterday,) I based all my operations on command buttons on the
forms. Now the forms are all cluttered up with buttons so I'm beginning to
clean it up using menubars.

So far, I haven't used ANY macros. But some some websites, as well as my
book, seems to indicate that it is necessary to base the menubar on a macro
with each menu's first instruction being AddMenu.

I have made three menus without any macros that seem to work fine (until
now.) Some of my operations don't use forms, but use input boxes and DAO
queries. These operations were stuck in the code behind the forms. I have
a module in the Modules section called, "basMenuStu ff," where I'm putting,
of all things, menu stuff. In there I made a subroutine called "NewGroup."
All this does is gets a new group name and group weight from two different
functions, then get a course code from an open form. From these three
pieces of data, it does an INSERT INTO query. That's it. But I got the
following error in a MsgBox:

----------------------------------------------
The object doesn't contain the Automation object "NewGroup."

You tried to run a Visual Basic procedure to set a property or method for an
object.
However, the component doesn't make the property or method available for
Automation operations.

Check the compenent's documentation for information on the properties and
methods it makes available for Automation operations.
|OK|
----------------------------------------------

Is it possible that a menu item cannot be based on a subroutine but must be
based on either in a macro, form, or function?

[MGFoster]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The easiest way is to set the menu bar item to call a macro. The macro
will be a RunCode macro that calls a VBA function.

You can, also, set the menu bar item's "OnAction" event to a VBA
function, but you have to set up the call programmaticall y. You'd use
the CommandBar objects & related methods, properties.

--
MGFoster:::mgf0 0 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQYFFUoechKq OuFEgEQJkhwCg/nm3HTt93ZAdp4eD +78rGkbOj5oAnRj C
1EDlIiIV/PTO4G6bfNV8QSVf
=OXzi
-----END PGP SIGNATURE-----
Richard Hollenbeck wrote:

Back in the old days before I started learning about menubars (the day
before yesterday,) I based all my operations on command buttons on the
forms. Now the forms are all cluttered up with buttons so I'm beginning to
clean it up using menubars.

So far, I haven't used ANY macros. But some some websites, as well as my
book, seems to indicate that it is necessary to base the menubar on a macro
with each menu's first instruction being AddMenu.

I have made three menus without any macros that seem to work fine (until
now.) Some of my operations don't use forms, but use input boxes and DAO
queries. These operations were stuck in the code behind the forms. I have
a module in the Modules section called, "basMenuStu ff," where I'm putting,
of all things, menu stuff. In there I made a subroutine called "NewGroup."
All this does is gets a new group name and group weight from two different
functions, then get a course code from an open form. From these three
pieces of data, it does an INSERT INTO query. That's it. But I got the
following error in a MsgBox:

----------------------------------------------
The object doesn't contain the Automation object "NewGroup."

You tried to run a Visual Basic procedure to set a property or method for an
object.
However, the component doesn't make the property or method available for
Automation operations.

Check the compenent's documentation for information on the properties and
methods it makes available for Automation operations.
|OK|
----------------------------------------------

Is it possible that a menu item cannot be based on a subroutine but must be
based on either in a macro, form, or function?

[Albert D. Kallal]

"Richard Hollenbeck" <ri************ ****@verizon.ne t> wrote in message
news:iKagd.1403 6$5O4.2722@trnd dc07...

Back in the old days before I started learning about menubars (the day
before yesterday,) I based all my operations on command buttons on the
forms. Now the forms are all cluttered up with buttons so I'm beginning
to
clean it up using menubars.
Great stuff. I also find that menus can significantly clean up those forms.

So far, I haven't used ANY macros. But some some websites, as well as my
book, seems to indicate that it is necessary to base the menubar on a
macro
with each menu's first instruction being AddMenu.

No, not all. As a general rule, I simply have all my menus call custom code.
That code can be in the forms module, or a general module.

In most cases, if the menu bar code is for the current form..then it makes
sense that the code belongs in the forms module..and not some other module.

Here is a few other points:

You do in fact have to use a function name..and you can't use a sub-name. If
you already got some extensive sub code written, you then just create a
function that calls the code.

The functions in the form have to be public. For example, MOST of my forms
have some custom delete code, and I ALWAYS call it

Public Function MyDelete
The advance of ALWAYS using the same function name should not be missed. If
you have a custom menu bar, then to call the forms code you put the function
name in the menu "on action" (I create all my menus via drag and drop with
the mouse by the way!).

So, to run the MyDelete function, you just type in the following into the
menus "on action" property setting:

=MyDelete()

The above goes in the on-action. What is very cool here is that this means
that ONE menu bar can apply to several forms. Which ever form has the focus
will have its public function called MyDelete() run. And, if the form does
NOT have a public function, then a function of the above name in a standard
module is tried to run. So, for example, you could write a common delete
function that applies to ALL forms,a and place the code in a standard
module. However, lets assume you have one form that needs special
treatment...you just then put a public function in the forms module of the
same name..and that one gets run!

Further, a LOT of my menu code is in standard modules, and some is in forms
module. If the code goes into a forms module, then you code can use things
like:

me.Refresh

or me.InvoiceNumbe r

However, for code in a general module..you can't use "me", so you what you
do is simply pick up the currently active form.

So, for "general" code, my code almost always grabs the active form...here
is a example for a invoice print option:

Dim tblgroupid As Long
Dim frmActive As Form

Set frmActive = Screen.ActiveFo rm

tblgroupid = frmActive.frmMa inClientB.Form! ID

If frmActive.Invoi ceNumber = 0 Then
frmActive.Invoi ceNumber = nextinvoice
frmActive.Refre sh
End If

DoCmd.OpenForm "guiInvoicePrin t", , , "id = " & tblgroupid
So, you can see that the trick here is to "pick up" the currently active
screen, and make a form ref that you can use. As mentioned, if you place
your menu bar code in the actual forms module..then you can use "me".

Here is some other ideas and screen shots of menu bars I made in ms-access
(all were created via drag and drop).

http://www.attcanada.net/~kallal.msn...erFriendly.htm
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com
http://www.attcanada.net/~kallal.msn

[Richard Hollenbeck]

Thank you. Great reply!
Rich

"Albert D. Kallal" <Pl************ *******@msn.com > wrote in message
news:k8mgd.4849 2$%k.19372@pd7t w2no...

"Richard Hollenbeck" <ri************ ****@verizon.ne t> wrote in message
news:iKagd.1403 6$5O4.2722@trnd dc07...

Back in the old days before I started learning about menubars (the day
before yesterday,) I based all my operations on command buttons on the
forms. Now the forms are all cluttered up with buttons so I'm beginning
to
clean it up using menubars.
Great stuff. I also find that menus can significantly clean up those

forms.

So far, I haven't used ANY macros. But some some websites, as well as my book, seems to indicate that it is necessary to base the menubar on a
macro
with each menu's first instruction being AddMenu.
No, not all. As a general rule, I simply have all my menus call custom

code. That code can be in the forms module, or a general module.

In most cases, if the menu bar code is for the current form..then it makes
sense that the code belongs in the forms module..and not some other module.
Here is a few other points:

You do in fact have to use a function name..and you can't use a sub-name. If you already got some extensive sub code written, you then just create a
function that calls the code.

The functions in the form have to be public. For example, MOST of my forms
have some custom delete code, and I ALWAYS call it

Public Function MyDelete
The advance of ALWAYS using the same function name should not be missed. If you have a custom menu bar, then to call the forms code you put the function name in the menu "on action" (I create all my menus via drag and drop with
the mouse by the way!).

So, to run the MyDelete function, you just type in the following into the
menus "on action" property setting:

=MyDelete()

The above goes in the on-action. What is very cool here is that this means that ONE menu bar can apply to several forms. Which ever form has the focus will have its public function called MyDelete() run. And, if the form does
NOT have a public function, then a function of the above name in a standard module is tried to run. So, for example, you could write a common delete
function that applies to ALL forms,a and place the code in a standard
module. However, lets assume you have one form that needs special
treatment...you just then put a public function in the forms module of the
same name..and that one gets run!

Further, a LOT of my menu code is in standard modules, and some is in forms module. If the code goes into a forms module, then you code can use things
like:

me.Refresh

or me.InvoiceNumbe r

However, for code in a general module..you can't use "me", so you what you
do is simply pick up the currently active form.

So, for "general" code, my code almost always grabs the active form...here
is a example for a invoice print option:

Dim tblgroupid As Long
Dim frmActive As Form

Set frmActive = Screen.ActiveFo rm

tblgroupid = frmActive.frmMa inClientB.Form! ID

If frmActive.Invoi ceNumber = 0 Then
frmActive.Invoi ceNumber = nextinvoice
frmActive.Refre sh
End If

DoCmd.OpenForm "guiInvoicePrin t", , , "id = " & tblgroupid
So, you can see that the trick here is to "pick up" the currently active
screen, and make a form ref that you can use. As mentioned, if you place
your menu bar code in the actual forms module..then you can use "me".

Here is some other ideas and screen shots of menu bars I made in ms-access
(all were created via drag and drop).

http://www.attcanada.net/~kallal.msn...erFriendly.htm
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com
http://www.attcanada.net/~kallal.msn