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

Re: updating an icon label in DUIM

Well,  I don't think text was a problem for me.  It was icons.  Here's how I
ended up
getting things to work:

define method update-transmit-status( the-frame :: <xpress-232-frame>,
on-off :: <symbol> )
   with-lock( screen-lock, timeout: 0.02)
      if (on-off == #"on" )
          gadget-label-setter( $transmitting-icon,
the-frame.transmit-pane );
          with-sheet-medium( medium = the-frame.transmit-pane )
             draw-image(medium, $transmitting-icon,   20, 2);
          end with-sheet-medium;
      else
          gadget-label-setter( $not-transmitting-icon,
ransmit-pane( the-frame ) );
          with-sheet-medium( medium = the-frame.transmit-pane )
             draw-image(medium, $not-transmitting-icon,   20, 2);
          end with-sheet-medium;
      end if;
   end with-lock;
end method update-transmit-status;

Does this seem like the "right" way?  The use of a <lock> seems to be
necessary because
the update-transmit-status is actually called from another thread.  So its
call looks something
like:

with-lock( screen-lock, timeout: 0.02 )
  call-in-frame( my-frame,  update-transmit-status, rts-state );
end with-lock;

Nominally, the rts-state (it stands for request to send.  yes I'm doing
millisecond level RS232 control from Dylan) changes from on to off after
only 0.001 seconds.

Showing an ON icon for only 1 msec isn't really enough time for the human
eye to detect well, so the extra slop in these calls to update the screen
isn't a problem--as long as I then recompute how much time I need to wait
before changing back from OFF to ON.  Before using the lock, my application
occasionally would lock up, and the debugger seemed to indicate to my
untrained Dylan eye that a number of screen update calls had quite literally
stacked up (on the call stack).  Although it may seem obvious in hindsight,
the screen update calls do not appear to be reentrant.  So far, using the
lock seems to have solved the crashes.


BTW,  since there's been a lot of nagg-ing about Dylan lately I'll add my
$0.02 about what might be nice to add to Dylan.   I know Dylan doesn't have
continuations and that they are a pain for compilers, but I saw a recent
post about timing of continuation based threads versus native OS threads in
comp.lang.scheme.  The continuation based threads just ran rings around most
native OS threads in terms of both speed and resource usage (as I recall),
with the absolute worst being native Linux threads.  Since a Linux Dylan is
something I'd love to see, and since I like using Dylan even for soft real
time type things, this Linux thread overhead scares me.

Another addition I would like to have: named parameters.  They're similar to
keyword parameters, but you can use them for any parameter.  Ada has alway
had them, and I think that's one of its simpler but nicer features.  It
makes code both easier to read and write.  The problem I've had with keyword
parameters is that it seems Dylan will accept ANY keyword in a call, even
ones the called function doesn't know about.  For example, I could call
oo( keyword-that-doesnt-even-exist: #f ) and foo would just ignore it.  I
would prefer for the compiler to catch that error.





<oodl@my-deja.com> wrote in message 8kda4l$5vt$1@nnrp1.deja.com">news:8kda4l$5vt$1@nnrp1.deja.com...
> Hi John,
>
> This works for me.   The "o" is changed to an "x" when I push the
> button.
>
> define frame <my-frame> (<simple-frame>)
>   pane led (frame)
>      make(<label>, label: "o");
>   pane
>     [LOTS OF STUFF OMITTED]
> end;
>
> define function run-button-callback (gadget :: <gadget>) => ()
>   let frame = sheet-frame(gadget);
>   frame.led.gadget-label := "x"; // or an instance of <image>
> end;
>
>
> Also, regarding your programming style, explicit use of "-setter"
> functions is not necesssary.  You can use := as I do with
> frame.led.gadget-label := "x"
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Follow-Ups: References: