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

Puzzling cbEVT_EDITOR_* event behavior

<< < (3/3)

dmoore:

--- Quote from: Pecan on December 11, 2009, 02:26:12 pm ---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.

--- End quote ---

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:

--- Quote from: dmoore link=topic=11663.msg79336#msg79336 ---
... cbEVT_EDITOR_ACTIVATED does fill the pointer with a valid editor control ...

--- End quote ---

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:

--- Quote from: Pecan on December 12, 2009, 02:17:39 pm ---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.

--- End quote ---

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

Navigation

[0] Message Index

[*] Previous page