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

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

Scott Ribe <sribe@miqs.com> writes:

> Worse than that, I can't even figure out how to usably subclass them!
> Subclassing <text-field> does not work, as it is not a subclass of
> <sheet> and does not have the needed behavior. 

To get the correct sheet behaviour, etc you can derive from
<win32-gadget-mixin>, along with <leaf-pane>. <win32-gadget-mixin> is
exported from win32-duim:win32-duim. So something like:

define class <my-text-field> (
  <win32-gadget-mixin>,
  <text-field>,
  <leaf-pane>)
end;

<leaf-pane> identifies the gadget as one that lives at the leaf of the
sheet tree - a gaget that obeys the layout protocols. It must be the
last class in the precedence list. <win32-gadget-mixin> gives all the
required win32 backend protocols.

>From there you can build up the functionality you want. It is not that
much code require to do the text-field stuff but it is a pain having
to duplicate it when the functionality already exists. It would be
nice to have access to <win32-text-gadget-mixin> but I don't think
that is exported either. All the methods on them are sealed so it
would do no good to derived from it anyway.

> This "works" in the sense that the GDI exists and I can calculate size
> and set the size of a widget successfully. But there are 2 problems.

do-compose-space and building your own classes would seem to be the
only way around this that I can think of. Someone more exprienced than
me at DUIM may be able to help.
> Another note, developers really need sources to ALL libraries for just
> these kinds of reasons. Dylan offers the ability to define libraries
> such that we should really not need source, but only in theory. 

I've found you can do a lot without source as long as the protocols
are open. Once they are sealed the only way of extending things is the
copy and paste method - which needs source.

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