Creating custom events - Event Handling Overview vs. wxFormBuilder
Lars Uffmann
Hey everyone!
I would like to create my own wxEvent, just a custom wxCommandEvent, no
derived wxEvent, so I read the Event Handling Overview at
http://www.wxwidgets.org/manuals/2.6/wx_eventhandlingoverview.html
And this overview starts talking about macros (DECLARE_EVENT_TYPE,
DEFINE_EVENT_TYPE, BEGIN_EVENT_TABLE, END_EVENT_TABLE) which is _really_
confusing me: The GUI code generated by wxFormBuilder doesn't use event
tables, but instead uses virtual event handling functions and in the
class constructor does a wxControl->Connect(...) call to connect an
event handler to a control with a certain event id. I thought I had
understood that part, now I am confused again.
Is it deprecated style to Connect() events?
And if not, why doesn't the documentation linked above make any mention
of this?
Best Regards,
Lars
chris elliott
Lars Uffmann wrote:
>
> Hey everyone!
>
> I would like to create my own wxEvent, just a custom wxCommandEvent, no
> derived wxEvent, so I read the Event Handling Overview at
> http://www.wxwidgets.org/manuals/2.6/wx_eventhandlingoverview.html
>
> And this overview starts talking about macros (DECLARE_EVENT_TYPE,
> DEFINE_EVENT_TYPE, BEGIN_EVENT_TABLE, END_EVENT_TABLE) which is _really_
> confusing me:
This is only needed if you want a completly new kind of event. if you
just have a need to send a wxCommandEvent you can do ProcessCommand(int
id) (see your copy of the wxFrame docs) or
wxCommandEvent e (wxEVT_COMMAND_MENU_SELECTED,iIndex); //10007
wxWindow * pParent = GetParent();
pParent->ProcessEvent (e);
chris
Vadim Zeitlin
LU> And this overview starts talking about macros (DECLARE_EVENT_TYPE,
LU> DEFINE_EVENT_TYPE, BEGIN_EVENT_TABLE, END_EVENT_TABLE) which is really
LU> confusing me:
Don't use them then. In the new code (meaning not caring about wx 2.4
(yes, 4) compatibility) you can just replace these macros with their (often
trivial) expansions as found in wx/event.h.
LU> The GUI code generated by wxFormBuilder doesn't use event
LU> tables, but instead uses virtual event handling functions and in the
LU> class constructor does a wxControl->Connect(...) call to connect an
LU> event handler to a control with a certain event id. I thought I had
LU> understood that part, now I am confused again.
I am certainly confused. You use Connect() for _connecting_ event
handlers, i.e. instead of BEGIN_EVENT_TABLE/EVT_XXX/END_EVENT_TABLE. But it
has nothing to do with defining new events i.e. DECLARE/DEFINE_EVENT_TYPE.
Why do you compare them?
LU> Is it deprecated style to Connect() events?
No. See
http://wxwidgets.blogspot.com/2007/01/in-praise-of-connect.html
LU> And if not, why doesn't the documentation linked above make any mention
LU> of this?
The event overview does mention Connect(), although it should probably do
it more prominently. However I have the impression that you want it to be
mentioned in the section about defining new events and it has simply
nothing to do with it.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Lars Uffmann
Vadim Zeitlin wrote:
> LU> And this overview starts talking about macros (DECLARE_EVENT_TYPE,
> LU> DEFINE_EVENT_TYPE, BEGIN_EVENT_TABLE, END_EVENT_TABLE) which is really
> LU> confusing me:
> Don't use them then.
seemed to be suggesting that was it.
> I am certainly confused. You use Connect() for _connecting_ event
> handlers, i.e. instead of BEGIN_EVENT_TABLE/EVT_XXX/END_EVENT_TABLE. But it
> has nothing to do with defining new events i.e. DECLARE/DEFINE_EVENT_TYPE.
> Why do you compare them?
Forgive my limited understanding of the connections - I have tried to
read documentation, but I am definitely a learning by doing type of
person, and I failed to make much out of what documentations I have
found. I am using wxwidgets.org documentation as a reference, but in
many cases there's just not enough information for my taste to fully
understand how things work. I started speaking about Connect() because I
thought that it connects an event handler not only to a control, but
also to a specific event - just like the event table.
> LU> Is it deprecated style to Connect() events?
> No. See
Thank you.
> The event overview does mention Connect(), although it should probably do
> it more prominently. However I have the impression that you want it to be
> mentioned in the section about defining new events and it has simply
> nothing to do with it.
Which is probably just because I'm not grasping the concept of events
yet. Namely the difference between event types and event IDs, and how
that affects handling them.
Sorry - but this is the only place where I seem to be able to go to make
some progress on some of my problems - while I'm solving the bigger
amount with debugging and trial-and-error. It's just not easy to get
started with wxWidgets.
Best Regards,
Lars
Vadim Zeitlin
LU> I started speaking about Connect() because I
LU> thought that it connects an event handler not only to a control, but
LU> also to a specific event - just like the event table.
Again, Connect() does the same thing as an event table entry, i.e. an
EVT_XXX(MyClass::OnEvent) line. Nothing more, nothing less.
LU> Which is probably just because I'm not grasping the concept of events
LU> yet. Namely the difference between event types and event IDs, and how
LU> that affects handling them.
The event type is the C++ type of the associated event object. An ID is
simply one of several pieces of information carried by all events (as they
all derive from wxEvent which has GetId()).
LU> Sorry - but this is the only place where I seem to be able to go to make
LU> some progress on some of my problems - while I'm solving the bigger
LU> amount with debugging and trial-and-error. It's just not easy to get
LU> started with wxWidgets.
I think studying the samples (in this case, the "event" one) is the best
way to clear up the confusion.
Lars Uffmann
Is
http://www.wxwidgets.org/manuals/stable/wx_wxcommandevent.html
the "official" documentation for wxCommandEvent?
Then that would be a prime example of the insufficient documentation
I've been complaining about before. I found an example of
wxCommandEvent, constructing a new one, with an error in the second
parameter (undefined variable), wanted to give that parameter a
meaningful value, and the documentation doesn't even mention what the
parameter is good for.
So does that mean I have to look through the wxwidgets sources to find
out more about this?
No offense intended, but this is really dissapointing - I am just trying
to be constructive here - if the documentation was better, I am sure
lots more people would be willing to use wxWidgets.
Best Regards & thankful for being corrected and pointed to the true
documentation,
Lars
Lars Uffmann
Thibault Genessay wrote:
>> So does that mean I have to look through the wxwidgets sources to find
>> out more about this?
:p
> Feel free to contribute :)
I am willing to do that - once I get the hang of it. It just feels odd
because it seems there's a bazillion people out there that know more
about wxWidgets programming than I do.
> It is another approach than the "simpler" wxCommandEvent derived
> event. I say "simpler" because it's simpler to declare, but not to use
> - you have to cast the event in your handlers, whereas using a true
> custom event, you get exact event instance in your handlers.
Not sure what to do with your event handler yet, I think for now I'll
have to find out if my lockup is really caused by accessing wxControl
properties from a thread, or something else... Thank you anyways!
Lars
Thibault Genessay
On Thu, Feb 21, 2008 at 10:30 AM, Lars Uffmann <ar...@nurfuerspam.de> wrote:
> Is
> http://www.wxwidgets.org/manuals/stable/wx_wxcommandevent.html
> the "official" documentation for wxCommandEvent?
It is the official reference page of the wxCommandEvent class. If you
are looking for generic information about events, you might have a
look at http://www.wxwidgets.org/manuals/stable/wx_eventhandlingoverview.html
> Then that would be a prime example of the insufficient documentation
wxWidgets is probably one of the most well documented open source
software I know. If the textual documentation is not enough, just dig
into the sources and you will find your answers.
Also, look at the wxPython examples as they are a very good starting
point for many use cases. The C++ conversion is then straightforward.
> I've been complaining about before. I found an example of
> wxCommandEvent, constructing a new one, with an error in the second
> parameter (undefined variable), wanted to give that parameter a
> meaningful value, and the documentation doesn't even mention what the
> parameter is good for.
>
> So does that mean I have to look through the wxwidgets sources to find
> out more about this?
Well, you might also hire a consultant.
> No offense intended, but this is really dissapointing - I am just trying
> to be constructive here - if the documentation was better, I am sure
> lots more people would be willing to use wxWidgets.
Feel free to contribute :)
Here is an example of a custom event type, not derived form
wxCommandEvent. I use it for a custom slider control.
It sits in the dilWx namespace, hence the dilwx, DILWX_API and such.
With such a custom event, you can use the EVT_SLIDER_VALUE_CHANGING
macro in your event tables. You also have the event type
dilWx::SliderEvent::EVT_SLIDER_CHANGING to use in the Connect()
functions.
It is another approach than the "simpler" wxCommandEvent derived
event. I say "simpler" because it's simpler to declare, but not to use
- you have to cast the event in your handlers, whereas using a true
custom event, you get exact event instance in your handlers.
Regards
Thibault
// ===========================================================================
// SliderEvent declaration
// ===========================================================================
class DILWX_API SliderEvent : public wxNotifyEvent
{
public:
SliderEvent(wxEventType commandType = wxEVT_NULL, int winid = 0,
const double& thumbPos = 0.0, const double& oldThumbPos = 0.0);
SliderEvent(const SliderEvent& event);
wxEvent* Clone() const;
// accessors
const double& GetThumbPos() const { return m_thumbPos; }
void SetThumbPos(const double& pos) { m_thumbPos = pos; }
const double& GetOldThumbPos() const { return m_oldThumbPos; }
void SetOldThumbPos(const double& pos) { m_oldThumbPos = pos; }
static wxEventType EVT_SLIDER_CHANGING;
private:
double m_thumbPos;
double m_oldThumbPos;
DECLARE_DYNAMIC_CLASS_NO_ASSIGN(SliderEvent)
};
typedef void (wxEvtHandler::*dilwxSliderEventFunction)(dilWx::SliderEvent&);
#define dilwxSliderEventHandler(func) \
(wxObjectEventFunction)(wxEventFunction)wxStaticCastEvent(dilwxSliderEventFunction,
&func)
#define EVT_SLIDER_VALUE_CHANGING(winid, fn) \
wx__DECLARE_EVT1(dilWx::SliderEvent::EVT_SLIDER_CHANGING, winid,
dilwxSliderEventHandler(fn))
// ===========================================================================
// SliderEvent implementation
// ===========================================================================
IMPLEMENT_DYNAMIC_CLASS(dilWx::SliderEvent, wxNotifyEvent)
wxEventType SliderEvent::EVT_SLIDER_CHANGING(wxNewEventType());
SliderEvent::SliderEvent(wxEventType commandType, int winid, const
double& thumbPos, const double& oldThumbPos)
: wxNotifyEvent(commandType, winid)
{
m_thumbPos = thumbPos;
m_oldThumbPos = oldThumbPos;
}
SliderEvent::SliderEvent(const SliderEvent& event)
: wxNotifyEvent(event)
{
m_thumbPos = event.m_thumbPos;
m_oldThumbPos = event.m_oldThumbPos;
}
wxEvent* SliderEvent::Clone() const
{
return new SliderEvent(*this);
}
Vadim Zeitlin
LU> Then that would be a prime example of the insufficient documentation
LU> I've been complaining about before. I found an example of
LU> wxCommandEvent, constructing a new one, with an error in the second
LU> parameter (undefined variable), wanted to give that parameter a
LU> meaningful value, and the documentation doesn't even mention what the
LU> parameter is good for.
Yes, wxCommandEvent ctor documentation is strange. OTOH it's still great
compared to your description of the problem. Let's see:
- you found an example of wxCommandEvent: where?
- "constructing a new one": phrase without verb no good
- with an error in the second parameter: what error?
So, without even trying, I am completely confused by the 3 sentences you
wrote. I hope after rereading what you wrote above you can appreciate a
little better why writing documentation which is immediately clear for
everyone is not easy.
To summarize, I still have no idea what are you complaining about. I just
see the wrong value of type of the _first_ ctor parameter in the docs and
missing explanation for the same (do we really need to explain that the
parameter called "id" is meant to be passed an id?). What else is there?
LU> So does that mean I have to look through the wxwidgets sources to find
LU> out more about this?
Oh horror.
LU> No offense intended, but this is really dissapointing
To be brutally honest, if you're not willing to consider the possibility
of ever looking in wx sources, you're going to waste a lot of time which
could be saved otherwise. You can still use wx, of course (plenty of people
with the same code-reading aversion attitude do) but I am just unable to
understand this instinctive queasiness towards looking into [not even
sources but] the headers. Personally it's the first thing I do (whether
using wx, MFC or whatever) because the code is so often more clear (in
spite of being more concise) than documentation anyhow.
Lars Uffmann
Vadim,
Vadim Zeitlin wrote:
> Yes, wxCommandEvent ctor documentation is strange. OTOH it's still great
> compared to your description of the problem. Let's see:
> [..]
I am really not in the mood to respond to your temper-tantrums. It's not
my fault if you're having a bad day.
> To be brutally honest, if you're not willing to consider the possibility
> of ever looking in wx sources, you're going to waste a lot of time which
> could be saved otherwise.
If you ever bothered to actually be open to constructive criticism
(which isn't even directed at you, personally), you would be able to see
that nowhere did I ever state I was not willing to look into the
sources. But before inventing the wheel anew, I was asking if I was
maybe looking at the wrong documentation while there is a more complete
document elsewhere. I have no problem with looking into the sources, but
since I never had to look into the sources for any other libraries (in
various languages) due to using well-documented interfaces, I was
expecting something similar here.
You know, I am all for having a widely used, portable open-source GUI
library for C++ (and other languages), but the "widely used" aspect
isn't really benefitting from your short-tempered reactions to someone
who is actively making an effort to work around the shortcomings of the
documentation. In case you hadn't noticed, I _never_ asked "please tell
me how this works" but instead asked for being pointed to documentation
links regarding the issue I was having.
> but I am just unable to
> understand this instinctive queasiness towards looking into [not even
> sources but] the headers.
Apparently your understanding of the problem fails you earlier, because,
as I said, I do not have a problem looking into the sources.
Seriously man, get a grip on your bad humour... If responding to my
questions makes you become so upset, then please, don't do it. I'll get
along on my own somehow. No one is forcing you to be helpful and get all
angry over it.
Sheesh...
Thank you anyways, you've been helpful at some points at least.
Lars
Vadim Zeitlin
LU> Vadim Zeitlin wrote:
LU> > Yes, wxCommandEvent ctor documentation is strange. OTOH it's still great
LU> > compared to your description of the problem. Let's see:
LU> > [..]
LU>
LU> I am really not in the mood to respond to your temper-tantrums. It's not
LU> my fault if you're having a bad day.
Oh sorry. I didn't mean to offense you but frankly, doesn't it seem
amazing that you managed to write a so unreadable report of a problem in
the documentation? Well, I guess not...
LU> If you ever bothered to actually be open to constructive criticism
I'm open to it but I honestly (I know you won't believe me but please try)
have no idea what did you complain about in the first place. I pointed to
the problem I see with the current documentation (which is problematic,
clearly documenting ctor by writing "Constructor" doesn't help much) but
you seemed to be complaining about something else entirely -- but I didn't
get what it was.
LU> In case you hadn't noticed, I never asked "please tell me how this
LU> works"
FWIW there is nothing wrong with asking this if it's not already
prominently described in the docs.
LU> but instead asked for being pointed to documentation links
LU> regarding the issue I was having.
Sorry, I didn't understand this. I thought you were pointing out a problem
in the documentation.
LU> Seriously man, get a grip on your bad humour... If responding to my
LU> questions makes you become so upset, then please, don't do it. I'll get
LU> along on my own somehow. No one is forcing you to be helpful and get all
LU> angry over it.
LU>
LU> Sheesh...
LU>
LU> Thank you anyways, you've been helpful at some points at least.
Rereading my reply it didn't come totally as I intended but I still think
you're overreacting. I wasn't upset and certainly didn't mean to upset you.
Once again, I just thought it was funny that a report about a problem with
a wording in the docs could have been written in so unclear way. I still
don't understand at all what your problem is, this description:
LU> I found an example of wxCommandEvent, constructing a new one, with an
LU> error in the second parameter (undefined variable), wanted to give that
LU> parameter a meaningful value, and the documentation doesn't even
LU> mention what the parameter is good for.
just seems to be lacking some bits critical for comprehension.
Anyhow, good luck,
Lars Uffmann
Vadim Zeitlin wrote:
> Oh sorry. I didn't mean to offense you but frankly, doesn't it seem
> amazing that you managed to write a so unreadable report of a problem in
> the documentation? Well, I guess not...
>> I found an example of wxCommandEvent, constructing a new one, with an
>> error in the second parameter (undefined variable), wanted to give
>> that parameter a meaningful value, and the documentation doesn't even
>> mention what the parameter is good for.
My introduction to the problem I was having was phrased poorly, I am
willing to admit that, but that was because I wanted to be brief and the
only thing in there referring to the wxWidgets documentation was the
last half sentence: "the documentation doesn't even mention what the
(second) parameter (of wxCommandEvent ctor) is good for."
The example was not from the wxWidgets doc, nor did it matter where it
comes from (forgot now), because all I wanted to know is what value to
supply for the second parameter (instead of the never declared or
initialized variable name in the example I had).
> I'm open to it but I honestly (I know you won't believe me but please try)
> have no idea what did you complain about in the first place.
It would have come across much better if you had just asked "sorry, I
don't understand this, can you be more specific about the problem?"
instead of being outright arrogant and trying to be funny in the first
reaction. ("Yes, wxCommandEvent ctor documentation is strange. OTOH it's
still great compared to your description of the problem. Let's see:")
> but you seemed to be complaining about something else entirely --
> but I didn't get what it was.
Just that the doc makes no mention what the parameters in the
constructor are for. While I can do an educated guess at
commandEventType, "id" isn't exactly self-explaining.
> LU> but instead asked for being pointed to documentation links
> LU> regarding the issue I was having.
> Sorry, I didn't understand this. I thought you were pointing out a problem
> in the documentation.
I was. My questions to doc links were in earlier posts, I was trying to
make a point that I don't think I deserved the unfriendly answer of
yours for being a dummy that wants everything served on a silver platter.
> Rereading my reply it didn't come totally as I intended but I still think
> you're overreacting. I wasn't upset and certainly didn't mean to upset you.
You didn't upset me, you had me dissapointed and shaking my head about
how someone (who's part of the developer team) can have the bad temper I
usually only see in trolls. Btw. re-reading your own post >before<
hitting send is always a good idea, especially in debates. :)
Have a nice day!
Lars