Changing menus on the fly (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Finder Help Menu
Next thread: RecordSets in RB4.5


RE: When is CompareRows done?   -   Hadley, Joshua
  Changing menus on the fly   -   Dr. Anthony G. Rich
   Re: Changing menus on the fly   -   Steve Schacht
    Re: Changing menus on the fly   -   Scott Griebel
    Mailing List Archives ?   -   Ron Zutz
   Re: Changing menus on the fly   -   William Cannings
    Re: Changing menus on the fly   -   Dario Guerrero

Changing menus on the fly
Date: 29.08.02 22:01 (Thu, 29 Aug 2002 16:01:52 -0500)
From: Dr. Anthony G. Rich
In this lengthy post I'm suggesting a small modification to RB
that I think would allow an app to change menus on the fly --
something that RB evidently can't currently do. I'm asking
for public comments on whether my suggestion would work. If
you're not interested in this topic, please skip this message.

I'd like to port an app in which the menus in the menubar
change as the app runs, depending on which of several
modes is selected in the app. Lots of apps do that. For
example, in FileMaker Pro, the menus change on the fly when
the user switches from Browse Mode to Layout Mode.

I'd like to use RB to do the port, but according to Matt
Neuburg's RB book, there's no way in RB to change the menus
while an app is running. Matt points out that "an argument
can be made that an application that changes its menus
on the fly is confusing and poorly planned."

Well, I'm interested in making software, not arguments. :)

It seems to me that it would be possible for an app to change
menus on the fly if only one small modification were made to
REALbasic: if the "text" property of a menu (the menu's name
that shows in the menubar) were settable and gettable in code.
Right now that string can only be set manually at development
time; it can't be examined or changed at runtime.

If that modification were made to REALbasic, here's how I
think changing menus on the fly could be made to work:

DELETING A MENU
---------------
Suppose we wanted to delete the rightmost menu in an app on the
fly. Let's say for the sake of example that:

1. The rightmost menu is the fifth menu in the menubar.

2. That menu is currently the Window menu, a dynamic menu
that lists all the windows the app currently has open.

3. Its RB internal "name" property (used by the code, as shown
in the IDE's Properties window) is "FifthMenu". [Please note
that this property can't currently be accessed in RB code;
that's the modification to RB I'm proposing.]

4. Its text property (the menu name that shows in the menubar,
also listed in the Properties window) is currently "Window".

To "delete" that menu, all the app would need to do (I assume)
would be to make the menu name "Window" disappear from the menubar,
thus making that menu invisible amd therefore unclickable. (If
necessary, the invisible menu could also be disabled so that no
"hot spot" remains on the menubar.)

To hide the menu, the app would just need to be able to execute
this one line of code, which is currently illegal in RB because
referring to a menu's internal name (FifthMenu) isn't currently
supported:

FifthMenu.text = "" // Set the menu name to the empty string.

REPLACING A MENU
----------------
Suppose we later wanted to replace that "deleted" (invisible)
Window menu with a new one. Let's say we want to replace it
with a different dynamic menu, like a Font menu. The app could
change the menu name via code:

FifthMenu.text = "Font"

...and then repopulate the existing menuitems with font names
instead of window names.

Of course, the app would first need to make the number of menuitems
equal to the number of installed fonts, not the number of open
windows. But that's easy to do in RB right now, by dynamically
adding or deleting menuitem controls, depending on whether there
happen to be more installed fonts or open windows at the moment.

HANDLING A MENUITEM CLICK
-------------------------
Now let's say that during execution, the user pulls down
this new Font menu (which used to be the Window menu) and
clicks on what is now a Font name. In the menu handler for the
fifth menu, the code would examine the current menu name to
decide whether to call a Font method or a Window method, like
this (again, a reference to FifthMenu is currently illegal):

if FifthMenu.text = "Font" then // Is menu #5 the Font menu?
<handle font choice>
else // No, it's the Window menu right now...
<handle window choice>
end if

ADDING MENUS ON THE FLY
-----------------------
REALbasic can't currently create new menus on the fly, but it
doesn't need to, because that effect would be easy to fake.

During development, one could simply create the maximum number
of menus that the app would ever have showing at once when it
runs -- nine, say. Then as the app runs, when fewer menus
should be showing (five, say), the rightmost four menus could
be made invisible, as described above in "Deleting a Menu".

Later, when more menus should show (let's say seven), the
leftmost two of the four invisible-but-existing menus could
be named to something visible, then repopulated with menuitems,
as described above in "Replacing a Menu".

WHAT ABOUT STATIC MENUS?
------------------------
I think static menus could be handled exactly the same way,
by making *every* menu a dynamic menu.

An app could simply keep an unchanging list of the menuitem
names that appear in each static menu. Then during execution,
when a static menu needs to be changed -- either to a different
static menu, or to a dynamic one -- the menu handler would
first clone or delete existing dynamic menuitems to make the
menu length equal to the number of names in the new menu.
Then it would overwrite the old menuitem names with the names
from the new menu's menuitem name list.

Now when what the user thinks is a "static" menuitem is chosen,
it's actually a dynamic menuitem being selected within RB. So
the menu handler would need to check the current name of the
menu, then call the appropriate method to handle the clicked
menuitem within that menu.

So to sum up, it seems to me that menus in an RB app *could*
be changed on the fly fairly easily if only the "text" property
of a menu were settable and gettable in code -- which it
currently isn't.

Wouldn't this work? Am I right about all this, or have I missed
some critically important detail? Should I REALbug this as a
feature request?

Thanks in advance for any comments on this.

Sorry for the length of this post, but I wanted to explain my
idea clearly.

-- Tony

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: Changing menus on the fly
Date: 29.08.02 22:30 (Thu, 29 Aug 2002 15:30:32 -0600)
From: Steve Schacht
On 8-29-2002 3:01 PM, Dr. Anthony G. Rich wrote:

> I'd like to port an app in which the menus in the menubar
> change as the app runs, depending on which of several
> modes is selected in the app.

That might be possible with declares right now, but I'm not positive. In
fact, that topic may have come up recently on the list. Have you searched
the archives? Or perhaps you've already looked into using declares?

---
Steve Schacht
<email address removed>

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: Changing menus on the fly
Date: 29.08.02 22:34 (Thu, 29 Aug 2002 17:34:56 -0400 (EDT))
From: Scott Griebel


Can you tell me how to search the archives? Sorry for the stupidity.

Scott

On Thu, 29 Aug 2002, Steve Schacht wrote:

>On 8-29-2002 3:01 PM, Dr. Anthony G. Rich wrote:
>
>> I'd like to port an app in which the menus in the menubar
>> change as the app runs, depending on which of several
>> modes is selected in the app.
>
>That might be possible with declares right now, but I'm not positive. In
>fact, that topic may have come up recently on the list. Have you searched
>the archives? Or perhaps you've already looked into using declares?
>
>---
>Steve Schacht
><email address removed>
>---
>Subscribe to the digest:
><mailto:<email address removed>>
>Unsubscribe:
><mailto:<email address removed>>

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: Changing menus on the fly
Date: 30.08.02 12:47 (Fri, 30 Aug 2002 21:47:23 +1000)
From: William Cannings
I think an easier setup would be to define all the menus possible in
the menu editor, as we do currently. Then when the app is running,
refer to something like a .hidden property which would show and hide
each menu in the menu bar. It means that you would enter menu handlers
exactly the same way we do now, create menus in the menu editor the
same way (without a need for code) etc. I don't know how RB would go
around this programatically, but just using .hidden etc. is less work
for us and more for RB (a good thing :). Thanks,

William Cannings



On Friday, August 30, 2002, at 07:01 am, Dr. Anthony G. Rich wrote:

> In this lengthy post I'm suggesting a small modification to RB
> that I think would allow an app to change menus on the fly --
> something that RB evidently can't currently do. I'm asking
> for public comments on whether my suggestion would work. If
> you're not interested in this topic, please skip this message.
>
> I'd like to port an app in which the menus in the menubar
> change as the app runs, depending on which of several
> modes is selected in the app. Lots of apps do that. For
> example, in FileMaker Pro, the menus change on the fly when
> the user switches from Browse Mode to Layout Mode.
>
> I'd like to use RB to do the port, but according to Matt
> Neuburg's RB book, there's no way in RB to change the menus
> while an app is running. Matt points out that "an argument
> can be made that an application that changes its menus
> on the fly is confusing and poorly planned."
>
> Well, I'm interested in making software, not arguments. :)
>
> It seems to me that it would be possible for an app to change
> menus on the fly if only one small modification were made to
> REALbasic: if the "text" property of a menu (the menu's name
> that shows in the menubar) were settable and gettable in code.
> Right now that string can only be set manually at development
> time; it can't be examined or changed at runtime.
>
> If that modification were made to REALbasic, here's how I
> think changing menus on the fly could be made to work:
>
> DELETING A MENU
> ---------------
> Suppose we wanted to delete the rightmost menu in an app on the
> fly. Let's say for the sake of example that:
>
> 1. The rightmost menu is the fifth menu in the menubar.
>
> 2. That menu is currently the Window menu, a dynamic menu
> that lists all the windows the app currently has open.
>
> 3. Its RB internal "name" property (used by the code, as shown
> in the IDE's Properties window) is "FifthMenu". [Please note
> that this property can't currently be accessed in RB code;
> that's the modification to RB I'm proposing.]
>
> 4. Its text property (the menu name that shows in the menubar,
> also listed in the Properties window) is currently "Window".
>
> To "delete" that menu, all the app would need to do (I assume)
> would be to make the menu name "Window" disappear from the menubar,
> thus making that menu invisible amd therefore unclickable. (If
> necessary, the invisible menu could also be disabled so that no
> "hot spot" remains on the menubar.)
>
> To hide the menu, the app would just need to be able to execute
> this one line of code, which is currently illegal in RB because
> referring to a menu's internal name (FifthMenu) isn't currently
> supported:
>
> FifthMenu.text = "" // Set the menu name to the empty string.
>
> REPLACING A MENU
> ----------------
> Suppose we later wanted to replace that "deleted" (invisible)
> Window menu with a new one. Let's say we want to replace it
> with a different dynamic menu, like a Font menu. The app could
> change the menu name via code:
>
> FifthMenu.text = "Font"
>
> ...and then repopulate the existing menuitems with font names
> instead of window names.
>
> Of course, the app would first need to make the number of menuitems
> equal to the number of installed fonts, not the number of open
> windows. But that's easy to do in RB right now, by dynamically
> adding or deleting menuitem controls, depending on whether there
> happen to be more installed fonts or open windows at the moment.
>
> HANDLING A MENUITEM CLICK
> -------------------------
> Now let's say that during execution, the user pulls down
> this new Font menu (which used to be the Window menu) and
> clicks on what is now a Font name. In the menu handler for the
> fifth menu, the code would examine the current menu name to
> decide whether to call a Font method or a Window method, like
> this (again, a reference to FifthMenu is currently illegal):
>
> if FifthMenu.text = "Font" then // Is menu #5 the Font menu?
> <handle font choice>
> else // No, it's the Window menu right now...
> <handle window choice>
> end if
>
> ADDING MENUS ON THE FLY
> -----------------------
> REALbasic can't currently create new menus on the fly, but it
> doesn't need to, because that effect would be easy to fake.
>
> During development, one could simply create the maximum number
> of menus that the app would ever have showing at once when it
> runs -- nine, say. Then as the app runs, when fewer menus
> should be showing (five, say), the rightmost four menus could
> be made invisible, as described above in "Deleting a Menu".
>
> Later, when more menus should show (let's say seven), the
> leftmost two of the four invisible-but-existing menus could
> be named to something visible, then repopulated with menuitems,
> as described above in "Replacing a Menu".
>
> WHAT ABOUT STATIC MENUS?
> ------------------------
> I think static menus could be handled exactly the same way,
> by making *every* menu a dynamic menu.
>
> An app could simply keep an unchanging list of the menuitem
> names that appear in each static menu. Then during execution,
> when a static menu needs to be changed -- either to a different
> static menu, or to a dynamic one -- the menu handler would
> first clone or delete existing dynamic menuitems to make the
> menu length equal to the number of names in the new menu.
> Then it would overwrite the old menuitem names with the names
> from the new menu's menuitem name list.
>
> Now when what the user thinks is a "static" menuitem is chosen,
> it's actually a dynamic menuitem being selected within RB. So
> the menu handler would need to check the current name of the
> menu, then call the appropriate method to handle the clicked
> menuitem within that menu.
>
> So to sum up, it seems to me that menus in an RB app *could*
> be changed on the fly fairly easily if only the "text" property
> of a menu were settable and gettable in code -- which it
> currently isn't.
>
> Wouldn't this work? Am I right about all this, or have I missed
> some critically important detail? Should I REALbug this as a
> feature request?
>
> Thanks in advance for any comments on this.
>
> Sorry for the length of this post, but I wanted to explain my
> idea clearly.
>
> -- Tony
>
> ---
> Subscribe to the digest:
> <mailto:<email address removed>>
> Unsubscribe:
> <mailto:<email address removed>>

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: Changing menus on the fly
Date: 30.08.02 14:11 (Fri, 30 Aug 2002 15:11:49 +0200)
From: Dario Guerrero
give a try to MenuLib from www.einhugur.com

On viernes, agos 30, 2002, at 13:47 Europe/Madrid, William Cannings
wrote:

>> I'd like to use RB to do the port, but according to Matt
>> Neuburg's RB book, there's no way in RB to change the menus
>> while an app is running. Matt points out that "an argument
>> can be made that an application that changes its menus
>> on the fly is confusing and poorly planned."

Un saludo,

Darío Guerrero.
---------------

mailto:<email address removed>
http://perso.wanadoo.es/dariogf/
Kualo Software.
http://homepage.mac.com/kualo/
mailto: <email address removed>

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>