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

cbEvents

(1/6) > >>

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;

--- End code ---
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

Navigation

[0] Message Index

[#] Next page