Firstly, I'd like to make a plea to readers for feedback. Indeed comments are welcome not just on this series of articles but on the content of RISC OS Now in general. Only by receiving plenty of feedback and comments from the readers can I decide what direction the series will take, or whether I'm confusing people or boring them with stuff they already know. Anyone is welcome to email me directly (nospam@vigay.com) either to offer suggestions or constructive criticism as well as request help on their own WIMP programming projects.
One of the hardest parts of designing a new RISC OS application is that of making it easy to use and not too confusing for any potential users. It's no good having a super-whizzo new application if no one knows how to use it, or it's too confusing. Therefore it's worth spending a bit of time and thought on how the finished product will not only look but also function. How big should the windows be? What should they look like? What functionality should you include in each window? Should you combine things into a single window, or split different functions into different windows. Is an option better selected from a menu or by clicking on an on/off button in a window. Can you use it straight away, or do you need to sit down and ready a lengthy manual first?
Before you start coding, I would recommend that you sit down and carefully plan out your proposed application or utility? I tend to do this in my head, but some people prefer to physically draw out what it should look like on a piece of paper. Do whatever feels comfortable for you. There's no particular right or wrong way for designing applications. Gone are the days when developers meticulously plotted their projects out with the aid of flow diagrams and masses of pseudo code - a kind of cross between English and computer code, whereby you draft out the basic functioning of your program.
I find it handy to make a list of bullet points of features you want to include in your program. Don't be too ambitious though. Some projects start off with grand ideas, only to get put on a back burner because you feel overwhelmed at what to do next. I'm guilty of this because I have a vision of the finished application in my mind and often feel exasperated at the beginning of a new project - simply because there seems to be a vast chasm between the skeleton WIMP application I gave in article one and how I imagine I want the final application to look like. However, once you've got the core WIMP application working, you can then start adding your own functionality to your project and you can rapidly start to see the project take shape. This is when programming can become very satisfying and even addictive.
An essential utility for building new applications is a "Window template editor". There are several such applications freely available to download from the internet, and you should find one before you get too advanced in actual coding. The purpose of a template editor is to create the various windows that you want to use in your application. When you become more advanced you can actually write the code to automatically generate the windows as and when they're required, but for most applications, you can simply use a template editor to create the windows you require, dragging and dropping icons as required. My favourite template editor, and one I thoroughly recommend, is !WinEd. This was originally written by Tony Houghton and now maintained by Adam Richardson. You can download it from http://www.riscos.info/index.php?title=WinEd
It comes with comprehensive documentation so I won't spend time describing how to use it here, but once you get the grasp of it, it's dead easy to use and you'll soon be feeling confident enough to design more complex windows and design layouts. I used it for designing the window you saw in the demo application described in the first two articles.
Using a window editor you can quickly produce some blank windows (as per the one in my example application). However, it's also easy to create some icons and start to design some functionality to your window. This is what we'll do next in our example.
Load a window editor and, initially, you can load my example template which comprises two windows; the main window (currently blank) and an info window. The templates file has it's own filetype, unsurprisingly called "Template" (type &FEC) and if your window template editor has been 'seen' by the RISC OS filer, then simply double-clicking on a template file will load the template editor along with your window definitions (see screenshot). The list of windows is shown as a series of small window icons in a small template filer window. This has a small toolbar along the top of it, from which you can click on common functions, in order to save your file or create a new window etc. In my example, you should see two; 'info' and 'main'. Double-click on 'main' which will open the window, as it will appear in your application. The main difference is that whilst you're editing it, there's a small tool panel attached to the top left hand side. More on this later.
A couple of other 'control' windows will also open, such as a 'monitor' window which simply indicates to you the details of the window and/or icon underneath the mouse pointer and an 'Icon picker' window, from where you can choose various icons in order to position in your blank window. You can drag the window around the screen and indeed, wherever the window is when you save the templates file, that's where the window will appear when you open the window in your WIMP application.
You can adjust the overall size of the window by clicking on the 
icon on the little window toolbar. This will open the 'work area adjustment window' (fig.2) allowing you to define the overall size of the complete window. The 'work area' is the total size of the window.
Thus, if the work area is bigger than the 'visible area', you'll automatically get scroll bars appearing (unless you disable scroll bars - click on the 
icon). Alternatively you can use the resize icon on the window itself, to set the size you require, then click on 'Minimise' in the work area adjustment window. This button will automatically adjust the work area to be exactly the same size as the visible area - so that you don't require scroll bars in order to view bits that are out of view. Experiment with all the controls in order to familiarise yourself with all the options, as you'll be using the window editor a lot whilst writing new applications.
We're now going to create some icons for our new application. At this point, the application could be building into anything. It's just a 'blank' WIMP demo of the way RISC OS controls everything and we've not really done anything specific to a particular function or end result. Indeed, all of the things you've learnt so far are valid for ALL new applications. You'll always build upon the same skeleton WIMP application in order to start writing a new application. It's only when we start designing the actual windows and writing feature specific routines in our BASIC program that the application will start to take a turn towards the actual end result required.
I thought we could make our example WIMP demo into a unit conversion utility. This is one of the simplest applications to write, yet illustrates virtually all the WIMP facilities and bits of code that we need for even huge applications such as desktop publishers and spreadsheets etc. Therefore, at this point, we need to sit down and visualise what our finished utility will look like. How big will the window be, and how many things do we need to include. You may want to sketch a brief drawing on a piece of paper, or you could just start straight away by dragging icons into your main window. This is my preferred way, as I can then move them around and resize them to suite my vision for the final project. The window editor utility acts almost like Lego in that you can create, edit or delete icons to your hearts content, then just save the finished windows as a single template file which in turn can be loaded by your BASIC program.
The most important thing to consider when you're designing your window templates is the size of each icon. I don't mean the physical size of the icon on the screen, which can be pretty much any size you require - but the size of the icon in terms of the memory block it requires - if you remember the points I made about buffer sizes in part two. After a bit of thought, I came up with the design in figure 3, which is loosely based upon the Apple Mac OS X unit conversion widget (Apple's fancy name for desktop utility!)
As you can see from the screenshot, I've been fiddling with a number of the other features offered by WinEd, such as turning off the scroll bars, making the window smaller and giving it a suitable title. The availability of scroll bars and other 'standard' window icons are all controlled by 'Edit window', which you can find by clicking on the icon mentioned above.
Anything to do with the actual title and title bar of the window is edited by clicking on the 
WinEd button, which in turn opens the 'Edit title' window. Again, all these controls are explained more fully in the WinEd manual.
The actual icons within the 'work area' (I'm continuing to use some of the 'buzz words', or techno jargon in order to help familiarise the use of such terms so that future usage of them will become second nature) of the window are created simply by dragging the relevant icons we require, out of the 'Icon picker' window and into our main window. Just drop them where you require them, and you can fine position them, either by re-dragging them around the window or by pressing CTRL-D when the relevant icon is highlighted. This opens a small window allowing you to specify the exact coordinates and size of the icon so that you can achieve fine control over the finished look. If you double-click on any of the icons in your window (such as 'Length' in the screenshot above), you'll get what is possibly the most frequently used control window opening - the 'Edit icon' window, fig.4.
This window allows you to set all the attributes of each individual icon, and is arguably the most important window to get the hang of, not least because one of the settings in here can cause the most common form of errors and crashing when your program is running. This is the 'Max text length' value, which we'll come onto in a minute. In the meantime, you should familiarise yourself with all the other options. This is where you can enter the text that goes inside your icon, determine which type of click (if any) the icon will respond to (ie. return a WIMP reason code 6 when you click on it) or the colours (to see the colours, you'll need to scroll down the 'Edit icon' window a bit).
At this point there are two important aspects I need to point out. Firstly, in the example I give above, you'll see that I've turned on (ticked) the 'Indirected' option at the top, and entered some odd looking text in the 'Validation' box. I recommend setting any icons that you may want to edit or alter from within your code (we'll get onto this in the next article) to be 'Indirected'. This means that the data in the icon, which in this example is the word "Length" is indirected, meaning that a pointer is given to where it's stored. I mentioned the confusing area of pointers in the last article, but we're now about to see a real-life example of how it all works. The validation characters are some additional parameters that we can use to further customise our icon, and there are quite a few you can use (see PRM volume 3, page 102). Each validation option is separated by a semi-colon (;) so you can see that my example uses two options. The R2 sets the border style (note that we've got the 'Border' flag turned on lower down in the settings) to a 3D inset style. The Pptr_menu part sets the Pointer to use the RISC OS pointer shape called "ptr_menu". What this means in English is that whenever the mouse pointer moves over that particular icon, it will automatically change to a little menu pointer shape, signifying that the user can click on the icon in order to open a MENU. I've done the same for the 'Mile' and 'Kilometer' icons in the example).
Of course, the fact that I've put the words "Length", "Mile" and "Kilometer" into some of the icons is entirely my choice. These will be the 'default' options when our new application loads. However, the aim is to make each of these icons be able to change when the user clicks on them to select a MENU of available options. We could just have easily used "Mass", "Grams" and "Ounces" if we'd wanted to. At this stage, we're more interested in just designing the template to suit our application. Changing the various text within the icons will come later when we get back to coding.
Now, onto the most important value. The 'Max text length'. This value determines how much space is reserved for your icon. Thus, if you're going to allow someone to type into the icon, it will determine the maximum number of characters (minus one because we require an 'end of icon' termination character) they can type. Furthermore though, even if you don't allow the user to type into the icon (by setting the button type to 'None' or one of the click options), it determines how long the text can be that's stored in this icon. As you'll find out when we get back to the programming, the text inside these icons can be changed (which is why it doesn't matter too much what words we used above) by our program code. However, if we decide to change the word "Length" for "Temperature" in our program, but we've only given a 'Max text length' of 8 characters (for example), then as soon as we change the word to "Temperature", our program will start overwriting part of the next icon, because the word "Temperature" requires a minimum icon size of 12 characters. This is why, if you're unsure how long to make each icon, allow a few extra characters. If you know that the conversion unit is never likely to exceed 49 characters, then make the 'Max text length' 50.
For writable icons, unless I only want the user to enter a small number or something, I make them 256 characters. This will allow them to contain a string of 255 characters - which is the maximum BASIC will allow anyway (if we exceed this we'll get another kind of error, which I'll explain in a future article).
At this point, you should see how powerful something like WinEd is. Quite a lot of WIMP applications can be controlled automatically by RISC OS itself, so we've added quite a bit of functionality to our utility without doing a single word of actual programming. Things like changing the mouse pointer when you move over icons, positioning the caret when you click in an icon and highlighting an icon when you click on it, are all handled automatically by RISC OS, so you can see why it pays to spend a little time and effort to design your windows well. This will save programming effort later.
Next time we'll go back to coding again, and you can see how our newly created icons can be controlled by our application....
|
Last edit: 11th Dec 2009 at 12:50pm |
|
Viewed 547 times since 17th May 2008, | ||||||||||
| ||||||||||||||||||||||||
  |   |
|||||||||||||||||||||||
Email this page to a friend
Delicious
Digg
reddit
Facebook
StumbleUpon
