Robert Kovacic asked an interesting question in the Dolphin newsgroup (comp.lang.smalltalk.dolphin) which touches on the different operation of the Dolphin 6 view composer in comparison to previous releases.
[text] entry fields have a different appearance within View Composer (they appear "indented") compared to when the view is run or when the view is displayed from the Test menu selection within View Composer (where they appear flat as normal for Windows XP). Why is this so?
I thought it would be worth writing something up on this to explain how it differs, and also why there are several cosmetic/rendering issues that you might encounter. Suffice it to say, they aren't our fault, as I will now endeavour to explain.
The Dolphin X6 view composer works in a different way than that of Dolphin 5 and earlier. In previous Dolphin releases the view composer hosted the windows under composition inside its "arena" as child windows, and it placed an transparent "shield" window over the top to intercept mouse events, etc, sent to these windows. This worked reasonably well in that what you saw was on the whole what you got (as opposed to the VC emulating the controls rather than using real ones, in which case what you see is rarely what you get), but it had two quite significant disadvantages:
-
Shell windows do not display their menu bar when hosted as a child of another window
-
The VC could not be attached to a live window in order to edit it.
In Dolphin X6 the view composer does not host the composed view as a child, but instead displays a rendering of the view which is itself off-screen (so you can't see it). This means that shell windows are proper top-level windows and display their menu bar. It also means that one could theoretically attach a view composer to a live window instance, and edit it. Now if you try to do this with the X6 view composer, it won't quite work as we had to cut that particular functionality from this release, but it is certainly something we hope to do in a later release. Why would we want to do that? Well because it fits in with the Smalltalk paradigm of editing the running program in an iterative process, doing some coding in the debugger, etc, until it looks and behaves as you want it. Rather than working on a static, unconnected, representation of the view as now, you could edit the view of a live MVP triad, and so eliminate the edit/run cycle.
So how do we manage to render the off-screen view into a bitmap that we can display on the view composer's design surface? Well thankfully Windows provides an API and supporting Windows messages to do this, namely PrintWindow() and WM_PRINT/WM_PRINTCLIENT. These are somewhat like the WM_PAINT message, but instead of painting to a screen device context, can paint onto some arbitrary DC such as a bitmap or printer DC.
Unfortunately having got quite a long way down the path of implementing the X6 view composer Andy discovered that the WM_PRINT implementations of many of the Windows controls are buggy, sometimes in very cosmetic ways, and other times there are more serious issues. Thankfully we managed to work around one of the most serious, which you can see by looking at the method CardContainer>>wmPrint:wParam:lParam, and consequently this wasn't a show stopper for X6.
The particular problem to which Robert refers is one such bug in Windows Edit control's implementation of the WM_PRINT message, i.e. that Edit controls don't WM_PRINT their themed representation, but the classic representation. Now you might think that a sensible implementation of WM_PRINT and WM_PAINT would be to use the same paint routine, and pass in either the screen DC from WM_PAINT, or the memory DC from WM_PRINT, but it seems that at least some of the controls are not implemented this way, so they do not actually paint correctly into off-screen DCs. Since it is cosmetic (and because we don't think they'll do anything about it) we haven't even reported this to Microsoft, but that would be the only route to getting a correct and lasting fix.