fixing EVT_PROJECT_OPEN

[pauliusz]

Problem: Currently EVT_PROJECT_OPEN event is generated in "wrong" place... (Bug #11233)

Reason: EVT_PROJECT_OPEN event was moved to "wrong" place in revision 1437 (long long time ago), because there were problems with code-completion(CC).

Solution: Since CC doesn't use EVT_PROJECT_OPEN anymore it is safe to move it back to "right" place.

I could do this by myself, but I not sure about all these "new" protections if workspace is loading...

[rickg22]

And what's the "right place"?  :?

[pauliusz]

And what's the "right place"?  :?

You can see it in the change log of revision 1437.
You can also see it if you will search files for EVT_PROJECT_OPEN.

[dje]

Hi !

You can see it in the change log of revision 1437.
You can also see it if you will search files for EVT_PROJECT_OPEN.

Far easier than giving file/method/line in current version  :wink:

Dje

[thomas]

Is it really necessary to change yet another core behaviour without urgent need at this time?

I can't tell beforehand what effects this particular change will have, but I can tell what effect the last few had.

[pauliusz]

Is it really necessary to change yet another core behaviour without urgent need at this time?

I think Pecan could give some comments about that.

I can't tell beforehand what effects this particular change will have, but I can tell what effect the last few had.

I have looked at placed where EVT_PROJECT_OPEN is used and it looks like there shouldn't be any problems. But I'm not 100% sure

[Pecan]

Is it really necessary to change yet another core behaviour without urgent need at this time?

I can't tell beforehand what effects this particular change will have, but I can tell what effect the last few had.

I believe it should be corrected before an sdk release.

I've had to rely on using the project hooks instead of the cbEvents for plugins.

As it is now, editor activation and project activation events occur before project open events.

This really screws with the maintenance of dynamic arrays holding objects or pointers to editors.

If a release of the sdk goes out with this problem, plugin writers can never rely on these cbEvents.
We'll just have to tell them to use the Project and Editor hooks instead. Much more overhead.

I'll write up a simple plugin today to show the problem.

[rickg22]

Pecan, you could also use EVT_WORKSPACE_CHANGED, I put it there *EXACTLY* for that reason. When the new project has finished opening, the EVT_WORKSPACE_CHANGED is triggered. Perhaps you could use it in combination with EVT_PROJECT_OPEN..

[Pecan]

Pecan, you could also use EVT_WORKSPACE_CHANGED, I put it there *EXACTLY* for that reason. When the new project has finished opening, the EVT_WORKSPACE_CHANGED is triggered. Perhaps you could use it in combination with EVT_PROJECT_OPEN..

Sorry, that won't work. Here's why:
The sequence of events when loading a project:

Code

Loading a project

10:34:55: [1419125ms] EVT_EDITOR_DEACTIVATED [050C8B18][]
10:34:55: [1419125ms] EVT_EDITOR_ACTIVATED [050C8B18][]
10:34:55: [1419172ms] EVT_EDITOR_OPEN [050C8B18][EventsDisplay.cpp]

10:34:55: [1419187ms] EVT_EDITOR_DEACTIVATED [028EDA58][]
10:34:55: [1419187ms] EVT_EDITOR_ACTIVATED [028EDA58][]
10:34:55: [1419219ms] EVT_EDITOR_OPEN [028EDA58][EventsDisplay.h]

10:34:55: [1419234ms] EVT_EDITOR_DEACTIVATED [050C8B18][EventsDisplay.cpp]
10:34:55: [1419234ms] EVT_EDITOR_ACTIVATED [050C8B18][EventsDisplay.cpp]
10:34:55: [1419234ms] EVT_EDITOR_ACTIVATED [050C8B18][EventsDisplay.cpp]

10:34:55: [1419266ms] EVT_PROJECT_ACTIVATE[] 
10:34:55: [1419266ms] EVT_PROJECT_OPEN 
10:34:55: [1419266ms] EVT_EDITOR_DEACTIVATED [050C8B18][EventsDisplay.cpp]
10:34:55: [1419266ms] EVT_EDITOR_ACTIVATED [050C8B18][EventsDisplay.cpp]
10:34:55: [1419281ms] EVT_WORKSPACE_CHANGED[] 
10:34:55: [1419281ms] EVT_WORKSPACE_CHANGED[]

 Now closing the project
 
10:35:10: [1433953ms] EVT_PROJECT_CLOSE[] 
10:35:10: [1433953ms] EVT_EDITOR_DEACTIVATED [05095BA8][]
10:35:10: [1433953ms] EVT_EDITOR_ACTIVATED [05095BA8][]
10:35:10: [1434062ms] EVT_EDITOR_CLOSE [050C8B18][unavailable]
10:35:10: [1434078ms] EVT_EDITOR_DEACTIVATED [05095BA8][Start here]
10:35:10: [1434094ms] EVT_EDITOR_ACTIVATED [05095BA8][Start here]
10:35:10: [1434094ms] EVT_EDITOR_CLOSE [028EDA58][unavailable]
10:35:10: [1434109ms] EVT_EDITOR_DEACTIVATED [05095BA8][Start here]
10:35:10: [1434109ms] EVT_EDITOR_ACTIVATED [05095BA8][Start here]
10:35:10: [1434125ms] EVT_WORKSPACE_CHANGED[] 
10:35:10: [1434125ms] EVT_WORKSPACE_CHANGED[] 

If you used EVT_WORKSPACE_CHANGED, you'd miss every open/activate on every editor.
If you wanted to wait until a project opened, you again would miss every editor.

The whole sequence is backwards. OR... I'm misunderstanding the purpose of the events.


http://www.savefile.com/files/848388


Above is a url containing cbEventsDisplay.zip with source and .cbplugin for MSW .
Use Plugins/Manage Plugsin/Install new/ to install and remove it.

It'll open up a log in the upper left and log the events as they occur.

 

[rickg22]

Well, I'm suggesting a workaround. Try adding a queue to your plugin.

Like

Code

OnEditorActivate(...)
{
  if(ProjectManager::IsBusy())
     m_filequeue.insert(theeditor);
  else
     do_stuff_on_editor(theeditor);
}

OnEditorDeActivate(...)
{
  if(ProjectManager::IsBusy())
     m_filequeue.erase(theeditor);
  else
     undo_stuff_on_editor(theeditor);
}

OnWorkspaceChanged...
{
  Do_stuff_on_filequeue();
  filequeue.clear();
}

Since I don't really know what you're doing, I can't suggest a specific method, but what I do goes around those lines.

But yes, I agree that in this case, the PROJECT_OPEN should be triggered before.

The problem is WHAT WE WANT the events for.

Should we have a PROJECT_BEGIN_OPENING and PROJECT_FINISHED_OPENING events?

In any case, PROJECT_OPEN should go immediately *BEFORE* PROJECT_ACTIVATE. And PROJECT_CLOSE should go immediately *AFTER* PROJECT_DEACTIVATE for the events to have some coherence.

The real question is, if by doing this, we break existing functionality on the plugins.

[rickg22]

Code

10:35:10: [1434125ms] EVT_WORKSPACE_CHANGED[] 
10:35:10: [1434125ms] EVT_WORKSPACE_CHANGED[] 

WHOA! That EVT_WORKSPACE_CHANGED should only happen once!  :shock:
I need to look into that...

[Pecan]

Well, I'm suggesting a workaround. Try adding a queue to your plugin.

Yes, I have plenty of workarounds. The best of which is to simply use the editor/project hooks. They occur in the correct order.

Just thought it'd be nice to actually have a SDK that's dependable.

But if not... we'll learn and use the hack-arounds.

[thomas]

Code

10:35:10: [1434125ms] EVT_WORKSPACE_CHANGED[] 
10:35:10: [1434125ms] EVT_WORKSPACE_CHANGED[] 

WHOA! That EVT_WORKSPACE_CHANGED should only happen once!  :shock:
I need to look into that...

This is a long known condition (see the other thread). It happens for several events.
PLEASE do not add another workaround for this.

[rickg22]

This is a long known condition (see the other thread). It happens for several events.
PLEASE do not add another workaround for this.

What other thread?

[MortenMacFly]

What other thread?

I believe he meant this one:
http://forums.codeblocks.org/index.php/topic,6300.msg48355.html#msg48355