The doc tells me, that the second arg in
wxButton
is the ID; how knows the programmer
that it is 1010 (s.b.)?
You can set the ID to whatever you want -- it's just a number by which you
can later refer to that particular widget. However, this means that you
probably *don't* want to use the same ID number for every button, as shown
in your example -- the whole point of it is that it should be different.
Typically, if you have a menu option and a button that do the same thing,
you can give them the same ID, and that helps wxWindows (and your code) to
connect the two.
If you don't care what the ID is, or don't want to bother finding one that
isn't already taken (certain wxWindows components specify their own IDs),
there's two options. You can pass -1 as the ID, and wxWindows will assign
an ID on its own -- you never have to worry about it. Alternatively, you
can use wxNewId() to generate a valid, unused ID number -- this can be good
if you want to use the same ID for several related controls (linked menu
option/button, for example), but don't want to bother with finding an
appropriate value yourself. (I frequently create a dictionary of standard
IDs, filling it with wxNewId(), to emulate the C practice of #define-ing
constants in a header file.)
Jeff Shannon
Technician/Programmer
Credit International
I'm coming to wxPython programming after doing years of Swing programming. In Swing, there aren't IDs; you just keep a reference to the object. Some random thoughts about the IDs:
I haven't really dived too much into it, but it seems like the ID system is a throwback to older, non-OO C programming.
And I assume that wxPython uses it because that's how wxWindows works?
I can imagine that it might be easy to refactor / hide the IDs, and let the application programmer just deal with object references in wxPython.
But I also guess that it's important for wxPython to not diverge from wxWindows.
You can set the ID to whatever you want -- it's just a number by which you
can later refer to that particular widget. However, this means that you
probably *don't* want to use the same ID number for every button, as shown
in your example -- the whole point of it is that it should be different.
Typically, if you have a menu option and a button that do the same thing,
you can give them the same ID, and that helps wxWindows (and your code) to
connect the two.
If you don't care what the ID is, or don't want to bother finding one that
isn't already taken (certain wxWindows components specify their own IDs),
there's two options. You can pass -1 as the ID, and wxWindows will assign
an ID on its own -- you never have to worry about it. Alternatively, you
can use wxNewId() to generate a valid, unused ID number -- this can be good
if you want to use the same ID for several related controls (linked menu
option/button, for example), but don't want to bother with finding an
appropriate value yourself. (I frequently create a dictionary of standard
IDs, filling it with wxNewId(), to emulate the C practice of #define-ing
constants in a header file.)
Jeff Shannon
Technician/Programmer
Credit International
I haven't really dived too much into it, but it seems like the ID system
is a throwback to older, non-OO C programming.
And I assume that wxPython uses it because that's how wxWindows works?
I can imagine that it might be easy to refactor / hide the IDs, and let
the application programmer just deal with object references in wxPython.
Well, that's part of it, yes... a lot of it *is* a carryover from non-OO
programming. However, it's still got its advantages -- for example, when
creating a set of controls (menu, toolbar, buttons, etc) that all run the
same command, it's very convenient to just be able to set the same ID and
have the framework automatically connect them. I'm sure that the linkage
could be created by registering object references, but it seems to me that
this would require a slight bit more effort.
Of course, the underlying fact *is* that wxPython must interoperate with the
lower-level GUI frameworks. I know that the concept of window/widget IDs is
built into the Win32 GUI API. (I don't know about XWindows/GTK...)
Therefore, it's natural for that architecture to be reflected in any
toolkits built on top of that. You *can* hide it, but in doing so you may
lose flexibility.
Jeff Shannon
Technician/Programmer
Credit International