updating an icon label in DUIM 
Author Message
 updating an icon label in DUIM

How would you go about updating a <label> gadget in DUIM to display a
different icon.  It is initialized with one icon value in a frame
definition.  I would like to change it to another icon whenever a
request-to-send is asserted on a COM port.  I had code like this:

define method update-transmit-status( the-frame :: <xpress-232-frame>,
on-off :: <symbol> )
   if (on-off == #"on" )
       gadget-label-setter( $transmitting-icon, transmit-pane(the-frame)
);
   else
       gadget-label-setter( $not-transmitting-icon,
the-frame.transmit-pane );
   end if;
   update-gadget( transmit-pane( the-frame ) );
end method update-transmit-status;

However, it doesn't work.  I certainly can believe that since it appears
that the method for update-gadget on a <gadget> simply returns false.
If update-gadget isn't the way, what is?

Thanks for any help.

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Fri, 27 Dec 2002 03:00:00 GMT  
 updating an icon label in DUIM
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.



Fri, 27 Dec 2002 03:00:00 GMT  
 updating an icon label in DUIM

[...]

Quote:
>[...] 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.

 Linux is not known for having good threading support. And it seems that
Linux Torvald's beliefs in the rightness of the Linux process/thread design
is blocking efforts to change this. It would be interesting to
provide a similar comparison on other OSes.

 To be fair, it also seems that the comparison involved a user-level threading
package (continuations) vs. a kernel-level threading package. Those are different
beasts and the trade-offs are well documented in the CS literature. Was
the continuation package "fair" (guarantees that every thread will run eventually),
pre-emptive ? Could it take advantage of more than one processor ? How does it scale ?
These differences are easily overlooked when comparisons are not done with
high-end servers in mind. Testing on an OS supporting a M*N thread implementation
would also be interesting.

 I would however suggest that interoperating with pthread-based threading
libraries is a more reasonnable approach as soon as you want to mix Dylan with
any other language (which is likely to be "always" on OSes where libc
provides the only supported interface to the kernel).

Quote:
> 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.

 I like named parameters (used them in PL/SQL quite a bit), especially
for their code documentating values. However how do you propose to reconcile
them with the usage of higher-level programming (e.g.: apply()) ?

 Do you revert to argument order when no parameter name is given ? What
if only some of the names are given (not in order) plus some unnamed parameters ?
etc.

 define method foo (bar => bar-value :: <integer>, baz => baz-value :: <integer>);

 foo (baz => 1, 2);       == ?
 curry(foo, baz => 1) (2) == ?
 curry(foo, bar => 1) (2) == ?

Quote:
>  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.

 I am guessing here that it is not an error if you did not declare the
generic for foo(). IIRC, the generic defined by default will accept
any keyword parameter. There isn't much the compiler can do, maybe a
Dylan lint could provide a warning though.

 Interesting ideas, keep them coming !

 Regards - Eric

--



Sat, 28 Dec 2002 03:00:00 GMT  
 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 de{*filter*} 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.

Quote:

> 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.*-*-*.com/
> Before you buy.



Sun, 29 Dec 2002 03:00:00 GMT  
 updating an icon label in DUIM

Quote:


>[...]
>>[...] 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.

> Linux is not known for having good threading support. And it seems that
>Linux Torvald's beliefs in the rightness of the Linux process/thread design
>is blocking efforts to change this. It would be interesting to
>provide a similar comparison on other OSes.

> To be fair, it also seems that the comparison involved a user-level
threading
>package (continuations) vs. a kernel-level threading package. Those are
different
>beasts and the trade-offs are well documented in the CS literature. Was
>the continuation package "fair" (guarantees that every thread will run
eventually),
>pre-emptive ? Could it take advantage of more than one processor ? How does
it scale ?
>These differences are easily overlooked when comparisons are not done with
>high-end servers in mind. Testing on an OS supporting a M*N thread
implementation
>would also be interesting.

It was an explicit goal of Harlequin/Functional Dylan that Dylan
interoperate with native threads.  I did not initially think this was
a good idea, for exactly the reasons John Whittaker lists, but
I changed my tune in the face of the importance of interoperability
at the shared library level.


Sun, 29 Dec 2002 03:00:00 GMT  
 updating an icon label in DUIM


Quote:
> Well,  I don't think text was a problem for me.  It was icons.

I tested, and you're right:  Text labels are updated okay, but icons
labels are not.

If anyone else wants to play around with this, you can open the the
win32-duim-gui-test-suite project, and insert this line into the
frame-draw-icons method.

  frame.%label-pane.gadget-label := $paste-icon;

When you choose File->Draw Icons when the app is running, I would
expect that the wizard icon should be updated, but it doesn't get
updated.  Is this a bug?

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 29 Dec 2002 03:00:00 GMT  
 updating an icon label in DUIM
Try calling 'update-gadget' on the gadget and see what happens.
Quote:



>> Well,  I don't think text was a problem for me.  It was icons.

>I tested, and you're right:  Text labels are updated okay, but icons
>labels are not.

>If anyone else wants to play around with this, you can open the the
>win32-duim-gui-test-suite project, and insert this line into the
>frame-draw-icons method.

>  frame.%label-pane.gadget-label := $paste-icon;

>When you choose File->Draw Icons when the app is running, I would
>expect that the wizard icon should be updated, but it doesn't get
>updated.  Is this a bug?

>Sent via Deja.com http://www.deja.com/
>Before you buy.



Mon, 30 Dec 2002 03:00:00 GMT  
 updating an icon label in DUIM
I'd be suprised if that did it, update-gadget is used to force a
gadget to update itself because of data changes, not to cause
a redisplay. The most common example is to refresh a tree control
by recomputing all of its children functions.

So I think this must be a bug/oversight. I'll look into fixing it.

Andy

---
Andy Armstrong

On Wed, 12 Jul 2000 23:00:03  

Quote:

>Try calling 'update-gadget' on the gadget and see what happens.




>>> Well,  I don't think text was a problem for me.  It was icons.

>>I tested, and you're right:  Text labels are updated okay, but icons
>>labels are not.

>>If anyone else wants to play around with this, you can open the the
>>win32-duim-gui-test-suite project, and insert this line into the
>>frame-draw-icons method.

>>  frame.%label-pane.gadget-label := $paste-icon;

>>When you choose File->Draw Icons when the app is running, I would
>>expect that the wizard icon should be updated, but it doesn't get
>>updated.  Is this a bug?

>>Sent via Deja.com http://www.deja.com/
>>Before you buy.

Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


Mon, 30 Dec 2002 03:00:00 GMT  
 updating an icon label in DUIM


Quote:
> Try calling 'update-gadget' on the gadget and see what happens.

As John mentioned before, it has no effect.

Sent via Deja.com http://www.deja.com/
Before you buy.



Mon, 30 Dec 2002 03:00:00 GMT  
 updating an icon label in DUIM
Just to let everyone know, Andy Armstrong has kindly fixed the bug in
DUIM.  It did not make it into Service Pack 1 though.

To change an icon, you simply just need to call gadget-label, i.e.
  frame.icon.gadget-label := $new-icon

Sent via Deja.com http://www.deja.com/
Before you buy.



Tue, 07 Jan 2003 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. updating an icon label in DUIM

2. icon shows captions instead of labels

3. Trouble with menu entry with both icon and label (compound)

4. ICONS, ICONS, ICONS....

5. ICONS, ICONS, ICONS

6. Icons Icons Icons

7. Tkinter: some Labels not updating

8. HELP needed when updating label -textvariable

9. updating labels from entries?

10. Updating a label from C

11. Bug??? Label text immidiate update

12. Label or entry text not updated

 

 
Powered by phpBB® Forum Software