Firstly, I'd better explain for those newcomers what is actually meant by the WIMP and WIMP programming.
WIMP, in computer terminology, stands for Windows, Icons, Menus, Pointer (or pointing device). Some people refer to the M as standing for Mouse but this is technically incorrect because you don't specifically require a mouse to use a WIMP environment - although it certainly helps.
In RISC OS terms, a WIMP program is one that runs within the desktop environment - as opposed to taking over the whole machine and 'single tasking'. In order to achieve this, your program should follow certain recommended guidelines so that it doesn't hog the whole machine and render it unusable or slow it down too much.
Before you become too confused with terminology and technical 'jargon', I should perhaps explain a bit more about single and multi-tasking applications. Indeed, what is an application?
On RISC OS an application is a collection of files comprising a complete software package, such as OvationPro, NetSurf or Draw etc. There are certain conventions it's best to follow when creating an application and packaging all the files together and this will be explained as we progress through the course.
Previously, before people started WIMP programming, a program written in BASIC would generally take over the whole screen and anything else running on the computer would momentarily stop whilst your BASIC program ran. This is what's known as single-tasking. ie. Only a single task (or program) is running at a time. A multi-tasking application is one which runs in the background so that other applications can run at the same time. To do this, it needs to 'register' itself as a task running within the RISC OS desktop, often (but not always) putting an icon on the iconbar and waiting for the user to click on it.
One of the initial problems with teaching a computer programming language is that of determining the skillset, experience or existing knowledge base of any potential students. I'm aware that a lot of people would like to learn programming but don't know where to start. The aim of this course in WIMP programming is not to teach BBC BASIC from first principles, because that would detract from the WIMP specific aspects of programming. Therefore, I'm going to assume that anyone starting out on the path to WIMP programming already has a firm understanding and experience of programming in BBC BASIC. If you don't, I would recommend starting on a "Learning BBC BASIC" course first and then progressing to this one. Such a course is available online at http://www.vigay.com/academy/ - or maybe an idea for a future series of articles....
Programming for the WIMP, or desktop, requires a slightly different approach to coding, but once you grasp this, it's relatively easy and you can start to write your first WIMP application quite soon. The beauty of WIMP programming is that you can quickly develop further applications once you have an understanding of the concept and philosophy behind it all. I'm going describe a skeleton application which you can use as a starting point from which to develop your own applications.
As time progresses you will build up a library of handy routines, or procedures, so that you can immediately start a new application by repeating standard routines from a previous one. I will also share my own routines with you, to start you on your way. Mine are by no means the only way of doing things, but they are quite flexible and most of my own WIMP applications use them.
The main basis for WIMP coding is a loop which repeats until you quit the application. Within this loop your program detects various WIMP events that the computer automatically generates and notifies you of, such as a user clicking on something or a window opening or closing. Your program can then act upon these events by calling additional program routines.
Within this loop you perform what's known as polling the WIMP (see fig.1), which essentially means that you keep monitoring the system to see what events are occurring. Each time a new WIMP event happens, RISC OS will communicate back to your program via a wimp_poll response. If you keep monitoring the condition of this, you can simply call other routines depending upon what is going on within the computer.
To use an example, when the user clicks a mouse button the computer will generate an event saying 'mouse click'. Or, when a user drags a window across the screen another event will be generated. On a basic level, all your WIMP program has to do is sit waiting for these events, effectively doing nothing - until the system tells it an event has taken place - such as the user clicking on an icon or button which is owned by your program.
However, even in the simplest of WIMP programs you need to recognise and handle a minimum number of standard events, even if only to detect the user selecting 'Quit' from a menu. This is so that your program conforms with the rest of the RISC OS system. All well written applications need to have the facility to Quit the application and either open a window on the screen or place an icon on the iconbar (a program which does neither will be a bit pointless unless it's a utility specifically designed to monitor certain events "in the background" - more on this later!).
The best way of learning the concepts explained above is by way of a worked example. This is where you find that one tricky thing about WIMP programming is that you need a minimum number of 'standard' routines in order to write even a simple program which doesn't really do much. It's not so much tricky as rather daunting for the newcomer. However, don't let this put you off because once you get the hang of how things work, it gets easier as things slot into place.
For instance, even the shortest program needs to initialise itself, place an icon on the iconbar, implement a menu (from which we can Quit the application) and have Quit code - all in addition to the main polling loop described above. We may also want to open or close a window and do various other 'generic' tasks.
As our first example, we're going to write a small application which will place an icon on the iconbar and create a menu giving just two options; Info and Quit. Info will open a standard 'Info window' which provides information on our application, such as author, copyright and version details. Quit will quit the application.
As part of this initial exercise, I will introduce my standard wimp library which you can use as a basis for your own wimp applications.
A slight diversion - or how to organise your application
Before we start to write our first application, I should perhaps explain how RISC OS applications are organised. A WIMP application is different to a straight-forward BASIC program because there are various files required in order to make RISC OS see and understand it as a WIMP application. A good book to get hold of which explains the correct style in more detail is the Acorn Style Guide. Unfortunately this is out of print now, but you may be able to pick up a copy on eBay or second-hand from a RISC OS dealer.
Each application you write is comprised of a number of files. These are stored within the main directory of your application, which always starts with an exclamation mark (!), referred to in RISC OS circles as a pling character. Thus, our first application will be called !WimpDemo.
So, first we'll create a new directory called !WimpDemo. Because the ! signifies to RISC OS that it's an application it will be given an application sprite rather than the standard RISC OS directory one (fig.2).
The first thing you will notice is that the appearance is not the standard directory icon. This is because applications can have custom icons (which you're probably familiar with if you've used RISC OS applications before). We've got a generic one here because we've not actually designed a custom icon for our application yet. To do this, we create a 256 colour sprite using !Paint (built into RISC OS) which is 34 x 34 pixels in size (although technically we can create them any size, 34 x 34 is a standard convention for application icons).
The sprite name is always the same name as the application itself - in this case !wimpdemo (sprites are always lowercase). This sprite should be saved within the application (!WimpDemo) directory and given the filename !Sprites.
One thing to note is that we don't open application directories in the same way as normal directories, by double-clicking on them. This is because double-clicking on an application directory will actually try to RUN and load the application - which we haven't written yet. To open application directories we hold the SHIFT key down whilst double-clicking on them. If you do this with our new !WimpDemo application you will see an empty directory (fig.3) because that's all it is at this stage.
To give it a custom icon we'll quickly create a quick sprite to identify our application. Load !Paint and create a new sprite. Enter !wimpdemo as the name and ensure the size is set to 34 x 34 pixels. It should be created using 256 colours (mode 28). Initially you'll get a blank 34 x 34 icon (fig.4).
 Fig.3 - An empty application directory. |
Fig.4 - Creating a new icon for our demo application. |
As we don't want to get side-tracked too early in the development of our application, I'd recommend just creating a very simple sprite at this stage. You can always go back and improve it at a later stage. Save the file inside your application directory (fig 3) as !Sprites.
Just remember that the actual sprite name should be identical to your application name, and that the filename it's saved as should always be !Sprites.
!Boot and !Run files
We now need a couple of other standard files for our application; a !Boot file and a !Run file. A !Boot file is run as soon as we open the directory containing our application. This file is optional, but it's worth including a minimalist one, just for completeness. I generally have one consisting of a single line which ensures that our newly created sprite is used for the application icon.
Create a blank file in your text editor and enter the following lines;
| !Boot file for example application IconSprites <Obey$Dir>.!Sprites
Save the file as !Boot in your application directory (fig 6). Once you've saved it, you need to ensure that it's filetype is set to Obey which means the file will be executed line by line by RISC OS. If your text editor doesn't let you create obey files in the first place, you can change the filetype by using the standard filer menu and entering obey in the filer Set type option.
The last file we create before we start writing the main application is the !Run file. This is another obey file which is the one actually executed when we double-click (without holding SHIFT) on our application directory icon to load and run it. In fact, if you try double-clicking on your application directory now, you should get an error to the effect that the !Run file is not found - because we've not created it yet!
Now to create the !Run file:-
Copy the !Boot file, changing the name to !Run. Now hold SHIFT down and double-click on !Run. Holding SHIFT down will forcibly load a file into your text editor instead of trying to run the file or load it into another application. You can now edit the !Run file to contain the lines shown in fig.7
This file will need some further explanation so that you know what to do for future applications.
Firstly, any lines starting with a | (vertical bar) character (and coloured green in my text editor, !Zap) are comments. These are ignored by RISC OS when executing obey files, so you can add notes or additional explanations in your file. As shown on the third line of our !Run file (fig.7) they can be used simply for padding if you want the file to look a bit neater.
The second line in both files is an IconSprites command. This tells RISC OS to load our sprites into the system sprite pool (more on this later). The parameter after the command is the actual filename. What does <Obey$Dir> mean though? This is a very handy RISC OS short cut to the directory that the current 'obey' file is executing from, and this saves having to enter a fixed filepath for the location of our !Sprites file. This allows much more flexibility because our application wouldn't be very portable if you put the exact filepath, because as soon as you copied your application to another location or disc, it would complain with a 'file not found' error. When writing applications you should always ensure that any filename paths are relative which means that they're relative to the application and thus portable - not fixed to a particular disc and/or directory.
So, putting this altogether, what the line is doing is telling RISC OS to load our application sprites file, !Sprites, from the same directory our !Run (ie. obey filetype) file is residing in, into the system sprite pool. The system sprite pool is a central repository of sprites and icons that all applications running in the RISC OS desktop can use. I'll explain more about this later, when we come to write our applications. By including the same IconSprites line in both the !Run file and !Boot file it will ensure that RISC OS installs your new application sprite(s) irrespective of whether you just open the directory containing your application file (the purpose of the !Boot file) or if you actually double-click on the application to load it (the purpose of the !Run file).
The next important line, which should be included in all !Run files is the WimpSlot command. This has two parameters after it; a minimum amount of memory and a maximum amount of memory. These are signified by the parameters -min and -max, each followed by a value (in K bytes). The actual values used will vary depending upon the size of the application we're writing. For the time being, 64K will be more than ample. However, as you start writing longer applications you may find that you need to use bigger values. Although this will be explained in more detail later in the course, I'd recommend making both the -min and -max values the same at this point.
The value of the WimpSlot determines how much memory RISC OS will allocate to your application. If you give too small a value you may find your application will run out of memory and throw up an error message or 'crash'. Use too large a value and you may be wasting memory. Although modern machines have a fair bit of memory, the beauty of RISC OS is that applications are pretty small, so there's no point in claiming more memory than your application actually requires. To see how much memory various applications are using, click on the Task display icon (the far right icon on the iconbar). This will open the task window, displaying a list of all the tasks (applications) currently running on your machine. Next to each is a number and a corresponding green bar showing how much memory is being used by that application. This will give you a rough idea as to how much memory different applications require.
The next line Set wimpdemo$dir <Obey$Dir> sets a system environment variable - called wimpdemo$dir - and sets it to the pathname in <Obey$Dir>, which we've already established will be the filepath of the directory containing the obey script (ie. the !Run file). The reason we set this to our own variable (which is generally the name of the application followed by $dir) is so that this then becomes unique to our application - just in case another obey file is executed (for example, another application loading) and the original value becomes changed, perhaps pointing to someone else's application. From now on, we can reference the filepath of our application by referring to <wimpdemo$dir>
The next, and final Run <wimpdemo$dir>!RunImage %*0 line puts this newly created variable to use and tells the computer to actually load the main application file, called !RunImage - which we'll come onto next. By referring to it by our new system variable, we don't need to worry about any other applications changing the value of <Obey$Dir> and we'll always be able to make relational references to the file location of our directory without having to worry about absolute (ie. fixed) file names and paths changing if we decide to move our application somewhere else on our hard drive.
At present the meaning of the rather odd %*0 at the end of the line isn't really required, other than to include it for the time being. This affects how your application's !RunImage file can understand additional parameters sent to it - but this is beyond the scope of this introductory lesson, so just include it as it is for the time being. More will be explained in future lessons.
The !RunImage file - and back to programming...
We now come onto the !RunImage file. This is the most important file and will be the main application, which we're going to write in BBC BASIC. This file contains the actual program. It doesn't have to be called !RunImage but it's become rather a de-facto RISC OS convention - so unless you have good reason to change it, I'd leave it as !RunImage. If you do call your main application something other than !RunImage, then you should change the appropriate line in the !Run file which loads the application, created above.
To start writing your BASIC program you need a text editor capable of understanding BASIC keywords. These are actually 'tokenised' by the computer. You don't really need to understand the ins and outs of the BASIC interpreter other than the fact certain keywords are stored as a single 'token' rather than the actual letters PRINT (for example). This should be familiar to anyone already used to BBC BASIC and is explained in more depth in the introductory BBC BASIC Programming course explained earlier.
Both !Zap and StrongED are excellent for BASIC programming and what's more, they're both free!
Zap is available to download from http://zap.tartarus.org/
StrongED is available to download from http://www.stronged.iconbar.com/
As mentioned earlier, we're going to produce a very small application which puts an icon on the icon bar and has a menu with two options. This will be the most basic of WIMP applications but will demonstrate the minimum number of routines we require in order to register a WIMP task, poll the WIMP and act on a menu choice. The small framework about to be described will enable you to form the foundations of future applications and in lesson two we'll build upon it - and explain what some of the routines do.
One of the obstacles to WIMP programming, and something which can initially appear daunting to the newcomer is the fact you need to know and implement several things before you can even get anything working. Thus, I'm going to dive straight in and give you the initial WIMP application in it's entirety. I'll then go back and describe it's workings for you.
The program is thus, and, if you want you can download it from the RISC OS Now website, to save typing it in. I've highlighted the main procedure names in red, for illustrative purposes. You can download this sample application from here
10 : REM WIMP demo application
20 : REM (C) Paul Vigay
30 : REM You are free to use this as a starter template for your own WIMP applications
40 : REM
50 : ON ERROR PRINT REPORT$;" at line ";ERL:END
60 : version$="1.00 (20th Apr 2008)"
70 : DIM pb% 256:task%=&4B534154:path$="<wimpdemo$dir>."
80 : PROCmsgsetup:SYS "Wimp_Initialise",300,task%,"Wimp Demo",pb% TO ,task_handle%
90 : PROCinit
100 : ON ERROR PROCerror
110 : REPEAT
120 : SYS "Wimp_Poll",1,pb% TO reason%
130 : CASE reason% OF
140 : WHEN 6:PROCmouseclick
150 : WHEN 9:PROCmenu
160 : WHEN 17,18:PROCmessage
170 : ENDCASE
180 : UNTIL end%
190 : SYS "Wimp_CloseDown",task_handle%,task%
200 : END
210 :
220 : DEFPROCinit
230 : LOCAL N%,e$,a%
240 : N%=OPENIN(path$+"Resources.Templates"):templen%=EXT#N%*2:CLOSE#N%
250 : DIM mbuffer% 256
260 : DIM inv% 28,outv% 28
270 : DIM ws% templen% :REM workspace for icons in windows
280 : DIM wb% templen% :REM window block (multi-purpose)
290 : DIM mb% 1000,md% 1000
300 : nw%=2:DIM window%(nw%):REM number of windows to define
310 : end%=FALSE
320 : PROCloadsprites:PROCgetmodeinfo:PROCloadwindows:PROCmenucreate:iconbar%=FNiconbar
330 : ENDPROC
340 :
350 : DEFPROCmenu
360 : LOCAL menu%,b%,w%,i%
370 : menu%=menu1%
380 : SYS "Wimp_DecodeMenu",,menu%,pb%,mbuffer%:m$=$mbuffer%
390 : b%=pb%!8
400 : IF b% THEN
410 : CASE m$ OF
420 : WHEN "Quit":end%=TRUE
430 : ENDCASE
440 : ENDIF
450 : PROCmenucreate
460 : IF b% AND 1 THEN SYS "Wimp_CreateMenu",,menu%,pb%!0-88,560
470 : ENDPROC
480 :
490 : DEFPROCmouseclick
500 : LOCAL x%,y%,b%,w%,i%,N%,click4x%,click4y%,a$,p%
510 : x%=pb%!0:y%=pb%!4:b%=pb%!8:w%=pb%!12:i%=pb%!16
520 : lastwindow%=w%:lasticon%=i%
530 : CASE b% OF
540 : WHEN 1,4:CASE w% OF
550 : WHEN -2:PROCfront(window%(2))
560 : ENDCASE
570 : WHEN 2:CASE w% OF
580 : WHEN -2:SYS "Wimp_CreateMenu",,menu1%,x%-72,184
590 : OTHERWISE SYS "Wimp_CreateMenu",,menu1%,x%-72,y%+42
600 : ENDCASE
610 : ENDCASE
620 : ENDPROC
630 :
640 : DEFPROCmessage
650 : LOCAL N%,f$,f1$,d$,s$,s2$,t%,len%,e%
660 : CASE pb%!16 OF
670 : WHEN 0:end%=TRUE
680 : WHEN &400C1:PROCgetmodeinfo
690 : ENDCASE
700 : ENDPROC
710 :
720 : DEFPROCgetmodeinfo
730 : inv%!0=4:inv%!4=5:inv%!8=6:inv%!12=7:inv%!16=11:inv%!20=12:inv%!24=-1:SYS "OS_ReadVduVariables",inv%,outv%
740 : dx%=1<<(outv%!0):dy%=1<<(outv%!4):scrx%=(outv%!16+1)*dx%:scry%=(outv%!20+1)*dy%-2
750 : ENDPROC
760 :
770 : DEFPROCmsgsetup
780 : LOCAL N%,code%
790 : N%=0:RESTORE 820
800 : REPEAT:READ code%:pb%!N%=code%:N%+=4:UNTIL code%=0
810 : ENDPROC
820 : DATA 1,3,&502,&400C1
830 : DATA 0
840 :
850 : DEFPROCloadsprites
860 : LOCAL s%,x%,sa%
870 : s%=OPENIN(path$+"!Sprites"):x%=EXT#s%+16:CLOSE#s%:DIM sprites% x%
880 : sprites%!0=x%:sprites%!8=16
890 : SYS "OS_SpriteOp",&109,sprites%:SYS "OS_SpriteOp",&10A,sprites%,path$+"!Sprites"
900 : ENDPROC
910 :
920 : DEFFNiconbar
930 : LOCAL sp$,ih%
940 : pb%!0=-1:pb%!4=0:pb%!8=0:pb%!12=70:pb%!16=70:pb%!20=&3102:DIM spr% 12
950 : $spr%="!WimpDemo":pb%!24=spr%:pb%!28=sprites%:pb%!32=8:SYS "Wimp_CreateIcon",0,pb% TO ih%
960 : =ih%
970 :
980 : DEFPROCmenucreate
990 : LOCAL pass%,items%,nm%,f2%,f4%,f6%,f%,t$
1000 : menu1%=0
1010 : FOR pass%=0 TO 2 STEP 2
1020 : P%=mb%:indir%=md%
1030 : menu1%=P%
1040 : RESTORE 1260
1050 : [ OPT pass%
1060 : EQUS "Wimp Demo":EQUB 0:EQUW 0
1070 : EQUB 7:EQUB 2:EQUB 3:EQUB 0:EQUD 250:EQUD 44:EQUD 0
1080 : ]
1090 : FOR items%=1 TO 2
1100 : READ t$
1110 : f%=0:nm%=-1:f2%=0:f4%=indir%:f6%=LEN(t$):$f4%=t$:indir%=indir%+f6%+1
1120 : CASE t$ OF
1130 : WHEN "Info":nm%=window%(1)
1140 : WHEN "Quit":f%=&80
1150 : ENDCASE
1160 : [ OPT pass%
1170 : EQUD f%:equd nm%:equb 49:EQUB 1:EQUB f2%:EQUB 7:EQUD f4%:EQUD -1:EQUD f6%
1180 : ]
1190 : NEXT items%
1200 : IF P%-mb%>500 ERROR 1,"Menu data too long ("+STR$(P%-mb%)+") for mb% block"
1210 : IF indir%-md%>500 ERROR 1,"Menu data too long ("+STR$(indir%-md%)+") for md% block"
1220 : NEXT pass%
1230 : ENDPROC
1240 :
1250 : REM data for menu 1
1260 : DATA Info,Quit
1270 :
1280 : DEFPROCloadwindows
1290 : LOCAL W%,window$,N%
1300 : SYS "Wimp_OpenTemplate",,path$+"Resources.Templates":wm%=ws%+templen%
1310 : RESTORE 1420
1320 : FOR W%=1 TO nw%
1330 : READ window$:SYS "Wimp_LoadTemplate",,wb%,ws%,wm%,-1,window$,0 TO ,,ws%
1340 : CASE window$ OF
1350 : WHEN "info":$(wb%!(88+128+20))=version$
1360 : ENDCASE
1370 : SYS "Wimp_CreateWindow",,wb% TO window%(W%)
1380 : NEXT W%
1390 : SYS "Wimp_CloseTemplate"
1400 : ENDPROC
1410 : REM names of windows within template file
1420 : DATA info,main
1430 :
1440 : DEFPROCerror
1450 : LOCAL message$,action$,E%,err%,a%
1460 : ON ERROR OFF
1470 : message$=REPORT$:err%=ERR:action$=""
1480 : CASE err% OF
1490 : WHEN 1:action$="Click OK to continue":a%=1
1500 : WHEN 3:action$="":a%=1
1510 : OTHERWISE action$="Fatal internal error. Please click OK to continue or CANCEL to Quit.":a%=3
1520 : ENDCASE
1530 : message$=message$+" "+action$:VDU7
1540 : E%=FNerror(a%,err%,message$)
1550 : IF E%=2 OR end%=TRUE THEN SYS "Wimp_CloseDown",task_handle%,task%:END
1560 : ENDPROC
1570 :
1580 : DEFFNerror(E%,N%,M$)
1590 : SYS "Hourglass_Smash":SYS "Wimp_DragBox",,-1
1600 : !pb%=N%:$(pb%+4)=M$+CHR$(0):SYS "Wimp_ReportError",pb%,E%,"WIMP demo" TO ,E%
1610 : =E%
1620 :
1630 : DEFPROCgetw(handle%)
1640 : pb%!0=handle%:SYS "Wimp_GetWindowState",,pb%:vminx%=pb%!4:vminy%=pb%!8:vmaxx%=pb%!12:vmaxy%=pb%!16
1650 : scrollx%=pb%!20:scrolly%=pb%!24:bx%=vminx%-scrollx%:by%=vmaxy%-scrolly%:bhandle%=pb%!28:flags%=pb%!32
1660 : ENDPROC
1670 :
1680 : DEFPROCopen(handle%)
1690 : LOCAL scx%,scy%,x%,y%,x2%,y2%
1700 : IF handle%=-1 ENDPROC
1710 : pb%!0=handle%:SYS "Wimp_OpenWindow",,pb%
1720 : ENDPROC
1730 :
1740 : DEFPROCclose(handle%)
1750 : pb%!0=handle%:SYS "Wimp_CloseWindow",,pb%
1760 : ENDPROC
1770 :
1780 : DEFPROCfront(handle%)
1790 : LOCAL mx%,my%
1800 : SYS "OS_Mouse" TO mx%,my%:IF handle%<>-1 PROCgetw(handle%):pb%!28=-1
1810 : PROCopen(handle%)
1820 : ENDPROC
1830 :
Don't worry if you don't understand it all at the moment. Hopefully it will begin to make sense as we progress.
Also, like most things, there are often more than one way of achieving the same results, so my skeleton program here is by no means the only way you can write WIMP programs. Everyone will eventually have their own style and way of implementing the same general functions.
I'm not going to explain the detailed functions of each procedure in this lesson, but will refer back to them in future lessons. You'll also find that there are some rather major short-comings of the program as provided here. See if you can spot what they are (it probably won't take you long!). I will explain what they are - and how to rectify them, in part two.
All this short program does is to setup a WIMP task (visible from the Tasks display), place an icon on the iconbar and provide a minimalist menu and a single window - which opens when you click on the iconbar.
I've implemented the minimal number of things you need to include in order to run the program as a multi-tasking wimp application as well as giving the user a way of quitting the application - either from it's own menu or from the Tasks display.
The other procedures supplied are:-
PROCinit | Initialise arrays and define initial variables required by the program. |
PROCmenu | Decode what the user has selected when they select a menu option. |
PROCmouseclick | Interpret any buttons or icons the user clicks on. This will eventually become a major part of our application because clicking on things in windows is a major part of the RISC OS desktop. |
PROCmessage | Interpret and act upon WIMP messages. This is probably the most complex area to be covered, and will be discussed in more detail in a future lesson. |
PROCgetmodeinfo | Read system information about the current screen mode and resolution. |
PROCmsgsetup | Setup which WIMP messages our application will understand. Again, this is a complex area which will be discussed in a future lesson. |
PROCloadsprites | Load any sprites we require for our application (so far, only the iconbar one) |
FNiconbar | Create an icon on the iconbar. |
PROCmenucreate | Create any menus our application requires. There are probably 101 ways of achieving this effect, but the method described, although rather complex to initially understand, is one I've been using for some time and find it works reasonably well. |
PROCloadwindows | Load any windows the application requires. These are stored within a Templates file we created earlier. Again, we'll cover this in more detail as we progress. |
PROCerror | Handle any errors which may occur whilst our application is running. |
FNerror | Report an error message (used by PROCerror) |
PROCgetw | A generic routine to find out information about a specified window. |
PROCopen | A generic routine to open a specific window. |
PROCclose | A generic routine to close a specific window. |
PROCfront | A generic routine to open a specific window in front of any other windows. |
See if you can spot the two rather major things which don't work yet, and I'll tell you how to fix them in the next lesson - with the aid of just two additional lines of code. Thus you see how we need quite a lengthy portion of code in order to implement a simple WIMP application to start with. However, because we've now implemented around 90% of what we need to do - future additions and development will become progressively easier - so don't despair if it seems complex so far. It does get easier, and quicker, to add more functionality to our application.
|
Last edit: 11th Dec 2009 at 12:50pm |
|
Viewed 833 times since 2nd Jan 2006, | ||||||||||
| ||||||||||||||||||||||||
  |   |
|||||||||||||||||||||||
Email this page to a friend
Delicious
Digg
reddit
Facebook
StumbleUpon
