Printable View
If you are handling the modal dialogue close command, then you have an error in logic as Victor says in post #13. Whatever your code is doing for the modal dialogue close command is not correct. You should be able to debug/trace your modal dilogue close code and find the source of the 'crash' during this code.
If my code was not clean why is it closing smoothly without crashing after the processing of data is completed fully.Quote:
Originally Posted by VictorN
But it crashes only If I try to close the dialog window during the processing of data .
It is going smooth and after the last line ..it is popping up error message about Access violation reading location 0xfffffffcQuote:
Originally Posted by 2kaud
Code:CDialogEx::OnClose();
As of now I am managing to "greying" out the close button of dialog box till my processing is completed.Once everything is done/or if intermediate error happens then I am enabling the "close" button so that user can exit the dialog window.
And what about closing the modal dialog using ENTER, ESCAPE, Ctrl+F4?
Is your processing in a thread, or just functions inside the dialog?Quote:
Originally Posted by vcdebugger
Disabling the close button isn't very user friendly. It would be better to interrupt your processing when the close button is pressed, then close the dialog.
Your debugger could likely assist you in determining why it is crashing.
sorry.. I forgot to mention that those processing is happening in a seperate worker thread... I think that is where the problem is. ANy idea how to fix it..Quote:
Originally Posted by GCDEF
Also that worker thread calls 2 console application s via Shellexecute which do the processing
It is impossible to recommend any way for fixing without knowing the basic architecture of your application and your implementation of inter-threading communication and synchronization.Quote:
Originally Posted by vcdebugger
It sounds like your modal dialog close code isn't properly allowing/signalling threads/processes to terminate cleanly - and waiting until they are. But as Victor says in post #24, this is guesswork without knowing much more detail re the application architecture etc - and you should never guess when coding! :eek:
Are your separate worker thread(s) directly updating the UI?
YesQuote:
Originally Posted by salem_c
So, the dialog goes away and some worker thread then tries to update some non-existent UI element and promptly dies.
This is generally regarded as being a big no-no.
https://stackoverflow.com/questions/...ws-thread-safe
https://docs.microsoft.com/en-us/cpp...s?view=vs-2019
That it crashes when you close the dialog could just be the tip of a very large iceberg.
You need to create some inter-thread messaging system, where your worker thread sends say a "progress bar 1 = 20%" to the main UI thread, and the main UI thread itself does the update (and can also check that the dialog still exists).
What other multi-thread sins have you committed, just waiting to come back and bite you at some future time? Maybe your worker threads are busy writing into data structures that your main thread is busy reading from.
You need a PLAN (seriously!) before you add threads to existing code. Every shared function with a side-effect and every bit of shared data needs thinking about. You need a properly designed ownership and responsibility model before you even reach for the keyboard to type in some code. If you're not familiar with all this, then you have lots of studying to do.
If you're up to C++11, then https://en.cppreference.com/w/cpp/thread
Otherwise, your platform API, https://docs.microsoft.com/en-us/win...tion-functions
To be honest, if your code is under some kind of source control, and this "add threads" was a recent change, then I'd definitely suggest creating another branch from your last stable single thread version and starting again.
But if the change was months ago, merged with many other unrelated changes, or you have NO source control, then you really do have your work cut out. The rat's nest of race conditions you've created for yourself will be hard to remove completely.
It sounds like a bad design... :(Quote:
Originally Posted by vcdebuggerYesQuote:
Originally Posted by salem_c
You should access your dialog control only from within the main UI-thread this dialog belongs to. Check it out: Using Worker Threads
Quote:
Originally Posted by VictorN
To avoid that I moved my Progresscontrol and Edit box updates from worker thread to my OnTimer() function of the main dialog box but still it was crashing to some other places where CString's were handled( by the other applications called using SHellExecute from the worker thread - for which I dont have control over).
Now I have removed the worker thread itself from my code and doing everything in the main thread of CDialog itself. But the dialog window freezes now when the processing is happening and when the user click on Onclose ( X) button it will respond later but not crashing!