Is there an event generated when an application 'gets focus' within windows

  • Thread starter Thread starter Glyn Meek
  • Start date Start date
G

Glyn Meek

When running an application, and the user uses the minimize button to shrink
it from the screen, is there an event generated when the application is once
more 'maximized'?

Similarly, is this the same event that is generated when a user clicks on
the application to 'bring it to the front' and make it the active app?

regards

Glyn Meek
 
Here's the problem I was trying to solve...

I have an application that process graphic all image files (raster .tif and
..tga format) which are in excess of 1.4 gigabytes each. Fairly large files
even for graphical images, 22"x28" at 600 dpi RGB. It takes these programs
5-6 hours to run on a relatively fast PC (Dell Dimension 4600) with 1 gig of
RAM.

The program has 3 nested loops, and I use 3 different progress bars to
display where each loop is, and I also display 'counts' for each of the
loops as well. After each count display, I do a count.refresh to display the
update count on the screen. Evrything works great and the bars move and the
counts display as long as the application window is 'on top', and I am not
doing anything else.

BUT...if I go off and do some other work while this program is running in
the background (which I tend to do, as like most programmers, I have a low
boredom threshold...lol) , the counts stop updating completely on the screen
and the progress bars just freeze. I cannot find a way to 'restart' the
counts appearing. I have tried 'refreshing' controls and screens alike and
it seems to have no effect. The program does NOT stop executing though, and
continue to run successfully (as I get to find out 3 or 4 hours later...:-))
it just doesn't show me its progress any more.

My thought was to recognize the 'application getting focus' event, and at
that point do a me.refresh to see if this makes any difference, and starts
the progress bars and the counts again.

Hope this makes sense Imran, and if you have any ideas as to why the
displays 'stop' I'd love to hear them.

Regards and thanks for the response

Glyn Meek
 
For one thing - are you using Application.DoEvents in your loops since these
are taking so long? That way the UI has a chance to repaint itself and in
that case you probably wouldn't even have to do refresh on the controls as
long as you are correctly updating the progress bars in your loop as you are
proceeding. A cleaner solution would be create a new thread to do the
processing on your graphics so that the main thread is free. Here's a small
program that I have that will simulate the kind of behaviour you are trying
to achieve:

Imports System.Threading

Public Class Form1
Inherits System.Windows.Forms.Form

Private WorkerThread As New Thread( New ThreadStart( _
AddressOf MyLongMultiLoopProcedure))

Private Sub MyLongMultiLoopProcedure()
Dim lCnt1 As Integer
Dim lCnt2 As Integer
Dim lCnt3 As Integer

For lCnt1 = 1 To Integer.MaxValue
If lCnt1 Mod 10000 = 0 Then
ProgressBar1.Value = lCnt1
End If
For lCnt2 = 1 To Integer.MaxValue
If lCnt2 Mod 10000 = 0 Then
ProgressBar2.Value = lCnt2
End If
For lCnt3 = 1 To Integer.MaxValue
If lCnt3 Mod 10000 = 0 Then
ProgressBar3.Value = lCnt3
End If
Next
Next
Next
End Sub

Private Sub Form1_Load(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
For Each oControl As Control In Me.Controls
If TypeOf oControl Is ProgressBar Then
CType(oControl, ProgressBar).Minimum = 0
CType(oControl, ProgressBar).Maximum = Integer.MaxValue
End If
Next
End Sub

Private Sub Form1_Closing(ByVal sender As Object, _
ByVal e As System.ComponentModel.CancelEventArgs) _
Handles MyBase.Closing
If WorkerThread.IsAlive Then
WorkerThread.Abort()
End If
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
WorkerThread.Start()
End Sub

Private Sub Button2_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button2.Click
WorkerThread.Abort()
End Sub

End Class

I have ommited the form designer code - basically, I've just placed 3
progress bars named progressbar1, progressbar2 and progressbar3 and two
buttons btStart and btStop. btStart will start the new thread which executes
the long running procedure with 3 time consuming loops. btStop will stop
it - obviously :)
If you run this program, you'll see that the UI never freezes up since the
main thread (running the UI) is free while the new thread that we created is
doing the work. Try calling the procedure directly (just replace
WorkerThread.Start with MyLongMultiLoopProcedure( ) ) and although the
progressbars update, you'll notice that the form does not respond. Also, if
you activate any other application in front of the form, the form stops
responding and nothing appears on the form although ofcourse the process is
still running and you'll know when it finishes :)
You could do away with adding the line Application.DoEvents in each of the
loops and it should work fine but I think threads would be the way to go for
you.

hope this helps..
Imran.
 
When a form changes state with respect to normal windowed state, maximized,
and minimized, the SizeChanged event fires. In that event you can inspect
the form's WindowState property to find out which of those states the form
is in. If you save the WindowState value each time in an instance variable,
you can easily detect window state changes.

The Activated event is the one that fires when a form gets the keyboard
focus (which is what happens when the user clicks on the form to 'bring it
to the front'.

HTH,
Tom Dacon
Dacon Software Consulting
 
Back
Top