Whilst running through the gui tests for DUIM I was puzzled by the behaviour of dialog boxes. As far as I could tell, most of them should have been running modally, but they were all running modelessly (well, all apart from the "standard dialogs" which use a completely different create/map/event loop process to everything else).
What to do, apart from to examine the code?
It turns out that the <dialog-frame> classes (which inherit from <basic-frame>) all contain Dylan "keyword" slots. I had assumed (even after reading the relevant sections of the DRM) that this was a straightforward shorthand for specifying a slot with a keyword initarg, but after looking in detail at the frame creation code on <basic-frame> and re-reading the DRM it becomes apparent that these are not slots at all, but rather Dylan's way of specifying CL's :default-initargs class option.
After changing these "slots" to be :default-initargs, things run much better (i.e. more like I expected them to run). The initialize-instance method on <basic-frame> is now passed the initargs it needs to construct frames properly (barring further errors on my part). This also resolves a couple of the issues with scrolling that I've been having.
Unfortunately the DEFINE-DYLAN-CLASS macro I wrote (and that is still used by other macros, such as DEFINE-FRAME) doesn't deal with "keyword" slots properly. I spent some time a while ago making most classes just use DEFCLASS instead of my Dylan "compatability" macro -- it would seem the time has come to port the remaining uses over to DEFCLASS and to rewrite some of those macros. At least I know what I'll be doing this evening given the opportunity.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment