cbEvents

[frithjofh]

I'll try my best. The call stack I used only inside the debugger till now.

On other thing: in the code I posted the constructor takes a EditorBase pointer as argument. For the case a this pointer I get directly from the event object. Could it be for some reason, that this event object carries a pointer to EditorBase which is not completely initialized? For the case b if retrieve the pointers from the editormanager, these are complete.

[oBFusCATed]

What is the event for caseA?

[frithjofh]

cbEVT_EDITOR_OPEN. case b works without event: the plugin on attaching retrieves from editormanager whatever editors are open.

just ran a test: after receiving the event, I don't use the editor from the event object, but retrieve the editor by filename (from the editor in the event object) directly from editormanager. same result.

Opening some arbitrary file also does not show the project name. as till now I think the project name is set on the editors only after cbEVT_PROJECT_OPEN.

[frithjofh]

Made another test. Tried to retrieve the project name from an Entry which was constructed from an editor retrieved from an cbEVT_EDITOR_CLOSE event object. This does work as expected.

So: cbEVT_EDITOR_CLOSE and cbEVT_EDITOR_OPEN are not symmetric.

[oBFusCATed]

Looking at the code:
1. In EditorManager::New there is not mentioning of a project, probably it has not created here or it is just an omission. No time to dig if the project can be made available in this method.
2. There are some project events like cbEVT_PROJECT_BEGIN_ADD_FILES, cbEVT_PROJECT_FILE_ADDED have you tried to capture them? When do they happen? Before or after the EDITOR_OPEN event?

[frithjofh]

I thought these events were meant only if files were added or removed from a project, not when a file belonging to a project was opened??

For my issue: even if the plugin is attached and a project is open already, every file I then open (a file belonging to a project) does not show its projects name. I think the problem really is what you found: the cbEVT_EDITOR_OPEN does not contemplate the project the file belongs to.

[MortenMacFly]

In the end: I'm not really criticizing anyone. In the end I just have to admit that c::b is fun and a great tool to work with, so just don't mind too much about my complaint.

Don't worry, we listen and we like discussions. Again, just try to implement it in a way it fits your needs by introducing additional events to the core and provide us with patches. In the end if your plugin works fine and requires them we have no other choice than to apply those, aren't we?! ;-)

By the way: is there some, one, place where all those events are really explained, as to when they fire, and what was the idea behind their implementation, and so ...

I'm afraid only in the heads of us for the moment. I recall a WiKi article on that topic but it seems gone, or at least a quick search didn't reveal it for me.

And for that thing which is the idea behind the EditorBase, and the cbEditor, and what more implications lurk there?

Sure: Have a look at wxSmith and ByoGames, also HexEditor and the NassiShneiderman plugin for example: They all use not a classical cbEditor which means editing text (source code), but an EditorBase. EditorBase it intended to be the minimal set of function relevant to all basically "notebooks" C::b will handle. However, "specialisations" for source code, which is the #1 use case are done in cbEditor. You can also see EditorBase as an interface class, if you want to.

(Now I'll continue to read the other million posts in this thread... ).

[MortenMacFly]

Looking at the code:
1. In EditorManager::New there is not mentioning of a project, probably it has not created here or it is just an omission. No time to dig if the project can be made available in this method.

Sure it is not, because an editor does not require a project. However, the IDE will ask in the case you create a new file (editor) if you want to attach this to a project. In that case, you'll see it in the project changed event (or similarly called). In fact, if an editor is created there should not be a ned fr a project to keep it decoupled. Again, think about specific editors like ByoGames... there will never be a project nor should be.

[MortenMacFly]

For my issue: even if the plugin is attached and a project is open already, every file I then open (a file belonging to a project) does not show its projects name. I think the problem really is what you found: the cbEVT_EDITOR_OPEN does not contemplate the project the file belongs to.

For all these test cases, can you do me a favour and disable the CC plugin to check if that changes things?

[frithjofh]

disabling the code completion plugin does not change the behavior.

[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]

Every specific editor inheriting from EditorBase could have his specific event to be fired when opening.

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]

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?

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

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.