wxAPP::OnExit not called with wxWidgets 3.1.1 Topic is solved

[csniper]

My application runs well with wxWidgets 3.1.0. However, the OnExit would not be called in Closing under Linux(GTK3/2) after I linked with 3.1.1.

My code of the App class derived from wxAPP is not changed in the transition, which is still working well on Windows.

Below is the declaration of the class. I could not find any issue. Any suggestions for me to debug? The application exit without crash/exception.

Code: Select all

class MadEditApp:public wxApp
{
	shared_ptr<wxSingleInstanceChecker> m_SigleAppChecker;
	MadAppSrv * m_AppServer;
#if (wxUSE_ON_FATAL_EXCEPTION == 1) && (wxUSE_STACKWALKER == 1)
	MadStackWalker m_StackWalker;
#endif
	bool m_SilentMode;
	bool m_Exit;
	bool m_ForceEdit;
	wxString m_Delimiter;
	wxArrayString m_FileNames;
	wxString m_MadPythonScript;

public:
	MadEditApp() : /*m_SigleAppChecker(nullptr), */m_AppServer(nullptr), m_SilentMode(false), m_Exit(false), m_ForceEdit(false), m_Delimiter(wxT("*")) {}
	virtual bool OnInit();
	virtual int OnExit();
	virtual void OnInitCmdLine(wxCmdLineParser& cmdParser);
	virtual bool OnCmdLineParsed(wxCmdLineParser& cmdParser);
#if (wxUSE_ON_FATAL_EXCEPTION == 1) && (wxUSE_STACKWALKER == 1)
	void OnFatalException();
#endif
	void InitLocale();
	void ShowMainFrame(MadEditFrame *mainFrame, bool maximize);
};

[catalin]

It will not be called if OnInit() has failed or if you explicitly exit() your app. Does it happen for minimal sample too?

[csniper]

No, I tried minimal. It works well.

OnInit did not fail. Other wise the app/frame would not show up.

The original issue is I met a dialog each time I run the app "Deleted stale lock file '/home/username/prog_name-username' ". Googled and found someone said the wxSingleInstanceChecker I used was not released/deleted while exiting, which I did it explicitly in OnExit.

However, I still met the issue after I changed the pointer to shared_ptr as shown in the code above. Looks the shared_ptr was also broken?

[catalin]

Do you have any OnClose() handler? You might need to skip the received event there.

[csniper]

You are the boss!!

It worked well after I added Skip in my OnClose handler! Thanks a lot.

BTW, the issue of shared_ptr might introduced by the code of calling exit in OnClose. I tried to remove it and did not meet crash. So, I should remove the exit, right? And what about the Destroy? The code is used in the OnClose handler of my main frame.

#ifndef __WXMSW__
// it will crash randomly under linux.
// so we must call exit() to quit the app.
exit( 0 );
#else
Destroy(); // quit app normally.
#endif
}

[catalin]

Right.
You should never call exit() because it messes with the normal cleanup. That is valid for any c++ program, see shared_ptr. You normally don't need Destroy() either (unless you have an override that must be called or something like that).

[csniper]

Thanks a lot!

[csniper]

The last question:

You normally don't need Destroy() either (unless you have an override that must be called or something like that).

Does this apply to all? I mean the dialogs I created for my application. I simply do clean up and handle veto in the OnClose handler of the dialog and call Skip() if not veto able? Is this the correct way?

[catalin]

Windows are normally deleted when their parent gets deleted, or by the app in case of TLWs with no parent. If you want a window to be deleted earlier than its parent or app exit, then you can call Destroy() for it. Otherwise Destroy() is not needed when the window would already be on its way to being deleted.
The OnClose() handling sounds about right.

[csniper]

Hi, Catalin,

Do you think it's OK to use DeletePendingEvents in OnClose handler? I met some tricky issue that OnActivate was called after OnClose.

[catalin]

I can't really say, I've never used DeletePendingEvents in about 10 years of using wxW. But it does sound somewhat too drastic tu use it for such a reason.
Did you try to simply Disconnect()/Unbind() your OnActivate() handler in OnClose()?

[csniper]

That's sounds better. Will apply your suggestion.