Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Puzzling cbEVT_EDITOR_* event behavior
dmoore:
--- Quote from: MortenMacFly on December 10, 2009, 06:44:32 am ---
--- Quote from: dmoore on December 10, 2009, 06:04:35 am ---When an editor is closed cbEVT_EDITOR_ACTIVATED for any new editor then cbEVT_EDITOR_CLOSED, but no cbEVT_EDITOR_DEACTIVATED!
--- End quote ---
Correct here, too as the editor closed is not "de-activated" (meaning still accessible), but truly destroyed.
--- End quote ---
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:
--- Quote from: dmoore on December 10, 2009, 03:35:11 pm ---
--- Quote from: ollydbg on December 10, 2009, 02:25:39 pm ---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
--- End quote ---
not quite: cbEVT_EDITOR_DEACTIVATED of A, cbEVT_EDITOR_ACTIVATED of B then cbEVT_EDITOR_OPEN of B
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version