Table of Contents
10.5.9 Application.Busy
Using the value of the property Application.Busy of the class Application (gb. qt4), you change the 'Busy state' of an application.
10.5.9.1 Notes
- The property Application. Busy has the data type Integer with the default value 0.
- You change the property Application. Busy either with' Inc Application.Busy' and' Dec Application.Busy' or with' Application.Busy = 1' and' Application.Busy = 0'. Only the values 0 and a value greater than zero are relevant.
- You should set the value of this property to 1 if the application starts a statement or sequence of statements that takes a long time or is to be executed free of interruptions. Then decrease the value back to 0.
- If the value of the Application. Busy property is greater than zero, the mouse pointer changes automatically but temporarily to Mouse. wait, indicating that the application is busy and does not respond to user input.
- If an error occurs after the statement' Inc Application.Busy' or' Application.Busy = 1', you must intercept it and react appropriately. Do not forget to reset the value of Application.Busy to 0.
Suggestion:
Apply a button to a form in an example project and include the following source code as an event handler to see the effect of using the Application.Busy property:
Public Sub btnSetBusy_Click() Dim iCount As Integer Inc Application.Busy ' Alternative: Application.Busy = 1 For iCount = 1 To 40000 Print Sqr(iCount + Pi(0.533)) Next ' iCount Dec Application.Busy ' Application.Busy = 0 Message.Info("That's all it was..") End
10.5.9.2 Examples
The examples serve to demonstrate the use of the control element Application. Busy in different applications.
Example 1
In an application for installing gambas via SVN, the local version number on the PC is first queried and then the number of the current revision on the SVN server. For this query, the program will use the mouse pointer to indicate the “Binary busy state” and will not respond to user input. If an error occurs, it is intercepted, an error message is issued and the program is released again with' Dec Application. Busy'. The release is also carried out if the revision number could be determined without errors.
Public Sub btnUpdateStart_Click() Dim sResult, sMessage As String Dim iTimeOut As Integer ' ... Inc Application.Busy ' Mouse.Wait Repeat Shell "cd " & sSVNPfad & "; svn info -r HEAD | awk '$1 ~ /^Revision:$/ {print $2;}'" To sResult Inc iTimeOut Until (sResult <> Null Or iTimeOut > 9) Try iSVNCurrentRevision = Val(sResult) If Error Then Message.Error("The SVN server is currently unavailable!") Dec Application.Busy Return Endif ' ERROR ? Dec Application.Busy ' Mouse.Default End ' btnUpdateStart_Click()
Figure 10.5.9.2.1: The queries were successful
Example 2
A print program does not accept any more entries in the time in which it is printed:
Public Sub btnPrintImage_Click() If printerImage.Configure() Then Return Me.Enabled = False ' The form is deactivated Application.Busy = 1 ' The program does not accept any more entries.. printerImage.Print ' The print job is started.. Application.Busy = 0 ' The program accepts input again.. Me.Enabled = True ' The form is reactivated End ' btnPrintImage_Click()
Example 3
As a sub-process for the installation of a program (update) from existing packages, the statement /configure -C is executed, which analyzes the system, configures the packages and generates the makefile. The main program ignores all entries for the runtime of the subprocess:
Public Sub btnConfigureUpdate_Click() Inc Application.Busy sShellCommand = "echo 'CONFIGURE';echo '---------------------------';" sShellCommand &= " cd " & sSVNPfad & ";./configure -C" GoToTerminal(GetTerminalList()[0], sShellCommand) btnMakeUpdate.Enabled = True Dec Application.Busy End
Example 4
For the Watcher class demonstration program (→ chapter 20.10 Watcher) the monitored events should be handled and documented with messages in separate windows. The following source code extract from the testing phase for the project caused not only errors, but also a program crash, because the constant change (move or resize) caused message windows to be generated:
Public Sub wWatcher_Resize()
Message.Info(("The main window " & wWatcherObject1.Control.Name & " has changed its size!"))
Stop Event
End
Public Sub wWatcher_Move()
Message.Info(("The main window " & wWatcherObject1.Control.Name & " has changed position!"))
Stop Event
End
The thoughts and approaches to the solution:
- Message is a static class of which only one object exists (even if it is not displayed).
- The event cascade when moving or enlarging the window manually occurs as follows: As soon as the message box of the first event handler is displayed, the interpreter waits for this dialog to close. Waiting is handled by the event loop (it waits for the button to be clicked in the dialog). But then the next event comes from the watcher and the interpreter executes the event handler, which causes the error.
- A solution to avoid an event cascade is to keep the watcher from generating new events, for example with the “Application.Busy” strategy!
- As soon as one of the error-prone events (Move or Resize) is triggered, the Application.Busy property is set to 1 in the event handle and the message box is called. After closing the box, the property is reset to 0 and the event is stopped.
- The relevant event handler only calls the message box if the Application.busy property has the value 1.
- Application.Busy acts here as primitive mutex (→ http://de.wikipedia.org/wiki/Mutex)
Here is the corrected section of the source code:
Private sControlName As String ' ... sControlName = "'" & wWatcherObject1.Control.Name & "'" ' ... Public Sub wWatcher_Resize() Application.Busy = 1 If Application.Busy = 1 Then Message.Info("The window " & sControlName & " has changed its size!") Application.Busy = 0 Stop Event End Public Sub wWatcher_Move() Inc Application.Busy If Application.Busy = 1 Then Message.Info("Das Fenster " & sControlName & " has changed position!") Dec Application.Busy Stop Event End

