cbEvents

[frithjofh]

Hi everyone,

I know there are already a lot of topics regarding this, but I think it would really be time to address this theme.

I think the devs should reorganize some events and when they are posted. Especially the EVT_PROJECT_CLOSE and EVT_PROJECT_OPEN. Right now these events are not very clear in my humble opinion, and their behavior still less.

The  EVT_PROJECT_CLOSE gets sent  on closing a project. After that all editors of this project are closed and send their EVT_EDITOR_CLOSE event. When this happens, it seems, that the project is gone already, or what? But there is no EVT_PROJECT_CLOSED event. So a project does cease to exist before its editors?? Pardon me, I am no programmer with a degree or anything, but this just sounds like crap. After project close then, I cannot get the projects name for instance, using an editor to get at it? But I still have an editor for a file in a closed project?

The same applies to EVT_PROJECT_OPEN. First it opens all editors of the "project" (but there really still is no project), so I can't get to any project related information using one of these editors. Then, when all its editors are open, then the project begins to exist? After its own content? Very strange, and by the way, making work difficult without need for anyone developing something in or for c::b.

Well, just my little opinion, but searching the forum, I'm not the only one it seems.

So what can I do? Add the two missing events EVT_PROJECT_CLOSED and EVT_PROJECT_OPENED? I'm not sure if I'm able do change the way c::b opens and closes projects (for my pity faculties). I am also aware that making changes there can and will break a lot of stuff, topmost the plugins. But I do think this should be changed, it is really a messy heritage to carry around.

Regards

frithjofh

[MortenMacFly]

Well the reason here is the same as for the others:
These events are there to intercept them, so there is no point in sending them when its too late.
On the other hand, the CLOSED/OPENED events where simply not needed until now, so they don't exists. I also don't know why you would want to know, when a project has been destroyed, because you could no longer access any information of it, even a pointer to the project would be NULL. So you would have an event "PROJECT_CLOSED" with a NULL pointer attached, thus, all you get to know is "some project has gone". What would be the use-case here?

As for the editors: As long as the SDK methods to obtain an editors' projects do not return NULL, the project is present, of course. You can safely rely on that.

[frithjofh]

Well, I did expect that answer 

But I'm still not convinced totally. If I look over the code in c::b that has to deal with this issue (and associated) I see that it really shines on checking if editor is cbEditor, if it is buildt-in, if it is VisibleToTree(), if it is NULL, and so on and so forth. I enjoy reading code, but this all seems like those examples in books where they tell you what not to do. But picking on you guys for all the work done is a bit unfair ... I know that.

So if your alright with the way these things work, I'll just go along. Maybe I am a little bit annoyed by the fact that the project is not given to the manager directly and be done with it, but that its editors are given to the manager one by one, and then the project is declared open. And the same the other way around when a project is closed. But surly there are reasons for the way things are done, and if the reason were that it was done so at some remote beginning and that is just why, it is fine with me too.

But look, I really think there is much friction introduced by these kind of things, friction in the work progress. I'm sure that all the guys which have hacked on c::b for years just have these things internalized and just don't notice anymore. But for the others out there some design decisions seem rather hard to understand. Every project has its style I guess and one has to adapt.

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.

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 ...

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

Regards and thank you for the answer

frithjof

[oBFusCATed]

Too much words you're using and the noise/signal ratio is too big.
Can you provide code snippet or snippets, where the current events fail to serve their purpose?
This way it will be a bit clear what are the problems or you can be given exact solutions or guides.

EditorBase is some base editor, which must be derived by the real editors. See the wxSmith plugin if you want to see a working editor implementation.
cbEditor is the text editor, also know as the buildin editor.

[frithjofh]

OK:

I'm making a plugin right now. It adds all open and opened files to a list. In the list the file name and the project name of the file are displayed.

When the plugin is enabled and I open a project, the entries in the list show up fine with their file name correctly set, but with their project name empty. I believe this is due to the project not existing at the moment the files are opened. When a file gets opened, the plugin queries for its name and the name of the project. This is triggered by the EVT_EDITOR_OPEN. As the project does not exist at this time, the project name is retrieved as empty. Then the project comes to life, it has a name, and I would be forced to scan the open files to set the project name accordingly.

When the plugin is disabled, and I have a project open, and then enable the plugin the project name is displayed correctly.

I am able to make this work in my plugin, it just does not feel very straight forward.

Also having to query each time for this :

Code

    if ( !an_editor || !an_editor->VisibleToTree() || !an_editor->IsBuiltinEditor() )
        return;

is quite ugly. I still accept the !an_editor part to check against NULL, but the other two are rather awkward, don't you think?

Regards

frithjofh

[oBFusCATed]

Have you look at how openfilelist plugin is done?

Also having to query each time for this :

Code

    if ( !an_editor || !an_editor->VisibleToTree() || !an_editor->IsBuiltinEditor() )
        return;

is quite ugly. I still accept the !an_editor part to check against NULL, but the other two are rather awkward, don't you think?

