Back to Contents        Previous        Next







26. ‘Internal multitasking’ **

We have already said that applications using the Wimp are multitasking - meaning that more than one such application can be active at the same time and the user can take action with any of them unhindered.

However, this section is about multitasking within an application - so that one task can be going on whilst the user takes another action within the same application. This can be useful when there is a process which may take a long time to carry out e.g. complex number crunching, file finding, etc. This Section shows how operations like these can be made to multitask.

Some methods of multi-tasking using Dr Wimp involve the special global variable NULL% which was introduced in Section 1.4 of this Manual. In these cases, it is necessary to set NULL% to TRUE at some point in your programme and this, in turn, causes PROCuser_null to be called - in which your multi-tasking code can be put.

In Dr Wimp, when your application is initialised, NULL% is set to FALSE - and when it enters the main Wimp-poll loop, this ensures that the Wimp is told not to let the application know every time a ‘no-action needed’ Reason Code (’null event’) occurs. This is because such events occur more or less continuously and an application simply does not normally need to know about them.
However, if at any time, NULL% is set to TRUE the Wimp poll starts receiving these null events and, in turn, calls PROCuser_null every time that it receives one - i.e. more or less continuously.
Thus, inside PROCuser_null, you could call a routine to do a small bit of work each time - ‘small’ because you will block the computer unless responses to null events are very short. Hence to utilise this option for a long task is complicated. (There is a simple application, called !FastSlow, using this method in the Examples folder.)

An easier option in Dr Wimp is to use PROCwimp_singlepoll. When called, it goes through the polling loop just once and if, at that time, NULL% is set to TRUE, PROCuser_null will be called once.

Assuming your application is already using the normal Dr Wimp PROCwimp_poll, it will already be in this loop, so all you have to do is call PROCwimp_singlepoll inside it. This very simple technique makes powerful multitasking operations very easy to achieve.

PROCwimp_singlepoll can also be useful without needing to use NULL% or PROCuser_null - as is demonstrated below.

Retrieve the complete !MyApp application as left in Section 2.15 (a copy is in the Tutor1 folder) and in the !RunImage listing change PROCuser_menuselection so it has lines like:

CASE menu% OF
WHEN iconbarmenu% :
         CASE item% OF
         WHEN 1 : PROCchangeauthor
         ENDCASE
ENDCASE


Now add the following new custom function definition at the end of !RunImage:

DEF PROCchangeauthor
FOR L%=1 TO 200
         PROCwimp_singlepoll
         a$=“”
         FOR M%=1 TO 6
         a$+=CHR$(RND(26)+64)
         NEXT M%
         PROCwimp_puticontext(info%,2,a$)
PROCwimp_pause(0.1):REM** To slow action down **
NEXT L%
ENDPROC


Save the !RunIamge, run !MyApp and click on the first item on the iconbar menu. If you now look at the info window, the author field should be constantly changing with random letters. You can still use the desktop, and even quit the application, during this routine’s run. (Note that this simple demonstration will only act for 200 text changes, over about 20 seconds. The insertion of PROCwimp_pause(0.1) slows down the action so that you can see it clearly.) Note that we have not changed NULL% during this process, nor used PROCuser_null.

[This !RunImage listing is not saved and can be discarded. When the tutorial is picked up again - in Section 2.27 - a fresh !MyApp will be started.]

There is another function that can offer further multi-tasking options; PROCwimp_pollidle. This works similarly to PROCwimp_poll but it repeatedly polls the Wimp at an interval decided by the programmer. For example, the call:

PROCwimp_pollidle(30,1)

causes PROCuser_null to be called once every 30 seconds.

In between this periodic action PROCwimp_pollidle will also react exactly like the normal PROCwimp_poll for other poll events e.g. mouse clicks etc. So it can be used very effectively for actions which need to be carried out with a regular periodicity whilst retaining the ability to intervene if necessary e.g a clock with a facility to change time, set alarm etc. It is usual to set NULL% to TRUE when using PROCwimp_pollidle so that PROCuser_null can be used for handling the regular task. (See !Clocker in the Examples folder for an example of using PROCwimp_pollidle.) Note that if the above listing had called PROCwimp_pollidle(30,0) then the periodicity would have been every 0.3 second, roughly. The second parameter determines whether the first parameter value is taken as ‘seconds’ or ‘centi-seconds’.

In addition, a further option is provided with PROCwimp_singlepollidle, which is the same as PROCwimp_singlepoll but polls the Wimp once after a user-specified delay.


For general multitasking guidance: use PROCwimp_poll or PROCwimp_pollidle to provide the main loop and then use PROCwimp_singlepoll and/or PROCwimp_singlepollidle within that. This also makes it easier to vary the ‘idle’ time, if required.

Be very wary of using any of the above calls within a file drag saving/loading routine.

(Note: if you have put a banner up and then used PROCwimp_pollidle with a time longer that the banner period, then the banner will stay up until the next PROCuser_null occurs.)







Top of page        Back to Contents        Previous        Next