wxEVT_BUILD_STARTING event

[jfouche]

Hi

I would like to know if I can create the wxEVT_BUILD_STARTING event to notify plugins that the build process is going to start.
Looking to the sources, I think I can put it just before the wxEVT_BUILD_STARTED is send, because at this time, the build process has not begin : the CompileRequest::Process() method actually send the event using ProcessEvent so I'm sure that the BuildTab::OnBuildStarted method is called before build process. My problem comes from this method name which make me think that the build had already started. May I have to create a specific method in CompileRequest::Process() to be sure that there will never have problem with this event handling (don't know what's gonna append in the futur...) ?
I don't know if I'm very clear...
What are your point of view ?

[eranif]

SImply add new event in compiler_action.h/cpp: wxEVT_BUILD_STARTING
Next, send it inside:
CustomBuildRequest::Process(IManager *manager)

and

CompileRequest::Process(IManager *manager)

Code: Select all

wxCommandEvent event(wxEVT_BUILD_STARTING);
// since this code can be called from inside the application OR 
// from inside a DLL, we use the application pointer from the manager
// when available, otherwise, events will not be processed inside 
// plugins
wxApp *app(wxTheApp);
if(manager) {
    app = manager->GetTheApp();
}

app->ProcessEvent(event);

- dont forget to send me a patch

Eran

[sdolim]

I think this event should be declared in plugin.h, where wxEVT_BUILD_STARTED is.

[jfouche]

Well, thank you
One more question : Why do the wxEVT_BUILD_STARTED is sent by the BuildTab, and not directly by the CompileRequest::Process() method ?
I will provide you a patch in few time

[jfouche]

Here is the patch (sorry about triming end lines...)
The project name is given as client data
Tested with VersionManager plugin.

[jfouche]

Hi Eran
Have you had a look to this patch ?
I just would like to know if this can be implemented or not, because I use this event in my plugin.
Thanks for your answer

[eranif]

Yes,
There were 2 issues with it:
- I added the same event to custombuildrequest.cpp
- SetClientData was called for proj->GetNane() which return temporary variable it actually lead to passing pointer to an address which has already been destroyed.

So instead of:

Code: Select all

event.SetClientData(&(proj->GetName()));

I simply modified it to:

Code: Select all

wxString pname (proj->GetName());
event.SetClientData((void*)&pname);

Other than that the patch looks fine and committed


Eran

[jfouche]

Thanks a lot Eran

I don't understand the local variable problem, because even if there is a warning (I know this is BAD (TM)), it was not a local variable, because proj was a shared_pointer (so an existing value). Reading your modifications, I can see a local variable also (maybe I'm wrong... surely).

Code: Select all

wxString pname (proj->GetName());
event.SetClientData((void*)&pname);

pname is a local variable also ? No ?
Thanks a lot for this new event

[eranif]

I don't understand the local variable problem, because even if there is a warning (I know this is BAD (TM)), it was not a local variable,

Dont mix between temporary variable and local variable - this is what my change did it copied the temporary variable into a local variable and passed it to ProcessEvent()

If you look at the prototype of

Code: Select all

wxString Project::GetName() const

the return value is temporary variable which it is undefined when it will be destroyed.

My change passes a local variable which is guarantees to remain valid until the ProcessEvent() finishes.

HTH,
Eran

[asterisc]

That's simply not true!

A msdn quote:
All temporaries created as a result of expression evaluation are destroyed at the end of the expression statement (that is, at the semicolon), or at the end of the controlling expressions for for, if, while, do, and switch statements.

A "C++ standard" quote:
Temporary objects are destroyed as the last step in evaluating
the full-expression (1.9) that (lexically) contains the point where they were created. This is true even
if that evaluation ends in throwing an exception.

It makes no sense in using the local variable at all.