Re: Re: how to use menu IDs to obtain pointers to submenus

>-- On Sat, 20 Oct 2007 00:06:00 -0000 john grant wrote --
> I found the answer. I hope this helps someone.
> You can call this code _after_ your derived framewindow has created
> its menubar and added the necessary menu items:
>
>
> wxMenuBar* theMenuBar = GetMenuBar(); // my only menubar wxMenu*
> pluginsMenu = theMenuBar->GetMenu( 3 ); // the 4th menu, "Plugins"
> pluginsMenu->Enable( ID_MENU3, false ); // ID_MENU3 is "Graphics"
>
>
> --- In anthemion-devtools%40yahoogroups.com">anthemion-devtoolsyahoogroups.com, john grant
> wrote:
>
>>
>> Hi,
>> My ultimate goal is to disable part of the menu until another part
>;>
>; of the menu has been clicked.
>
>;> I have used DialogBlocks to make a frame window with an elaborate
>>
> menubar. I have DB generating code for C++ use only. I am trying
> to use the IDs that DB so kindly generates. I am new to wxWidgets
> and I probably just do not understand the basic use of common
> classes. The generated C++ event handler functions (part of the
> generated wxFrame derivative class) seem like the perfect place to
> process the wxMenuItem clicked events. I just do not know what
>; code to write to obtain pointers to the submenus in order to
> enable/disable the submenus of interest. I imagine that the IDs
> would be useful, but I do not know what to use them for. I don't
> see any functions in the wxWidgets documentation that will provide
> a pointer to a submenu given an ID. Does anyone know how to
> accomplish this?
>
>>
>> Thanks,
>> John
>;>

Hi, John!

The easiest thing to do (and I do it routinely, so it doesn't always occur to me
that others don't), is to give Member variable names in the DB property sheets.
For example, in my menubar (as in most) I have a "File" menu, and I give it the
member variable name of "FileMenu" (original, no?!;). Then, when I want to
access members of that particular menu, I only need to grab the member variable
name (FileMenu) and it points to its menu items. I also like to give my Id names
in DB meaningful names (ID_MENUITEM3 keeps DB squared away, but it's not too
informative, especially when revisiting code at a later date!;). Let's say the
first menu item in FileMenu is "Open" (another original!;), I will give it the
name "OpenMenuItemId". Then the code is not so cryptic, and you don't need
comments like '// ID_MENU3 is "Graphics"'. This technique is known as self
documenting code!;)

If you're new to DB and/or wxWidgets, you may like to take a look at a couple of
tutorials. A basic one is the "Data Converter Tutorial", a very basic
application done in DB with step by step instruction and explanation. There's
also one that is _very_ important if you're new to wxWidgets: "A Simple Editor:
Sizers Tutorial". Sizers are the biggest stumbling block to most folks new to
wxWidgets but not new to graphical programming (i.e., Visual Studio, Delphi,
etc.). Sizers are the one thing that keeps wxWidgets IDE's from being
drag'n'drop IDE's. It just isn't in the cards. You may see several packages out
there that do drag'n'drop for wxWidgets, but they are highly ineffective when
programming with sizers (and sizers are the design heart of wxWidgets, the main
factor that keeps applications "cross-platform compatible"). So, you can design
applications with wxWidgets ignoring sizers (which most of these IDE's do, only
giving lip service to "programming sizers") and using absolute position and
sizing, but you're missing out on the main thrust of wxWidgets!wbr>)

You can find these 2 tutorials (and some others and demos and other interesting
tidbits) at wxWidgets Code Exchange or the wxMS_developers group.

HTH:

thx,
Dave S.

Contrary to popular belief, practice does not make perfect... only permanent!

wxMS_developers · Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/

wxWidgets Code Exchange
http://www.wxCodex.net/

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Hi Dave,
Thanks for the great advice. I will soon be experimenting with your
suggestions, but for now I have a really nice looking GUI. No need to
mess with a good thing. As far as being new to wxWidgets, I sure can
use all the advice I can get. However, I want to give my applause to
DialogBlocks because it single-handedly helped me to understand the
sizer concept through trial and error. Also, the in-IDE reference to
wxWidgets help files is **extremely** helpful. Way to go guys!

I'm slowly finding caveats in the code generation, which is not a
surprise to me because I know DB is a rapidly improving tool. I
hesitated to use the custom ID names, like you suggest, because I
thought I read in one of the reference pages that DB will not be able
to generate the code in the same manner if you override those kinds of
defaults. Maybe I have a bad memory, but I didn't want to push my
luck while learning how to use the tool and I wanted to leverage the
code generation as much as possible.

