|
From: Kevin W. <sw...@wo...> - 2004-09-18 03:50:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm having difficulty with the progress bar widget. I want to display the progress bar in a continuing loop to signify a process of indefinite length--the "barberpole" widget in Interface Builder serves this function, but since Tile doesn't have an equivalent version, looping the regular progress bar during the process (so that it repeats from 0-100 until the process terminates) is my workaround. The problem I'm having is that the only place I've seen the progress bar used is in the Tile demo, and the way it's presented there--as begin attached/driven by the "scale" widget--isn't how I want to do it. Here's the code in the tile demo: set s [tframe $l.scales] tscale $s.scale -orient horizontal -from 0 -to 100 -variable ::V(SCALE) tscale $s.vscale -orient vertical -from -25 -to 25 -variable ::V(VSCALE) tprogress $s.progress -orient horizontal -from 0 -to 100 tprogress $s.vprogress -orient vertical -from -25 -to 25 $s.scale configure -command [list $s.progress set] $s.vscale configure -command [list $s.vprogress set] Can anyone suggest a way to tweak this example so that the tprogress widget isn't driven by the tscale widget? [list $.progress set] Thanks, Kevin - -- Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw...@wo... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBS7BsF6m9qPmThLQRAgekAJ0TyEN5zDwi/OBHNH75uvBvW5/mcwCfQD1L cXrQiGlFTv81uOc51G9zRE0= =trV8 -----END PGP SIGNATURE----- |
|
From: Pat T. <pa...@zs...> - 2004-09-18 13:12:12
|
Kevin Walzer <sw...@wo...> writes:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I'm having difficulty with the progress bar widget. I want to display
>the progress bar in a continuing loop to signify a process of indefinite
>length--the "barberpole" widget in Interface Builder serves this
>function, but since Tile doesn't have an equivalent version, looping the
>regular progress bar during the process (so that it repeats from 0-100
>until the process terminates) is my workaround.
I have no idea what the barberpole widget looks like -- maybe it's
something that can be achieved by redefining the TProgress.bar element
using the pixmap/image engine though.
>
>The problem I'm having is that the only place I've seen the progress bar
>used is in the Tile demo, and the way it's presented there--as begin
>attached/driven by the "scale" widget--isn't how I want to do it. Here's
>the code in the tile demo:
The progress bar widget has a get and a set subcommand which take the
value to set the progress bar too. For instance, if we define the
range of the widget as 0 - 100, then a [$progressbar set 50] will
cause the bar to fill half the widget.
eg:
pack [tprogress .p -from 0 -to 100]
.p set 50
If you want to read the value, either [.p get] or [.p cget -value]
will do it.
So to cycle:
proc every {ms body} {after $ms [info level 0]; eval $body}
proc Update {w interval} {
set v [expr {[$w get] + $interval}]
if {$v > [$w cget -to]} {
set v [$w cget -from]
}
$w set $v
}
every 250 {Update .p 10}
--
Pat Thoyts
PGP Fingerprint: 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
|
|
From: Kevin W. <sw...@wo...> - 2004-10-25 00:20:48
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pat Thoyts wrote:
|
| The progress bar widget has a get and a set subcommand which take the
| value to set the progress bar too. For instance, if we define the
| range of the widget as 0 - 100, then a [$progressbar set 50] will
| cause the bar to fill half the widget.
| eg:
| pack [tprogress .p -from 0 -to 100]
| .p set 50
|
| If you want to read the value, either [.p get] or [.p cget -value]
| will do it.
| So to cycle:
| proc every {ms body} {after $ms [info level 0]; eval $body}
| proc Update {w interval} {
| set v [expr {[$w get] + $interval}]
| if {$v > [$w cget -to]} {
| set v [$w cget -from]
| }
| $w set $v
| }
| every 250 {Update .p 10}
|
Pat,
You were kind enough last month to provide the sample code above to help
me get started with the Tile progress bar widget. I've tweaked the code
for use in the application I'm working on and it works
beautifully...except that I don't know how to back out of the loop I've
set up. It cycles for an indefinite period of time (which is exactly
what I wanted it to do :-)). Destroying the window containing the
progress bar doesn't help because the every and update procedures are
still chugging in memory, and I get error messages that loop at the same
frequency of the code. And I've looked for a way to kill the procedure
itself, by using after cancel, but nothing seems to work. Can you give
me any direction in *closing* the loop? Thank you so much.
Regards,
Kevin
- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBfEbLJmdQs+6YVcoRAgEyAJ9CzyyK5rNcQn37HLrTJsqB1Y3XRwCfZOr+
0Vbupnk89bmiX9qEyEOZt7U=
=SdTK
-----END PGP SIGNATURE-----
|
|
From: Donal K. F. <don...@ma...> - 2004-10-25 08:13:58
|
Kevin Walzer wrote: > You were kind enough last month to provide the sample code above to help > me get started with the Tile progress bar widget. I've tweaked the code > for use in the application I'm working on and it works > beautifully...except that I don't know how to back out of the loop I've > set up. It cycles for an indefinite period of time (which is exactly > what I wanted it to do :-)). Destroying the window containing the > progress bar doesn't help because the every and update procedures are > still chugging in memory, and I get error messages that loop at the same > frequency of the code. And I've looked for a way to kill the procedure > itself, by using after cancel, but nothing seems to work. Can you give > me any direction in *closing* the loop? Thank you so much. OK, you need a cancel-able [every]. :^) Once you've got this though, it's easy to add a <Destroy> binding to clean things up. Here's some code (it's also on the wiki at http://wiki.tcl.tk/every of course.) proc every {ms body} { global everyId if {$ms eq "cancel"} { after cancel $everyId($body) unset everyId($body) } else { set everyId($body) [after $ms [info level 0]] uplevel #0 $body } } every 250 {Update .p 10} bind .p <Destroy> {every cancel {Update .p 10}} I'm sure this sort of thing could be improved upon fairly easily, but it should at least inspire... Donal. |
|
From: Brian G. <bgr...@mo...> - 2004-10-25 16:57:19
|
Donal K. Fellows wrote: > Kevin Walzer wrote: > >> You were kind enough last month to provide the sample code above to help >> me get started with the Tile progress bar widget. I've tweaked the code >> for use in the application I'm working on and it works >> beautifully...except that I don't know how to back out of the loop I've >> set up. It cycles for an indefinite period of time (which is exactly >> what I wanted it to do :-)). Destroying the window containing the >> progress bar doesn't help because the every and update procedures are >> still chugging in memory, and I get error messages that loop at the same >> frequency of the code. And I've looked for a way to kill the procedure >> itself, by using after cancel, but nothing seems to work. Can you give >> me any direction in *closing* the loop? Thank you so much. > > > OK, you need a cancel-able [every]. :^) Once you've got this though, > it's easy to add a <Destroy> binding to clean things up. Here's some > code (it's also on the wiki at http://wiki.tcl.tk/every of course.) > > proc every {ms body} { > global everyId > if {$ms eq "cancel"} { > after cancel $everyId($body) > unset everyId($body) > } else { > set everyId($body) [after $ms [info level 0]] > uplevel #0 $body > } > } > every 250 {Update .p 10} > bind .p <Destroy> {every cancel {Update .p 10}} > > I'm sure this sort of thing could be improved upon fairly easily, but it > should at least inspire... This is a particularly insidious area. It's possible to end up with rouge background task if you're not careful. I suggest adding a couple lines: proc every {ms body} { global everyId if {$ms eq "cancel"} { if {[info exists everyId($body)]} { after cancel $everyId($body) unset everyId($body) } } else { if {[info exists everyId($body)]} { # This makes sure there is only 1 every for this body after cancel $everyId($body) } set everyId($body) [after $ms [info level 0]] uplevel #0 $body } } Consider this testcase: every 250 {Update .p 10} every 250 {Update .p 10} -Brian "Once bitten, twice shy" -- ------------------------------------------------------------- -- Model Technology Inc. -- -- 8005 SW Boeckman Road 503.685.7000 tel -- -- Wilsonville, OR 97070 USA 503.685.0921 fax -- ------------------------------------------------------------- -- Technical support ............ mailto:su...@mo... -- -- Sales and marketing info ....... mailto:sa...@mo... -- -- Licensing .................... mailto:li...@mo... -- -- Home Page ........................ http://www.model.com -- -- AIM ........................................ bgriffin42 -- ------------------------------------------------------------- |
|
From: Donal K. F. <don...@ma...> - 2004-10-26 07:57:45
|
Brian Griffin wrote:
> Consider this testcase:
> every 250 {Update .p 10}
> every 250 {Update .p 10}
FWIW, I considered that test case and decided against doing anything
about it. It has the hallmark of code that is actually fairly unlikely
to occur in practice except in situations that are already a bug
irrespective of the effects of this code. Running the identical script
twice is going to lead to unexpected behaviour anyway.
You can of course go for a full solution that implements ids a bit like
[after] does (which allows for a fully controllable behaviour), but the
code to do this is rather much longer than I felt like writing and is
probably overkill too. :^D (It might be a candidate for adding to the
Wiki or tcllib if it isn't already there.)
Donal.
|
|
From: Kevin W. <sw...@wo...> - 2004-10-26 16:36:11
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to everyone for their help with my questions about the progress bar. I've synthesized everything and am adopting it for the application I'm developing (based almost entirely on Tile!). I've documented what I'm doing, plus added some nice eye candy, at the wiki: http://wiki.tcl.tk/12786 Additions, comments welcome there. Thanks! Kevin - -- Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw...@wo... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBfnzwJmdQs+6YVcoRArd1AJwK9pse8yACCvK5fKT10/zH5Dv/XgCePMvC dPjz5eYoha08T1Rs9FyOzZA= =5CCy -----END PGP SIGNATURE----- |