Does event.Skip() useful in the plugin event handler?

[ollydbg]

I see the plugin event was called like:

Code

bool Manager::ProcessEvent(CodeBlocksEvent& event)
{
    if (IsAppShuttingDown())
        return false;

    EventSinksMap::iterator mit = m_EventSinks.find(event.GetEventType());
    if (mit != m_EventSinks.end())
    {
        for (EventSinksArray::iterator it = mit->second.begin(); it != mit->second.end(); ++it)
            (*it)->Call(event);
    }
    return true;
}

One handler is:

Code

void CodeCompletion::OnProjectClosed(CodeBlocksEvent& event)
{
    // After this, the Class Browser needs to be updated. It will happen
    // when we receive the next EVT_PROJECT_ACTIVATED event.
    if (IsAttached() && m_InitDone)
    {
        cbProject* project = event.GetProject();
        if (project && m_NativeParser.GetParserByProject(project))
        {
            ReparsingMap::iterator it = m_ReparsingMap.find(project);
            if (it != m_ReparsingMap.end())
                m_ReparsingMap.erase(it);

            m_NativeParser.DeleteParser(project);
        }
    }
    event.Skip();
}

So, do we need the check the event's state before we call

Code

 (*it)->Call(event);

Any ideas?

[MortenMacFly]

So, do we need the check the event's state before we call

Code

 (*it)->Call(event);

Why would you want to do this? You don't know what information is being sent through this event, its just an "event router". Checking the event's state is under responsibility of the "customer" - the plugin therefore.

[ollydbg]

From the wxWidgets' book, there are some descriptions about the "Skip()" function:

Code

For example, it is possible to filter out selected keystroke events sent by the system to a native text control by overriding wxTextCtrl and defining a handler for key events using EVT_KEY_DOWN. This would indeed prevent any key events from being sent to the native control, which might not be what is desired. In this case, the event handler function has to call wxEvent::Skip to indicate that the search for the event handler should continue.

To summarize, instead of explicitly calling the base class version, as you would have done with C++ virtual functions, you should instead call Skip on the event object.

For example, to make the derived text control only accept "a" to "z" and "A" to "Z," we would use this code:

void MyTextCtrl::OnChar(wxKeyEvent& event)
{
    if ( wxIsalpha( event.KeyCode() ) )
    {
       // Keycode is within range, so do normal processing.
       event.Skip();
    }
    else
    {
       // Illegal keystroke. We don't call event.Skip() so the
       // event is not processed anywhere else.
       wxBell();
    }
}

So, the Skip() function can let the event propagate from derived class to bass class.

But for our usage in a C::B event handler, does Skip() go with the same mechanism? (From a derived class to cbPlugin class?)
Am I right?

[MortenMacFly]

But for our usage in a C::B event handler, does Skip() go with the same mechanism? (From a derived class to cbPlugin class?)

Well in our use case all events are sent through the core and the core only knows who's interested in (has registered for this event). For SDK events you may skip the event propagation in the plugin, but for more "generic" events, like the scintilla ones you should call Skip() as otherwise you stop propagation which may lead to errors (i.e. no key strokes in the editor). So it depends I'd say... but its not wrong to generally call event.Skip().

[ollydbg]

But for our usage in a C::B event handler, does Skip() go with the same mechanism? (From a derived class to cbPlugin class?)

Well in our use case all events are sent through the core and the core only knows who's interested in (has registered for this event). For SDK events you may skip the event propagation in the plugin, but for more "generic" events, like the scintilla ones you should call Skip() as otherwise you stop propagation which may lead to errors (i.e. no key strokes in the editor). So it depends I'd say... but its not wrong to generally call event.Skip().

Ok, I see. In our SDK events handler, Whether there is a "event.Skip()" call does not matters. But other events like "scintilla events" must have "event.Skip()" call.