I can't say how much I've been enjoying DB. I wonder, is there much
discussion about the direction of its development? How are features
prioritized?

Dave, thanks again for the response. Hopefully I can contribute more
to the group as I gain a little more knowledge.

John

--- In anthemion-devtools%40yahoogroups.com">anthemion-devtoolsyahoogroups.com, Dave Silvia <dsilvia...>
wrote:
&gt;
> >-- On Sat, 20 Oct 2007 00:06:00 -0000 john grant wrote --
> > I found the answer. I hope this helps someone.
> > You can call this code _after_ your derived framewindow has created
> > its menubar and added the necessary menu items:
&gt; >
>; >
>; > wxMenuBar* theMenuBar = GetMenuBar(); // my only menubar wxMenu*
> > pluginsMenu = theMenuBar->GetMenu( 3 ); // the 4th menu, "Plugins"
> > pluginsMenu->Enable( ID_MENU3, false ); // ID_MENU3 is "Graphics"
> >
>; >
>; > --- In anthemion-devtools%40yahoogroups.com">anthemion-devtoolsyahoogroups.com, john grant
&gt; > wrote:
&gt; >
>; >>
> >> Hi,
> >> My ultimate goal is to disable part of the menu until another part
>; >>
> > of the menu has been clicked.
> >
>; >> I have used DialogBlocks to make a frame window with an elaborate
> >>
> > menubar. I have DB generating code for C++ use only. I am trying
&gt; > to use the IDs that DB so kindly generates. I am new to wxWidgets
> > and I probably just do not understand the basic use of common
&gt; > classes. The generated C++ event handler functions (part of the
> > generated wxFrame derivative class) seem like the perfect place to
> > process the wxMenuItem clicked events. I just do not know what
>; > code to write to obtain pointers to the submenus in order to
> > enable/disable the submenus of interest. I imagine that the IDs
> > would be useful, but I do not know what to use them for. I don't
&gt; > see any functions in the wxWidgets documentation that will provide
> > a pointer to a submenu given an ID. Does anyone know how to
> > accomplish this?
&gt; >
>; >>
> >> Thanks,
> >> John
>; >>
>
> Hi, John!
&gt;
> The easiest thing to do (and I do it routinely, so it doesn't always
occur to me
> that others don't), is to give Member variable names in the DB
property sheets.
> For example, in my menubar (as in most) I have a "File" menu, and I
give it the
> member variable name of "FileMenu" (original, no?!;). Then, when I
want to
> access members of that particular menu, I only need to grab the
member variable
> name (FileMenu) and it points to its menu items. I also like to give
my Id names
> in DB meaningful names (ID_MENUITEM3 keeps DB squared away, but it's
not too
> informative, especially when revisiting code at a later date!;).
Let's say the
> first menu item in FileMenu is "Open" (another original!;), I will
give it the
> name "OpenMenuItemId&quot;. Then the code is not so cryptic, and you
don't need
> comments like '// ID_MENU3 is "Graphics"'. This technique is known
as self
> documenting code!;)
>
> If you're new to DB and/or wxWidgets, you may like to take a look at
a couple of
> tutorials. A basic one is the "Data Converter Tutorial&quot;, a very basic
> application done in DB with step by step instruction and
explanation. There's
> also one that is _very_ important if you're new to wxWidgets: "A
Simple Editor:
> Sizers Tutorial&quot;. Sizers are the biggest stumbling block to most
folks new to
> wxWidgets but not new to graphical programming (i.e., Visual Studio,
Delphi,
> etc.). Sizers are the one thing that keeps wxWidgets IDE's from being
> drag'n'drop IDE's. It just isn't in the cards. You may see several
packages out
> there that do drag'n'drop for wxWidgets, but they are highly
ineffective when
> programming with sizers (and sizers are the design heart of
wxWidgets, the main
> factor that keeps applications "cross-platform compatible"). So, you
can design
> applications with wxWidgets ignoring sizers (which most of these
IDE's do, only
> giving lip service to "programming sizers&quot;) and using absolute
position and
> sizing, but you're missing out on the main thrust of wxWidgets!wbr>)
&gt;
> You can find these 2 tutorials (and some others and demos and other
interesting
> tidbits) at wxWidgets Code Exchange or the wxMS_developers group.
&gt;
> HTH:
>;
> thx,
>; Dave S.
>
> Contrary to popular belief, practice does not make perfect... only
permanent!
&gt;
> wxMS_developers · Development with wxWidgets on MSWindows
> http://tech.groups.yahoo.com/group/wxMS_developers/
>
> wxWidgets Code Exchange
> http://www.wxCodex.net/
>

Messages in this topic (0) Reply (via web post) | Start a new topic

.