[Gambas-user] WAIT waits forever - help needed

Benoit Minisini gambas at ...1...
Sat Nov 10 12:43:55 CET 2007


On mercredi 7 novembre 2007, Stefano Palmeri wrote:
> Hi, all. Hi, Benoit.
>
> I made a little utility to convert some audio files
> from a format to another (nothing new) for personal use.
>
> In the FMain class there's a function called
> StartAudioConversion(). That function calls
> UpdateMain() that should refresh the Form before
> starting the conversion progress. Here is the problem:
>
> If I put a "WAIT 0.1" after UpdateMain() the Form is refreshed,
> but the application *waits* forever, I mean it freezes.
>
> If I don't put the "WAIT 0.1" the Form is refreshed after
> the audio conversion process is done.
>
> Any help or explanation will be appreciated.
>
> To test the app you need at least mplayer and
> you have to choose a 4Mb file to see the delay
> in refreshing.
>
> Gambas 1.9.90
>
> Regards,
>
> Stefano Palmeri

The application does not wait forever. It acts actually exactly as you wrote 
it, and you wrote it badly.

Just trace your application step by step, and you will see:

* You open the file dialog to select a file to convert.
* You run a modal dialog to select the destination format.
* You store what to do in some public variable of the modal dialog.
* You close the dialog. As it is not persistent, it will be destroyed.
* You wait (or not) a little.
* You use the public variables of the closed dialog to select the encoder.

Now the trick is that a GUI object is never destroyed immediately, but when 
the event loop returns at the same nested level the object was created. 

I did that because of the way QT and other GUI toolkit handle events. A C++ 
object can be destroyed whereas it is used in the stack by some event 
handler. And that usually leads to segmentation faults.

So, if you do not wait, the QT object is not destroyed, and so the associated 
Gambas form too. So the public variables keep their values, and everything 
works as expected.

But if you wait, then the QT object is destroyed during the wait, and when you 
access the public variables, another form is created (because the Form class 
is in "auto-create" mode, like in Visual Basic), with public variables all 
initialized to their default values.

You select your encoder by a SELECT ... END SELECT that does not use the 
DEFAULT or CASE ELSE keyword. So when the encoder variable is null, the 
program does not freeze, it just does nothing.

I hope I was clear :-)

Regards,

-- 
Benoit Minisini




More information about the User mailing list