Refresh on "update" under WinXP 
Author Message
 Refresh on "update" under WinXP

Does this sound familiar to anyone.

I am porting a large Tcl-Tk app from Linux to WInXP.
After making a call like the one below,  my main Application Window
won't refresh until I grab it with the mouse and move it a pixel or more.
    On Linux, calling "update"  always takes care of this ,
doesn't seem to do the trick in WinXP.
How should I force the App window ( some might call it the Wish Window)
to refresh.

And secondly, how can I call the below pogram without displaying a
Dos-window while it executes ?

I seem to having trouble making a straight exec call to the perl script
or to the Perl Interpreter using the $this_prog as the parameter.

...M'

----------- snip ------------

    ( progam being "Exec-ed is a Perl script )

set this_prog  "$install_dir/handpicks/correct-data.pl
--nchannels=$nchannels  --correctionprefix=handpic_correction-a.
--correctionsuffix=.txt \
    --dataprefix=$fpref   --datasuffix=$fext --outprefix=$outfilepref
--outsuffix=$outfileext"
    exec $::env(COMSPEC) /c [file nativename $this_prog]



Tue, 28 Feb 2006 21:31:51 GMT  
 Refresh on "update" under WinXP

Quote:

> I am porting a large Tcl-Tk app from Linux to WInXP.
> After making a call like the one below,  my main Application Window
> won't refresh until I grab it with the mouse and move it a pixel or more.

Don't call exec directly, use "open |..." and create a fileevent
to read the data - then you never tie up the application 100% with
the call to perl.

Quote:
> And secondly, how can I call the below pogram without displaying a
> Dos-window while it executes ?

> I seem to having trouble making a straight exec call to the perl script
> or to the Perl Interpreter using the $this_prog as the parameter.

You should be getting the perl interp (use auto_execok) to open| or
exec, not relying on COMSPEC to start it for you.

--
     Jeff Hobbs                     The Tcl Guy
     Senior Developer               http://www.ActiveState.com/
         Tcl Support and Productivity Solutions



Tue, 28 Feb 2006 22:26:44 GMT  
 Refresh on "update" under WinXP
OK , I am not quite getting it.

how would I run this instance, in a pipe, all parms are on the comm line.
( assume myprog.exe is not in the system path )

c:/subdir/my_bin_prog.exe  --parm1=$val1  --parm2=$val2 --parm3=$val3

???

Quote:


>> I am porting a large Tcl-Tk app from Linux to WInXP.
>> After making a call like the one below,  my main Application Window
>> won't refresh until I grab it with the mouse and move it a pixel or more.

> Don't call exec directly, use "open |..." and create a fileevent
> to read the data - then you never tie up the application 100% with
> the call to perl.

>> And secondly, how can I call the below pogram without displaying a
>> Dos-window while it executes ?

>> I seem to having trouble making a straight exec call to the perl
>> script or to the Perl Interpreter using the $this_prog as the parameter.

> You should be getting the perl interp (use auto_execok) to open| or
> exec, not relying on COMSPEC to start it for you.



Wed, 01 Mar 2006 03:01:34 GMT  
 Refresh on "update" under WinXP
Hi Mitch,

Does the following do what you want?

set pipe [open "|c:/subdir/my_bin_prog.exe\
    --parm1=$val1  --parm2=$val2 --parm3=$val3" r+]

(the backslash and line break can be removed)

Pipes via open are documented in the open man page:
http://www.tcl.tk/man/tcl8.4/TclCmd/open.htm#M20
and discussed on the Tcler's wiki:
http://mini.net/tcl/2196

Regards,
Aric



Wed, 01 Mar 2006 05:00:35 GMT  
 Refresh on "update" under WinXP
Thanks,
    yes that works.  But I don't fully understand what I am doing.
Do I need to close that pipe ? if so when?
Can I read from it to see if errors were sent to stdout ?

Thanks very much, (friday pm you know, its pretty quite in here),
...M'

Quote:

> Hi Mitch,

> Does the following do what you want?

> set pipe [open "|c:/subdir/my_bin_prog.exe\
>     --parm1=$val1  --parm2=$val2 --parm3=$val3" r+]

> (the backslash and line break can be removed)

> Pipes via open are documented in the open man page:
> http://www.tcl.tk/man/tcl8.4/TclCmd/open.htm#M20
> and discussed on the Tcler's wiki:
> http://mini.net/tcl/2196

> Regards,
> Aric



Wed, 01 Mar 2006 06:37:57 GMT  
 Refresh on "update" under WinXP
More specifically, how do I tell when my program in the pipe is done ?
Can  you point me to a  "dummies guide to running programs in a pipe "?

    Anyway , you  already got me a little further down the road .. thanks !
...M'

Quote:

> Hi Mitch,

> Does the following do what you want?

> set pipe [open "|c:/subdir/my_bin_prog.exe\
>     --parm1=$val1  --parm2=$val2 --parm3=$val3" r+]

> (the backslash and line break can be removed)

> Pipes via open are documented in the open man page:
> http://www.tcl.tk/man/tcl8.4/TclCmd/open.htm#M20
> and discussed on the Tcler's wiki:
> http://mini.net/tcl/2196

> Regards,
> Aric



Wed, 01 Mar 2006 06:59:04 GMT  
 Refresh on "update" under WinXP
I'm probably not the best person to be answering questions about command
pipelines, but...

Practical Programming in Tcl and Tk by Brent Welch et. al provides some
coverage of pipes.  I'm not aware of an online pipe tutorial.  Most of what
I know about pipes I learned through trial and error (and then promptly
forgot).

If you open your pipe to be readable*, you can read anything the pipe
outputs to stdout (using [gets $pipe line] or [set line [read $pipe]]).  If
you make your pipe writeable*, you can write to the process' stdin through
the pipe (using puts $pipe $line).  When the process you're running is done,
and when you've read everything from the pipe, [eof $pipe] will return 1.
That's how you know it's done, and at that point you do want to close the
pipe.

Two potentially pertinent commands that you might want to read up on are
[fconfigure] and [fileevent].  You might use fconfigure to change the
buffering and blocking of your pipe, and you might use fileevent to automate
reading and writing on the pipe when it is readable and writable.  If you
use fileevent, be sure to change your fileevent to {} as soon as you hit eof
on your pipe.

Here's a small example of a fileevent, which would go in your code right
after you open the pipe:

fileevent $pipe readable [list read_pipe $pipe]

proc read_pipe {pipe} {
    if {[eof $pipe]} {
        fileevent $pipe readable {}
        close $pipe
        puts "Closed pipe"
    } else {
        if {[string trim [gets $pipe line]] != ""} {
            puts "Pipe says: $line"
        }
    }

Quote:
}

If you're going to interact with the process on the other end of the pipe,
you need to make sure that both ends of the pipe cooperate with each other;
especially, you need to make sure that both ends flush output at the
appropriate times and that they use stdin and stdout to read and write.  If
you don't need to interact with the process but are just running it and
catching the result once it's all over, these are probably not issues.

I hope that helps a little.  Sorry to not be more helpful!  Hopefully this
gives you enough new info to try some different things and come back with
any more questions that arise.

Good luck,
Aric

* in case it wasn't obvious what I was talking about: the second argument to
the open command tells it what access to give you to the pipe.  r, r+, and
w+ will all give you readable access, and w, w+, and r+ will all give you
writable access.  Since I usually read and write to the pipes I open, I
usually use [open $pipe r+].



Wed, 01 Mar 2006 08:08:29 GMT  
 Refresh on "update" under WinXP

Quote:

>proc read_pipe {pipe} {
>    if {[eof $pipe]} {
>        fileevent $pipe readable {}
>        close $pipe
>        puts "Closed pipe"
>    } else {
>        if {[string trim [gets $pipe line]] != ""} {
>            puts "Pipe says: $line"
>        }
>    }
>}

eof check should be after the [gets] or [read] call.

proc read_pipe {pipe} {
    set got [gets $pipe line]
    if {$got > -1} {
        puts "Pipe says: $line"
    }
    if {[eof $pipe]} {
        set status [catch {close $pipe} result]
        if {$status == 0} {

            # The command succeeded, and wrote nothing to stderr.

        } elseif {[string equal $::errorCode NONE]} {

            # The command exited with a normal status, but wrote something
            # to stderr, which is included in $result.
            puts "stderr was: $result"

        } else {

            switch -exact -- [lindex $::errorCode 0] {

                CHILDKILLED {

                    foreach { - pid sigName msg } $::errorCode break
                        # A child process, whose process ID was $pid,
                        # died on a signal named $sigName.  A human-
                        # readable message appears in $msg.
                        puts "stderr: $pid died on $sigName: $msg"

                }

                CHILDSTATUS {

                    foreach { - pid code } $::errorCode break

                        # A child process, whose process ID was $pid,
                        # exited with a non-zero exit status, $code.
                        puts "pid $pid exited with code: $code"
                        puts "stderr: $result"

                }

                CHILDSUSP {

                    foreach { - pid sigName msg } $::errorCode break
                        # A child process, whose process ID was $pid,
                        # has been suspended because of a signal named
                        # $sigName.  A human-readable description of the
                        # signal appears in $msg

                }

                POSIX {

                    foreach { - errName msg } $::errorCode break
                        # One of the kernel calls to launch the command
                        # failed.  The error code is in $errName, and a
                        # human-readable message is in $msg.
                        puts "stderr: $errName: $msg"

                }
            }
        }
    }

Quote:
}

--

$ make war
make: *** No rule to make target `war'.  Stop.  Try `love' instead.



Wed, 01 Mar 2006 08:23:00 GMT  
 Refresh on "update" under WinXP
Thats what I needed,  !!
     I have my old Linux apps behaving beautifully , now runing in a pipe.
(which is a potpourri of C, Pascal, Perl , Santa-Ria incantations .. and
so on....)

Thanks so much for the 2 minute lesson!
I am pipe-ing quite happily !!!!

   (Man I love the internet)
...M'

Quote:

> I'm probably not the best person to be answering questions about command
> pipelines, but...

> Practical Programming in Tcl and Tk by Brent Welch et. al provides some
> coverage of pipes.  I'm not aware of an online pipe tutorial.  Most of what
> I know about pipes I learned through trial and error (and then promptly
> forgot).

> If you open your pipe to be readable*, you can read anything the pipe
> outputs to stdout (using [gets $pipe line] or [set line [read $pipe]]).  If
> you make your pipe writeable*, you can write to the process' stdin through
> the pipe (using puts $pipe $line).  When the process you're running is done,
> and when you've read everything from the pipe, [eof $pipe] will return 1.
> That's how you know it's done, and at that point you do want to close the
> pipe.

> Two potentially pertinent commands that you might want to read up on are
> [fconfigure] and [fileevent].  You might use fconfigure to change the
> buffering and blocking of your pipe, and you might use fileevent to automate
> reading and writing on the pipe when it is readable and writable.  If you
> use fileevent, be sure to change your fileevent to {} as soon as you hit eof
> on your pipe.

> Here's a small example of a fileevent, which would go in your code right
> after you open the pipe:

> fileevent $pipe readable [list read_pipe $pipe]

> proc read_pipe {pipe} {
>     if {[eof $pipe]} {
>         fileevent $pipe readable {}
>         close $pipe
>         puts "Closed pipe"
>     } else {
>         if {[string trim [gets $pipe line]] != ""} {
>             puts "Pipe says: $line"
>         }
>     }
> }

> If you're going to interact with the process on the other end of the pipe,
> you need to make sure that both ends of the pipe cooperate with each other;
> especially, you need to make sure that both ends flush output at the
> appropriate times and that they use stdin and stdout to read and write.  If
> you don't need to interact with the process but are just running it and
> catching the result once it's all over, these are probably not issues.

> I hope that helps a little.  Sorry to not be more helpful!  Hopefully this
> gives you enough new info to try some different things and come back with
> any more questions that arise.

> Good luck,
> Aric

> * in case it wasn't obvious what I was talking about: the second argument to
> the open command tells it what access to give you to the pipe.  r, r+, and
> w+ will all give you readable access, and w, w+, and r+ will all give you
> writable access.  Since I usually read and write to the pipes I open, I
> usually use [open $pipe r+].



Wed, 01 Mar 2006 20:43:27 GMT  
 Refresh on "update" under WinXP

|
| > I am porting a large Tcl-Tk app from Linux to WInXP.  After making
| > a call like the one below, my main Application Window won't
| > refresh until I grab it with the mouse and move it a pixel or
| > more.
|
| Don't call exec directly, use "open |..." and create a fileevent
| to read the data - then you never tie up the application 100% with
| the call to perl.

I've seen this no-update-until-user-interaction on XP also _after_
exec finished and with system calls which take some time.  The screen
is not refreshed until some user interaction with the window occurs,
which is quite messy, since usually the user waits for the program
indicating the end of some operation.  This is very XP-specific, and
does not happen on W2K or Unix/IRIX/HP.

Note that I'm not talking about the no-refresh _during_ exec or some
time-consuming system call (which is obvious), but _after_ the exec
finished and the window thus should be `responsive' again, but does
not update until some user interaction happens.

Any insight here (apart from `use threads')?
R'



Fri, 03 Mar 2006 17:01:47 GMT  
 Refresh on "update" under WinXP

Quote:



> |
> | > I am porting a large Tcl-Tk app from Linux to WInXP.  After making
> | > a call like the one below, my main Application Window won't
> | > refresh until I grab it with the mouse and move it a pixel or
> | > more.
> |
> | Don't call exec directly, use "open |..." and create a fileevent
> | to read the data - then you never tie up the application 100% with
> | the call to perl.

> I've seen this no-update-until-user-interaction on XP also _after_
> exec finished and with system calls which take some time.  The screen
> is not refreshed until some user interaction with the window occurs,
> which is quite messy, since usually the user waits for the program
> indicating the end of some operation.  This is very XP-specific, and
> does not happen on W2K or Unix/IRIX/HP.

> Note that I'm not talking about the no-refresh _during_ exec or some
> time-consuming system call (which is obvious), but _after_ the exec
> finished and the window thus should be `responsive' again, but does
> not update until some user interaction happens.

> Any insight here (apart from `use threads')?

I don't see what using threads will do to solve that.  In any case,
I'd like to see a repeatable instance of that, since I am writing on
XP right now and have never seen that problem.

--
     Jeff Hobbs                     The Tcl Guy
     Senior Developer               http://www.ActiveState.com/
         Tcl Support and Productivity Solutions



Fri, 03 Mar 2006 22:28:52 GMT  
 Refresh on "update" under WinXP

| [screen update problem on XP]
| I don't see what using threads will do to solve that.

The application in question is dealing with SCSI-tapes which sometimes
require some time to finish a SCSI/ASPI command.  I thought that if
we'd use a display-thread and a separate SCSI-worker-thread, the
problem would go away, since the display-thread no longer gets blocked
by the SCSI-call.  But maybe I'm wrong...

| In any case, I'd like to see a repeatable instance of that, since I
| am writing on XP right now and have never seen that problem.

Unfortunately I can't provide a simple TCL-only test case using only
`exec'.  Short of sending you the application plus the required
hardware (20+kg :-), I'm afraid we have to live with that for now
until there is more time for detailed research.

R'



Sat, 04 Mar 2006 00:43:27 GMT  
 Refresh on "update" under WinXP

Quote:

> | [screen update problem on XP]
> | I don't see what using threads will do to solve that.

> The application in question is dealing with SCSI-tapes which sometimes
> require some time to finish a SCSI/ASPI command.  I thought that if
> we'd use a display-thread and a separate SCSI-worker-thread, the
> problem would go away, since the display-thread no longer gets blocked
> by the SCSI-call.  But maybe I'm wrong...

You are right, this is probably the issue.  You can also use a
slave process that you talk to over a pipe.

--
     Jeff Hobbs                     The Tcl Guy
     Senior Developer               http://www.ActiveState.com/
         Tcl Support and Productivity Solutions



Sat, 04 Mar 2006 11:02:50 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. "Too many open files" ith WinXP

2. Slow "recording" on winXP Command

3. Refresh Browse "in place"

4. tcl http with HTTP-EQUIV="Refresh"

5. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

6. "update" vs. "update idletasks"

7. "update" vs. "update idletasks"

8. "update" and "update idletasks" and Solaris 2.5.1

9. BEGIN{want[]={"s1o", "s2o", "s2q", "s3q"}

10. Parsing ""D""?

11. "Smalltalk Overview"update

12. "Cascade on Update" clarification

 

 
Powered by phpBB® Forum Software