By the time you read this, there ought to be a new release of the Dr Wimp package - version 3.53. Please check my website to see. If you are wondering what happened to version 3.52, all is made clear in the documentation!
A user has suggested that the parameter be changed to allow finer control, by making it represent centiseconds instead of seconds - or, perhaps, by just making the parameter a real number. Thus, values of seconds such as 3.25, 0.5, 66.66 could then be used.
It would be a very easy change for me to make - but I am, for some reason, unable to decide whether the change would be regarded as an improvement or not by most users. Please let me know if you have a view on this.
Firstly, let me make it clear that there is a minor bug in Dr Wimp in this area - which will be corrected in the shortly-to-be-released new version. However, many of the oddities which can occur with sliders/bars are not due to bugs in Dr Wimp. Rather they are a result of several other factors which can sometimes come to the fore - and you can meet these in any application, not just those constructed with Dr Wimp.
For instance, if you use the mouse pointer to drag or click on a slider, the positional information returned by the mouse is very often fairly 'granular', e.g. you may not be able to move the pointer in steps of less than four OS units. This can mean, in turn, that the slider cannot pick out certain values precisely.
Another point is that PROCwimp_getsliderpcent and PROCwimp_putsliderpcent operate (as the names suggest) in percentages of the full slider value, so some rounding is inevitable and the actual size of the full length slider plays an important part. Similar practical issues can occur when using PROCwimp_bar.
None of these points is likely to be a nuisance if you use sliders merely as indications, and they can be overcome very easily with Dr Wimp if precise values need to be set. The common way of doing this reads the slider length/percentage into a writable icon and then uses a pair of nudgers/bump arrows to set this writable icon value more precisely - as is done in !Sliders, in fact.
It is important to realise what is actually happening here: the key value is the value in the writable box and not the actual value of the associated slider position. You may cause the box value to change by 1 unit by using the nudger, but it doesn't necessarily follow (assuming you have programmed the !RunImage to move the slider/bar correspondingly) that the slider/bar position will accurately move the right amount for 1 unit - or move at all, if your slider/bar maximum length is fairly short.
It is always safest to remember that the slider length/position and the writable box value are items arrived at by independent processes.
It is important that the height of each of these icons is no less than 44 OS units. Otherwise, even though it may look fine when the icon is first displayed, the text may be clipped at top or bottom after redraws, e.g. after a scroll or window resize.
This problem is easier to avoid if you design the icon in !TemplEd and use the 'Min size' option from the 'Edit icon' menus - after putting some default text in the icon.
It pays to do this even if you intend to create the icon using FNwimp_createicon rather than loading it from a template. After using !TemplEd, simply drag the template file into Dr Wimp's !CodeTemps utility to get the precise FNwimp_ createicon call needed to create the icon. Then copy it into your !RunImage at the right place. (You will probably need to alter the window handle.)
A foolproof way of ensuring this, whatever the length of the menu (and remembering that the menu length might be changed during development or even during program run) is to use:
CASE item% OF WHEN FNwimp_menusize(menu%) : PROCwimp_quit(0) etc. etc. ENDCASE
FNwimp_menusize returns the number of items in the menu - which will also equal the position of the 'Quit' item in the list if it is always the last one.
From my viewpoint, the more you get out of Dr Wimp the better and, when all is said and done, one of the best things about Dr Wimp is that it is not protected and you can learn a lot just by looking at the DrWimp library listing. However, if you are going to 'play' with the DrWimp library, please do it with your eyes open - and please offer your amendment to me afterwards for possible inclusion in the next upgrade. If it's useful to you, it is sure to be useful to someone else somewhere.
The most important point to note is that if you get your amended DrWimp library to work as you want it to in your pet application - let's call it !AppA - it does not necessarily mean that it will work in your other Dr Wimp applications - !AppB, !AppC, etc, or in other people's Dr Wimp applications. This is simply because each separate application generally calls its own unique selection of wimp-functions and calls them in different circumstances and combinations. My job is to try to ensure that the wimp-functions work in all cases.
To quote a real example, a user recently suggested a change in the sequence which goes on behind the scenes when you display a menu. In his application, he was displaying the menu by pressing the <menu> button - probably the commonest way - and his change addressed that method entirely satisfactorily. He offered it to me and I agreed that it was a good idea in principle, so I wanted to incorporate it in the next upgrade.
However, Dr Wimp allows you to display a menu in ways other than by pressing <menu> - none of which were employed in this user's application, so he hadn't needed to look at that. To incorporate the idea in the 'official' version, I needed to extend the suggested change to cover those other possible situations. It was no big deal, but it's a good example of why it is important to let me know.
| Source: | Archive 13.01 |
| Publication: | Archive Magazine |
| Contributor: | Ray Favre |