Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

cbEvents

<< < (6/6)

frithjofh:
Just a thought: how about having more different events to signal that an editor opens? Every specific editor inheriting from EditorBase could have his specific event to be fired when opening. This would concentrate all the decision making at the point where these events are produced. All the plugins could then only listen to those specific events they are interested in. If other new editor types are introduced, this would not affect any code already existing, every new editor type would bring along its own events.

MortenMacFly:

--- Quote from: frithjofh on June 02, 2012, 06:22:20 pm ---Every specific editor inheriting from EditorBase could have his specific event to be fired when opening.

--- End quote ---
This is not possible, because internally often EditorBase is used all the time, even if it is a text editor. So you never know if it is a special editor, therefore "just" EditorBase or an internal. And that is by design and good as it is, because that's the only way how you can use common functionality w/o knowing the details for each editor. For most tasks you don want and don't need to know the specialisation of the editor.

frithjofh:
Then how about putting the information inside the event object. It could have besides the generic GetEditor() function others that retrieve a specific editor, like GetBuiltinEditor() or so, returning NULL when it is not a built in and the editor if it is?

MortenMacFly:

--- Quote from: frithjofh on June 02, 2012, 06:32:29 pm ---Then how about putting the information inside the event object. It could have besides the generic GetEditor() function others that retrieve a specific editor, like GetBuiltinEditor() or so, returning NULL when it is not a built in and the editor if it is?

--- End quote ---
Well the SDK does not know special editors and should not know it (it e.g. knows nothing about wxSmith). So the SDK cannot return a special editor like that except if we integrate all special editors into the SDK which is simply impossible and also makes no sense.

Having another method GetBuiltinEditor() besides GetEditor() turns this:
if (event.GetEditor() && event.GetEditor()->IsBuiltIn())
...into:
if (event.GetBuiltInEditor())
Well - we can do this, but it means that in 90% of the cases you pass this overhead (each event object grows) but don't need it for what benefit?

In the end, if the SDK provides this method it also checks for both (event.GetEditor() && event.GetEditor()->IsBuiltIn()), so you could do yourself in your plugin a (static) method that does this, like (pseudo-code):

--- Code: ---cbEditor * GetBuiltInEditor(cbEvent* evt)
{
  if (evt && evt.GetEditor() && evt.GetEditor()->IsBuiltIn())
    return static_cast<cbEditor>(evt.GetEditor());
  return 0L;
}
--- End code ---
Then you can use it easily as desired. In the end you as plugin developer (this applies to all) plugin developers) will always have special needs. If we put all this into the SDK it will sooner or later be bloated. This is why I am always asking, show me a use case where it makes really sense.

ollydbg:
It looks like there is only one wiki page I can find talking about cb event, it is Code::Blocks SDK events - CodeBlocks.

But this article is quite simple and does not have detailed information about each event.

Navigation

[0] Message Index

[*] Previous page