🚀 go-pugleaf

Well, I did say it was a simplified version :)
I should have done a better job of writing the demo code.  The actual 
code is within a function that reads from the hardware and shows a 
progress bar basically indicating the timeout period.  The program 
crashes at random times of program execution after a random number of 
calls to this function.

I hear your point about threads.  I suppose I can look at that.

But back to the original point, I don't know why the error is occurring; 
I don't believe there are any other exit points or any exceptions thrown 
except out or system resources. I am using Eureka Log to track program 
execution and that's how I identified this spot; it doesn't show any 
other exceptions and PC-Lint doesn't report any errors in the code at all.



Remy Lebeau (TeamB) wrote:
> "Dan Mayo" <dmayo@dickey-john.com> wrote in message
> news:45afd751$1@newsgroups.borland.com...
> 
>> YES  There is no other way for the code to exit from that function.
> 
> What about if exceptions occur?  You are not protecting your code from
> that scenerio at all.
> 
>> My whole user interface has a number of other buttons, labels,
> graphs,
>> etc.  The weird thing I don't understand is that I am basically in a
> loop:
> 
> You don't need to re-create the form on each iteration of the loop.
> You could create it once and then let the loop show/hide it as needed.
> 
> Try this instead:
> 
>     void MyClass::TheLoop()
>     {
>         TMyForm *theDialog = new TMyForm(NULL); // no Owner needed
>         try
>         {
>             bool Stop = false;
>             while( !Stop )
>             {
>                 theDialog->ProgressBar->Position = 0;
>                 theDialog->ProgressBar->Max = ...;
>                 theDialog->Stopped = false;
>                 theDialog->Show();
> 
>                 TriggerLongHardwareRelatedTask();
> 
>                 bool DoingSomeLongHardwareRelatedTask = true;
>                 while( DoingSomeLongHardwareRelatedTask && !Stop )
>                 {
>                     if( theDialog->ProgressBar->Position <
> theDialog->ProgressBar->Max )
>                         theDialog->ProgressBar->StepIt(); // Set the
> Step property to 1
>                     else
>                         theDialog->ProgressBar->Position = 0;
> 
>                     DoingSomeLongHardwareRelatedTask =
> !HardwareTaskComplete();
> 
>                     Application->ProcessMessages();
>                     Stop = theDialog->Stopped;
>                 }
> 
>                 theDialog->Hide();
>             }
>         }
>         __finally
>         {
>             delete theDialogThatCrashes;
>         }
>     }
> 
> 
> Now, with that said, you should seriously consider moving the hardware
> code into a separate worker thread instead.  The thread can post
> notifications about its status to the main thread to update the
> dialog.  It is not good to perform lengthy operations in the main
> thead, and call ProcessMessages() like that can introduce other subtle
> problems elsewhere.
> 
> 
> Gambit
> 
>