You rarely have a problem with getting it onto the screen in the first place, but there are often cries for help about a corrupted display when the window is subsequently moved/covered/scrolled etc, i.e. when the window has to be 'redrawn'. Typically, part of the graphic/text then goes missing!
The answer to all such problems (whether you are using Dr Wimp or not) lies with your coding of the work/screen coordinate conversions.
Admittedly, it can take a bit of concentration, but the basics are very simple and Dr Wimp does all the hard work for you (if you let it!).
The first thing to remember is that the computer actually plots things onto the real screen (i.e. it uses 'screen coordinates'), and if you want a graphic to keep its relative place in a window, the screen coordinates of the graphic are going to need to change as the window moves.
The Wimp will take care of your window frame (and icons) automatically, but you need to keep telling the Wimp where to put your graphics and in Dr Wimp you do this within PROCuser_redraw.
The key to success is to do all your thinking in 'window/work area' coordinates, not forgetting that work coordinates are referenced to the top left corner of the window, so all visible items will need negative y-values. Then use, wherever possible, those plotting wimp-functions with 'window' in their name, e.g. PROCwimp_renderwindow for plotting a drawfile. If you can do this, Dr Wimp will do everything else for you.
Where this is not possible, e.g. when using Basic PLOT statements, then again do your positional thinking in work coordinates but then simply substitute the FNwimp_worktoscreen calls for your actual values. For example, to plot a filled square of 50 OS units sides with its bottom left corner at 100,-200 (OS units) in a window you would think in these terms:
RECTANGLE FILL 100,-200,50
but, in PROCuser_redraw, actually use:
x% = FNwimp_worktoscreen(window%,100,0) y% = FNwimp_worktoscreen(window%,-200,1) RECTANGLE FILL x%,y%,50
You are then home and dry!
The main change concerns the two wimp-functions which allow you to create your windows and icons from within the !RunImage coding, should you so wish - rather than by the usual way of using a window template. Because of the somewhat unusual nature of these two wimp-functions (in the Dr Wimp context anyway) it is likely that this main change in v.3.57 will, in fact, not affect many users.
The two wimp-functions are FNwimp_createwindow and FNwimp_createicon, and since their first appearance, many releases ago, they have suffered two shortcomings - one major and one minor - both of which have now been eliminated.
The major shortcoming was that there was previously a restriction on the type of window that could be created. With v.3.57, you can now create any window allowed by the Wimp.
The minor shortcoming was that the flags and button types used in FNwimp_createicon were not exactly the same as those used by the Wimp - although all options were available. Again, v.3.57 has corrected this.
The price of these changes is that the old flags and button type values, used as parameters in the wimp-functions, would need to be changed (and a new parameter added) if you wanted to upgrade a previously constructed application (not an essential step - it's up to you). If you do want to upgrade an old application, a new utility called !FlgConv does the hard work for you and gives you the new values to achieve the same functionality as the old values.
A necessary corollary to this change has been a corresponding upgrade in !CodeTemps, the utility that automatically provides the exact calls to FNwimp_createwindow and FNwimp_ createicon simply by dragging your window template file.
Other changes in the new release are minor and are detailed in Dr Wimp's Upgrading file.
The bug only occurred if you created a menu in one particular way and then later attempted to re-create it.
| Source: | Archive 14.03 |
| Publication: | Archive Magazine |
| Contributor: | Ray Favre |