Why do you care for the VisibleToTree? I don't think it is needed...
The second check is if you want to show only text editors. If you want to show all editors you don't need this check, too.
I see no problem here. Keep in mind that there can be non-text kind of editors, like the GUI editors in the wxSmith plugin.
So, I doubt you know a way to make the IsBuiltinEditor check disappear, if you know I'm all ears.

p.s. please try to keep your code/text ratio larger (e.g. post more code and less text)
p.p.s. can you post the whole snippet that is having the missing project problem or the whole plugin's source?

[frithjofh]

Yes, I looked how it is done in the openfilelist plugin. I copied from there. My code:

Code

Entry::Entry(const EditorBase* editor) :
    m_pEditor(editor),          // no ownership
    m_pAttribute(nullptr),      // no ownership
    m_AgeIndex(-1),
    m_ImageIndex(0),                                           // ascii
    m_ShortName(m_pEditor->GetShortName()),
    m_FileName(m_pEditor->GetFilename()),
    m_ProjectName(wxEmptyString)
{
    if (m_pEditor->GetModified())       m_ImageIndex =  1;     // modified
    else if (m_pEditor->IsReadOnly())   m_ImageIndex =  2;     // read only

    ProjectFile* prjf((static_cast<const cbEditor*>(m_pEditor))->GetProjectFile());
    if(prjf)
    {
        cbProject* prj = prjf->GetParentProject();
        if(prj)
            m_ProjectName = prj->GetTitle();
    }
}

Obviously this class is a sort of wrapper for the files information, some retrieved from c::b, other set by my plugin. Resulting behavior as to the moment is: when the plugin is active and I open a project, the projects name does not get caught. If I have the project already open and then enable the plugin the project name does get caught. Construction of Entry is triggered by EVT_EDITOR_OPEN.

I could listen for the EVT_PROJECT_OPEN and then set the project name to the Entries accordingly, that will work, but that seems very clumsy. This is first problem.

Second issue: no, I do not know right now how to avoid check IsBuiltinEditor(), but I think having to do this check raises the question if inheritance is used right here.

Third issue: I care for VisibleToTree() here (as does the openfilelist plugin) because of the presence of the start page.

regards and thank you for the attention 

[oBFusCATed]

1. Are you sure "m_ProjectName = prj->GetTitle();" is executed?
2. What are you using m_ProjectName(wxEmptyString), the default c-tor does a perfect job
3. Why have you posted the code out of it's context
4. Probably inheritance was not used correctly here, but I doubt it could be changed easily. You can volunteer to try to remedy the situation

[frithjofh]

1. Yes. just ran in debugger and yes, constructor is entered and GetTitle() is executed.
2. I know. I use wxEmptyString here as a more visible reminder to myself.
3. It is not out of context in the sense, that this is the only place in the plugin, where the m_ProjectName member is set.
4. I do. Don't know when. Probably somebody else will be quicker on it.  

[frithjofh]

Thinking about it: I changed the code a bit to see what happens:

1. in the initializer list of Entry I set m_ProjectName to "wtf" (just some example string)
2. inside the constructor I set m_ProjectName to "some other strg"

result:
case a: plugin enabled and then loading project: just "wtf" shows up as project name. that is in this case there is no project yet and so it stays with the initialization from initializer list
case b: first load project, then enable plugin: "some other strg" shows up as project name. in this case the plugin gets the already open editors from the manager, so there the project exists.

[oBFusCATed]

3. It is not out of context in the sense, that this is the only place in the plugin, where the m_ProjectName member is set.

You see the context, but we do not, thus it is out of the context

[frithjofh]

  well okay. Your more stubborn than I am. I admit it is out of context . Do you really need more code, then I'll send? Really the constructor is called without detours by functions taking only a cbEvent, so there is nothing there.

But anyway: what can you tell me about the issue? Any idea?

[oBFusCATed]

Looking at it looks normal, but I guess, the availability of the data depends on the events calling the code you've shown.
I doubt there is some secret part, so showing the full code is not a big problem for you. This will allow people to try it. Or to pin-point something.
I'm not proficient with the C::B events and when I have problems with them I use the debugger to see where is the place where they are sent
and what is the code/state around that place.

btw: Is this a part of the real code "ProjectFile* prjf((static_cast<const cbEditor*>(m_pEditor))->GetProjectFile());" (note the missing =)?

[frithjofh]

yes, this is the real code:

Code

ProjectFile* prjf((static_cast<const cbEditor*>(m_pEditor))->GetProjectFile());

I do this a lot (shame on me for readability), but its not an assignment, but a construction, actually.

I think the issue is that on opening a project cbEVT_EDITOR_OPEN events are sent before the project actually exists. I will use the trailing cbEVT_PROJECT_OPEN to set the name of those editors afterward. This is a bit ugly, and not very intuitive, but I recon nobody (not me for sure) will change the way these events are fired.

For the moment I stay put. When the plugin is in any presentable shape, I'll post it. Its function will combine the OpenFileList and the ClosedFileList in one and add a visual history of files. The most of it is working already, but I not satisfied yet.

Thanks for all the attention and greetings from Asturias 

[oBFusCATed]

Then can you show the callstack for the non-working case a?