======
      :
      wm attributes . -alpha 0.4; update idletasks
msgBox "debug-1"
      set code [catch {$cmdint eval $m($m(current),$curItm,code)} rc]      
msgBox "debug-2"
      wm attributes . -alpha 1.0; update idletasks
      :
======
I see the following behaviour which I don't understand at all. Above, there's a fragment of code of one of my GUI-programs (tclkit 8.4.19, Windows XP). In the 2nd line, some code gets evaluated by a slave interpreter ($cmdint). Within these code, something gets [exec]uted without a trailing '''&''', thus the program blocks, as expected; "debug-2" does not appear.
'''But after a few seconds or so, the main window . of my program goes into -alpha 1.0 mode.'''
After ending the [exec]uted process, "debug-2" appears, and the main window of my prog is in -alpha 0.4-mode again.

So, after all, who switches my program to - alpha 1.0 in between? Very mysterious...

[AMG]: I have your answer!  When a program is unresponsive to window system events for more than five seconds, MS-Windows marks it as "Not Responding".  Look in the Task Manager to see this.  When the user clicks on a window for a Not Responding program, MS-Windows puts a "fake" window frame on it.  Possibly other events can summon the "fake" window frame.  This "fake" window frame looks like a normal window frame, unless you have a funky shaped window, and it allows minimizing, closing, resizing, and moving.  Clicking the close button will bring up a confirmation dialog.  A side effect of drawing this "fake" window frame is setting 100% opacity.

[MHo]: Thanks. I guessed that has to be something from the outside. But (nothing unusual on windows...) some times it happens, sometimes not, sometimes after this delay, sometimes after that delay...

[AMG]: You need to keep your GUI responsive.  See "[Keep a GUI alive during a long calculation]" for some ideas.  Instead of [exec]'ing a program in the foreground, try running it in the background using [[[open] |]].

<<categories>> GUI