Prev: disabling/ignoring ctrl+c
Next: passing variable as default value to procedure parameter
From: Alexandre Ferrieux on 3 Sep 2009 13:41
On Sep 3, 7:03 pm, APN <palm...(a)yahoo.com> wrote:
> Cameron, you are exactly right as to my intent. Currently, I look to
> see whether Tk is loaded to distinguish, but the correct thing seemed
> to be not to check for Tk but for the event loop since that is what is
> important.

Do you want to detect whether an event loop is _already_ running, ie
you are being called from within an event callback, or whether an
event loop is _about_ to be launched, which is technically what
happens when falling back at the end of a wish script, or in an
explicit vwait at the end of an event-driven, pure tclsh script ?

As you might guess, short of a time machine, finding out what the
future has in store is tricky.

Again, you might be more specific as to the nature of that code, the
app domain, etc. The intent is still unclear.

-Alex
From: tom.rmadilo on 3 Sep 2009 14:52
On Sep 3, 10:03 am, APN <palm...(a)yahoo.com> wrote:
> Cameron, you are exactly right as to my intent. Currently, I look to
> see whether Tk is loaded to distinguish, but the correct thing seemed
> to be not to check for Tk but for the event loop since that is what is
> important.

If I were reading this and knew nothing of Tcl, I would conclude that
Tcl/Tk sucks badly. Your code has to change based upon an unrelated
extension (Tk)? Problem is I know next to nothing about Tk and only a
little bit more about the event loop.

Anyway, the only facts are that your application works fine without
Tk, but must be aware of operating in a Tk environment. My guess is
that if you do [vwait forever] there is no possibility for Tk to get
loaded, but who knows. What happens if Tk loads after your [vwait
forever]?
From: Uwe Klein on 3 Sep 2009 15:39
APN wrote:
> Cameron, you are exactly right as to my intent. Currently, I look to
> see whether Tk is loaded to distinguish, but the correct thing seemed
> to be not to check for Tk but for the event loop since that is what is
> important.

you can call vwait in all cases.
just do it with a [catch].


little testscript:

#!/usr/bin/tclsh


# if no eventloop is running this will error out
catch {vwait forever} cerr
# with: "can't wait for variable "forever": would wait forever"
puts cerr1:$cerr

package require Tk

button .b -command {set forever happy} -text weiter
pack .b



catch {vwait forever} cerr
puts cerr2:$cerr:$forever

exit


uwe
From: Don Porter on 3 Sep 2009 17:25
Uwe Klein wrote:
> APN wrote:
>> Cameron, you are exactly right as to my intent. Currently, I look to
>> see whether Tk is loaded to distinguish, but the correct thing seemed
>> to be not to check for Tk but for the event loop since that is what is
>> important.
>
> you can call vwait in all cases.

So long as you accept the risk of Tk's problems with that.
See Feature Request 456548.

> just do it with a [catch].

Um, why? What error are you expecting that a [catch] would
be the right remedy.

--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter(a)nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
From: tom.rmadilo on 3 Sep 2009 18:41
On Sep 3, 2:25 pm, Don Porter <d...(a)nist.gov> wrote:
> Uwe Klein wrote:
> > APN wrote:
> >> Cameron, you are exactly right as to my intent. Currently, I look to
> >> see whether Tk is loaded to distinguish, but the correct thing seemed
> >> to be not to check for Tk but for the event loop since that is what is
> >> important.
>
> > you can call  vwait in all cases.
>
> So long as you accept the risk of Tk's problems with that.
> See Feature Request 456548.
>
> > just do it with a [catch].
>
> Um, why?  What error are you expecting that a [catch] would
> be the right remedy.


After reading about vwait: apparently it nests: [vwait x] ... [vwait
y] waits for y then x.

This is no different than any other code. [for ....] [for ...]
requires the second 'for' to finish before the first can finish. Maybe
the real problem is using a dummy variable like "forever" which never
gets set in a reusable code fragment/library...that is [vwait forever]
is not reusable. This interpretation seems reasonable and is free of
bugs.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: disabling/ignoring ctrl+c
Next: passing variable as default value to procedure parameter