Puzzling cbEVT_EDITOR_* event behavior

[dmoore]

Stuff I learned while playing with EditorTweaks...

When an editor is opened, C::B generates cbEVT_EDITOR_DEACTIVATED if already open editor, then cbEVT_EDITOR_ACTIVATED then cbEVT_EDITOR_OPEN
switching between editors: cbEVT_EDITOR_DEACTIVATED then cbEVT_EDITOR_ACTIVATED
When an editor is closed cbEVT_EDITOR_ACTIVATED for any new editor then cbEVT_EDITOR_CLOSED, but no cbEVT_EDITOR_DEACTIVATED!

Is this right? (disclaimer: the C::B on this box is a few of months out of date -- I'll test again on an up to date copy)

In particular,
1/ why no cbEVT_EDITOR_DEACTIVATED on close?
2/ why activated before open/close?


A slightly related issue. Might it be good to send some sort of notification after changing editor/environment settings?

[MortenMacFly]

When an editor is opened, C::B generates cbEVT_EDITOR_DEACTIVATED if already open editor, then cbEVT_EDITOR_ACTIVATED then cbEVT_EDITOR_OPEN

Yes, Deactivated means "editor still open, but another one got active".

switching between editors: cbEVT_EDITOR_DEACTIVATED then cbEVT_EDITOR_ACTIVATED

Logical here, too.

When an editor is closed cbEVT_EDITOR_ACTIVATED for any new editor then cbEVT_EDITOR_CLOSED, but no cbEVT_EDITOR_DEACTIVATED!

Correct here, too as the editor closed is not "de-activated" (meaning still accessible), but truly destroyed.

[dmoore]

When an editor is opened, C::B generates cbEVT_EDITOR_DEACTIVATED if already open editor, then cbEVT_EDITOR_ACTIVATED then cbEVT_EDITOR_OPEN

Yes, Deactivated means "editor still open, but another one got active".

I was expecting: cbEVT_EDITOR_DEACTIVATED if already open editor, cbEVT_EDITOR_OPEN then cbEVT_EDITOR_ACTIVATED

When an editor is closed cbEVT_EDITOR_ACTIVATED for any new editor then cbEVT_EDITOR_CLOSED, but no cbEVT_EDITOR_DEACTIVATED!

Correct here, too as the editor closed is not "de-activated" (meaning still accessible), but truly destroyed.

I expected: cbEVT_EDITOR_DEACTIVATED, cbEVT_EDITOR_CLOSED then cbEVT_EDITOR_ACTIVATED

You might be "legally"/"factually" right about these things, but this isn't very convenient behavior for a plugin developer. e.g. plugin wants to change menus depending on which editor is active, deactivating items if the editor closes. I would expect to only have to trap [DE]ACTIVATED events. Instead we have to trap the CLOSE event as well and to make it more difficult the CLOSE event comes after the ACTIVATE event, which requires a check to see if there is anything still open after the close (instead of just relying on the ACTIVATE event). You can work around it, but it takes extra work and is VERY confusing.

Maybe I just don't see the problem the current behavior solves.

[ollydbg]

When an editor is opened, C::B generates cbEVT_EDITOR_DEACTIVATED if already open editor, then cbEVT_EDITOR_ACTIVATED then cbEVT_EDITOR_OPEN

Yes, Deactivated means "editor still open, but another one got active".

I was expecting: cbEVT_EDITOR_DEACTIVATED if already open editor, cbEVT_EDITOR_OPEN then cbEVT_EDITOR_ACTIVATED

example 1 , we have three files, A, B and C.
Now, A is already opened and the only active editor. B and C are not opened, so there is only one tab.

Action: If B is opened and activated, I expect the command sequence is:

cbEVT_EDITOR_DEACTIVATED of A
cbEVT_EDITOR_OPEN of B
cbEVT_EDITOR_ACTIVATED of B

example 2 , we have three files, A, B and C.
Now, A and B is already opened and A is the active editor. C are not opened.

Action: If B is activated, I expect the command sequence is:

cbEVT_EDITOR_DEACTIVATED of A
cbEVT_EDITOR_ACTIVATED of B

Am I right??

[dmoore]

example 1 , we have three files, A, B and C.
Now, A is already opened and the only active editor. B and C are not opened, so there is only one tab.

Action: If B is opened and activated, I expect the command sequence is:

cbEVT_EDITOR_DEACTIVATED of A
cbEVT_EDITOR_OPEN of B
cbEVT_EDITOR_ACTIVATED of B

not quite: cbEVT_EDITOR_DEACTIVATED of A, cbEVT_EDITOR_ACTIVATED of B then cbEVT_EDITOR_OPEN of B

so cbEVT_EDITOR_OPEN really means open and fully loaded?

Action: If B is activated, I expect the command sequence is:

cbEVT_EDITOR_DEACTIVATED of A
cbEVT_EDITOR_ACTIVATED of B

Am I right??

yes.

[dmoore]

When an editor is closed cbEVT_EDITOR_ACTIVATED for any new editor then cbEVT_EDITOR_CLOSED, but no cbEVT_EDITOR_DEACTIVATED!

Correct here, too as the editor closed is not "de-activated" (meaning still accessible), but truly destroyed.

If this is correct, then I don't see why we need a DEACTIVATED event at all. Just include pointers to the editors we switched to and from (or NULL if one of those doesn't exist) in the ACTIVATED event. It would then make sense to rename the ACTIVATED event to SWITCHED event. I still think we should send a switch event on close, however, even if there are no more open files. This is just more usable for the end user.

