Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

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

(1/1)

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;
}

--- End code ---

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();
}

--- End code ---

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

--- Code: --- (*it)->Call(event);
--- End code ---

Any ideas?

MortenMacFly:

--- Quote from: ollydbg on June 14, 2012, 07:09:47 am ---So, do we need the check the event's state before we call

--- Code: --- (*it)->Call(event);
--- End code ---

--- End quote ---
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();
    }
}

--- End code ---
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:

--- Quote from: ollydbg on June 15, 2012, 02:17:23 am ---But for our usage in a C::B event handler, does Skip() go with the same mechanism? (From a derived class to cbPlugin class?)

--- End quote ---
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:

--- Quote from: MortenMacFly on June 15, 2012, 06:50:17 am ---
--- Quote from: ollydbg on June 15, 2012, 02:17:23 am ---But for our usage in a C::B event handler, does Skip() go with the same mechanism? (From a derived class to cbPlugin class?)

--- End quote ---
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().

--- End quote ---
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.

Navigation

[0] Message Index