Dialogue form remains visible during program execution

[Ger]

My dialogue form (sometimes partly, sometimes as a whole) remains visible
during a fairly long processing job.
The dialogue asks the user to enter some data for the job to follow, and
after OK, should disappear and the processing job (Sub CreateHTML()) starts,
while showing a progress bar in the main form.
The problem is that the dialogue form stays visible and does not close
during execution of the job. It closes after the job is finished.
What am I doing wrong? Should I start a separate thread for the processing
job, or is there a more simple solution I am not aware of yet? Code below:

Dim fh As New frmHTML
If fh.ShowDialog(Me) = DialogResult.OK Then
'save dialogue data:
'(not relevant I think, but left it in for clearity)
DBDirectory = Directory.GetCurrentDirectory
HLang = fh.cmbLanguage.Text
HMainOnly = fh.radMain.Checked
HVarCols = Val(fh.txtCols.Text)
DBDirectory = fh.txtOutput.Text
fh.Dispose() 'Get rid of the dialogue form (I thought......)
' do the processing job:
CreateHTML()
Else
fh.Dispose()
End if

Thank you for replying.
/Ger

 

[C-Services Holland b.v.]

My dialogue form (sometimes partly, sometimes as a whole) remains visible
during a fairly long processing job.
The dialogue asks the user to enter some data for the job to follow, and
after OK, should disappear and the processing job (Sub CreateHTML()) starts,
while showing a progress bar in the main form.
The problem is that the dialogue form stays visible and does not close
during execution of the job. It closes after the job is finished.
What am I doing wrong? Should I start a separate thread for the processing
job, or is there a more simple solution I am not aware of yet? Code below:

Dim fh As New frmHTML
If fh.ShowDialog(Me) = DialogResult.OK Then
'save dialogue data:
'(not relevant I think, but left it in for clearity)
DBDirectory = Directory.GetCurrentDirectory
HLang = fh.cmbLanguage.Text
HMainOnly = fh.radMain.Checked
HVarCols = Val(fh.txtCols.Text)
DBDirectory = fh.txtOutput.Text
fh.Dispose() 'Get rid of the dialogue form (I thought......)
' do the processing job:
CreateHTML()
Else
fh.Dispose()
End if

Thank you for replying.
/Ger

Try inserting an application.doevents right after the dispose. That
gives the app the time to clean up the graphics.

Rinze

 

[Cor Ligthert]

Ger,

In my opinion your program should work, did you try it with another dialog
form with by instance only this on it?

Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Me.DialogResult = DialogResult.OK
End Sub

Just to try the effect?

Cor

 

[Cor Ligthert]

Rinze,

The dispose does not close the form, it should give the resources back to
the GC, however I am more and more in doubt if that it is needed. A form
created with the designer implements Idisposable, so it should do it itself.

However there is a MSDN page that tells that only forms showed with show
will be disposed. But it is for me absolute not clear what with that is
meant. I am more and more in doubt if that page is telling about a form that
not implements IDisposable and is made directly by code.

(Therefore I am really curious if your recommendation will help)

Just my thought,

Cor

 

[Ger]

Cor,
Thank you for your reply. Your example works fine, as other dialogues in my
application do also. But in all these cases the applications awaits further
user interactivity after handling the dialogue, so there is time enough to
close the dialogue.
The problem however seems to be here that the framework (or windows?) is
very busy processing the job (createhtml), and has no time to close the
dialogue form until the job is done. I do not know how to deal with that,
apart from running the job in a separate thread.
Thanks anyway,
/Ger

 

[Ger]

Try inserting an application.doevents right after the dispose. That
gives the app the time to clean up the graphics.

Rinze

Thank you Rinze, that did the trick! But I inserted the doevents statement
just before the sub (createhtml) is executed, not after the dispose as you
suggest, and it works OK now. Thanks again.

 

[Cor Ligthert]

Ger,

When what you say is true, than you can use the information from Rinze

However set than directly after your dialog.OK then that
application.doevents.
I doubt about it however you never know and "Niet geschoten is altijd
misgeschoten".

I tested it because I am curious as well and have placed on that place a
threading.thread.sleep(3000), the dialogform did disapear however directly.

Can you show some code from your dialogform?

(I do not think that multithreading is a solution in this, with that it can
be even more difficult to let it disapear).

Cor

 

[Cor Ligthert]

Ger,

I did not read this message before I sand mine.



Cor

 

[Cor Ligthert]

Ger,

Wrong place so again

I did not read this message before I sand mine where is almost the same said
to try.



Cor

 

[C-Services Holland b.v.]

Rinze,

The dispose does not close the form, it should give the resources back to
the GC, however I am more and more in doubt if that it is needed. A form
created with the designer implements Idisposable, so it should do it itself.

However there is a MSDN page that tells that only forms showed with show
will be disposed. But it is for me absolute not clear what with that is
meant. I am more and more in doubt if that page is telling about a form that
not implements IDisposable and is made directly by code.

(Therefore I am really curious if your recommendation will help)

Just my thought,

Cor

AFAIK disposing means releasing all resources, thus it should also be
removed from the graphics part. But since a CPU intensive task was
started right away, the OS didn't get time to clean up the graphics
plane so what was left was merely an echo of the form. Calling DoEvents
lets the OS handle those events and redrawing/updating the screen.

At least that's how I understand what is happening

Rinze

 

[Cor Ligthert]

Rinze,

When there is no reference anymore to it, so that is why I did not say it
would not work, however when the form is on screen and there is no reference
anymore to it, would be very strange in my opinion..

Cor

 

[Ger]

Cor,

However set than directly after your dialog.OK then that
application.doevents.
I doubt about it however you never know and "Niet geschoten is altijd
misgeschoten".

True! Rinzes solution worked for me.

I tested it because I am curious as well and have placed on that place a
threading.thread.sleep(3000), the dialogform did disapear however directly.

Can you show some code from your dialogform?

The dialogue form asks the user to enter a file name and a few selection
options.
After clicking OK the application starts reading a large database
sequentially with datareader. During this process a html file is created, as
well as the required gif images in separate image files. This process is
indeed very CPU intensive, so I guess Rinze's conclusion is correct. It
probably also depends on the processor speed and available memory and other
resources.
Thank you Cor for your replies.
/Ger

 

[james]

I have an application that imports XML & CSV databases and whenever I would
select a very large file to proccess the OpenFile Dialog would hang until
the proccess was completed. I tried the Application.DoEvents and it worked
great!! Made all the difference in the world.
Glad you posted this, I was pulling my hair out (what little I have left)
trying to figure out how to fix this.
james