[MortenMacFly]

Not much time to look into this any closer but did you consider that loading / opening an editor might fail (thus there is no deactivated/activated event at all) and selecting another editor tab (meaning without opening) has to be considered, too?

A failure might happen in every process the event queue describes. And we not only have opening a file, but also just switching a file. I don't see how we can differ between all this stages / failure cases other that as it is implemented now.

But I am tired atm...

[dmoore]

To illustrate, attached is a patch that implements a SWITCHED event in addition to the ACTIVATED/DEACTIVATED events. SWITCHED fills the event with pointers to the old and new editors, and will be called when an editor is opened, closed or there is a switch between editors. Probably need to put in some checks to prevent emission of redundant events. Ideally, any plugin that wanted to offer editor specific menus only needs to hook into this event.

[attachment deleted by admin]

[ollydbg]

example 1 , we have three files, A, B and C.
Now, A is already opened and the only active editor. B and C are not opened, so there is only one tab.

Action: If B is opened and activated, I expect the command sequence is:

cbEVT_EDITOR_DEACTIVATED of A
cbEVT_EDITOR_OPEN of B
cbEVT_EDITOR_ACTIVATED of B

not quite: cbEVT_EDITOR_DEACTIVATED of A, cbEVT_EDITOR_ACTIVATED of B then cbEVT_EDITOR_OPEN of B

Thanks!!

So, what is the logic of the message sequence when a file is opening?

Why cbEVT_EDITOR_ACTIVATED of B should be sent before cbEVT_EDITOR_OPEN of B

In my opinion, I think an editor should firstly be opened(which means loading the file from hard disk), after that, it has two visible status, "active state"(it is the front tab) or "de-active state" (it is an editor in the background).

[Pecan]

It's because activation comes from wxAuiNotebook.

It means the tab is "activated" before the file is opened and loaded into the wxAuiNotebook page.

It should be called cbEVT_TAB_ACTIVATED. Then it'd make sense.

[dmoore]

It's because activation comes from wxAuiNotebook.

It means the tab is "activated" before the file is opened and loaded into the wxAuiNotebook page.

It should be called cbEVT_TAB_ACTIVATED. Then it'd make sense.

Instead, I'd say that based on the current behavior the cbEVT_EDITOR_OPEN should be called something like cbEVT_EDITOR_LOADED. cbEVT_EDITOR_ACTIVATED does fill the pointer with a valid editor control so it's not just about the Tab being active (despite the fact the its implementation uses notebook page switching events). And since ACTIVATED is EFFECTIVELY signalling the creation of a new tab/editor (since it comes before the OPEN) I don't see why we wouldn't call DEACTIVATED when a Tab/editor is removed.

[Pecan]

... cbEVT_EDITOR_ACTIVATED does fill the pointer with a valid editor control ...

No and Yes.

When a Project is loaded, cbEVT_EDITOR_ACTIVATED has an EditorBase, but no Scintilla control. The editor "control" does not appear until the actual cbEVT_EDITOR_OPEN.

After the cbEVT_EDITOR_OPEN, all subsequent cbEVT_EDITOR_ACTIVATED events will contain the scintilla control.

This has given BrowseTracker no end of grief.

[dmoore]

When a Project is loaded, cbEVT_EDITOR_ACTIVATED has an EditorBase, but no Scintilla control. The editor "control" does not appear until the actual cbEVT_EDITOR_OPEN.

so ideally CB should defer add and activating the tab until after the control has been instantiated?