[Prev][Next][Index][Thread]

Re: <text-field>, size, GDI context...

Scott Ribe <sribe@miqs.com> writes:

> Now, when to call this? Ideally, I would like to intervene in the
> pane creation after the GDI context is available and before sizing
> and layout are calculated.

I think you probably want to specialize do-compose-space for your
gadget. This is where your gadget returns information that defines how
much space it will take up. When this is called, the gadget has been
created (as far as I'm aware) and text-size, etc will be valid. 

Other possibilities could be calculating the information as soon as
the Win32 representation of your gadget is created, in
initialize-gadget-mirror (a generic function in win32-duim). 

I think do-gadget-size is probably what you want though. I wrote a
rich edit gadget using the Win32 rich edit control and this uses
do-compose-space for sizing. 

The bad news is that do-compose-space is sealed on the various
<text-editor> subclasses for the Win32 backend. But this is not a
problem if you are writing your own control, not based on those win32
classes.

Another option is to handle the <frame-mapped-event> for your
frame. From here your controls have been created and you can do
whatever you like. I use it for setting extended selection on
table controls for example:

define method handle-event( 
  frame :: <app-frame>, 
  event :: <frame-mapped-event> ) => ()
    let hwnd = frame.table-pane.window-handle;
    let LVS-EX-FULLROWSELECT = #x20;
    let LVM-FIRST = #x1000;
    let LVM-GETEXTENDEDLISTVIEWSTYLE = LVM-FIRST + #x37;
    let LVM-SETEXTENDEDLISTVIEWSTYLE = LVM-FIRST + #x36;
    let lstyle = SendMessage(hwnd, LVM-GETEXTENDEDLISTVIEWSTYLE, 0, 0);
    lstyle := %logior(lstyle, LVS-EX-FULLROWSELECT);
    SendMessage(hwnd, LVM-SETEXTENDEDLISTVIEWSTYLE, 0, lstyle);
end method handle-event;  

(window-handle is from win32-duim module in win32-duim library). This
has the disadvantage of being seperated from your control but it does
allow you to manipulate existing gadgets.

> I don't know for sure if this is possible in DUIM without modifying
> the existing classes or substantially replicating the logic.

I think it may be difficult to get the functionality you want by
subclassing existing DUIM classes - most of the generics that you
would want to override seem to be sealed. I'd love to be corrected on
this one.

Note to Functional Objects, is there any consideration to changing some
of these protocols for the win32-* classes to be open? Is there much
of a performance/size impact?

Chris.
-- 
http://www.double.co.nz/dylan
Follow-Ups: References: