Fixed a number of long-standing but low priority bugs in the Wimp.
Detail: * Any top-bit-set sprite area pointer in a window definition was treated as a null pointer, and any top-bit-set program name pointer in Wimp_ReportError was similarly treated as a null pointer. * For 24-bit window colour builds, when the Wimp drew a title bar with the input focus, and there were sprite icons in the previously redrawn window, and the most recently plotted icon sprite was unpaletted and not selected or inverted, then the translation table for the icon sprite (in the RMA) would leak. I suppose that's what I get for re-using a bit of dead code without fully working out why it was bypassed in the first place... * The key handling code used to be over-eager to read bytes from the keyboard buffer: it would attempt to read up to 6 bytes ahead to ease the recognition of UTF-8 character sequences. This could cause problems, in particular if F12 was one of those 6 bytes, then any following bytes would be queued for use as Wimp keypresses, rather than being left in the keyboard buffer for use by ShellCLI. The Wimp now analyses the first byte read to make a sensible estimate of how many bytes it needs to read ahead. * Select-dragging (including Select-resizing) of windows with panes used to soak up all the processor time. This was because when the task received an Open_Window_Request, it would re-open the pane in front of the main window, but this would cause the Wimp to believe that it had to re-open the main window at the front of the stack again when Wimp_Poll was next called. The problem has been fixed so that the Wimp now examines all the windows in front of the drag window to see if they have the pane window flag bit set, and doesn't reshuffle the windows if they all do. (Actually, the test is performed such that foreground windows in front of the drag window are also ignored.) Admin: Tested on a desktop machine. Version 4.65. Tagged as 'Wimp-4_65'
Showing
Please register or sign in to comment