WHICHWIN (sysutils plugin)

[Steve Fabian]

Vince:
Trying to kill an overlong response using ctrl-C results in a lot more scrolling, followed by the death of the stand-alone TCC instance (but before all display would have been generated).
--
Steve

 

[vefatica]

On Wed, 26 Oct 2011 11:58:12 -0400, Steve Fabian <> wrote:

|Vince:
|Trying to kill an overlong response using ctrl-C results in a lot more scrolling, followed by the death of the stand-alone TCC instance (but before all display would have been generated).

It works fine here, though I must be really fast to Ctrl-C before it's done. How
are you generating an "overlong response"?

 

[Steve Fabian]

From: vefatica
| It works fine here, though I must be really fast to Ctrl-C before
| it's done. How are you generating an "overlong response"?

Failing to limit number of windows reported by proper filtering.
--
Steve

 

[vefatica]

On Wed, 26 Oct 2011 17:06:27 -0400, Steve Fabian <> wrote:

|From: vefatica
|| It works fine here, though I must be really fast to Ctrl-C before
|| it's done. How are you generating an "overlong response"?
|
|Failing to limit number of windows reported by proper filtering.

Huh? Example, please. If I don't limit at all and let it do child windows
(/R), the whole it takes a split second to do 451 windows.

 

[Steve Fabian]

From: vefatica
| Huh? Example, please. If I don't limit at all and let it do child windows
| (/R), the whole it takes a split second to do 451 windows.

It's not the execution time of the command that's at issue. It's the time it takes to display the 10 lines for each of those 451 windows. It seems to be uninterruptible without killing TCC. I run WinXP home SP3 on this machine.
--
Steve

 

[vefatica]

On Wed, 26 Oct 2011 17:49:43 -0400, Steve Fabian <> wrote:

|From: vefatica
|| Huh? Example, please. If I don't limit at all and let it do child windows
|| (/R), the whole it takes a split second to do 451 windows.
|
|It's not the execution time of the command that's at issue. It's the time it takes to display the 10 lines for each of those 451 windows. It seems to be uninterruptible without killing TCC. I run WinXP home SP3 on this machine.

I see those 4510 (or so) lines in under a second. If the crash occurs after
WHICHWIN has returned and before console output has finished, there's nothing I
can do about it. And if I can't reproduce it there may be little I can do
(sound familiar?). I'll look at the code and try to guess what might be
happening.

 

[vefatica]

I did reproduce it (on XP, couldn't on Win7) and I think I have fixed it (at least for WHICHWIN). Steve, please get/try a new one (at ftp://lucky.syr.edu/4plugins).

Maybe Rex will comment here.

When a plugin function needs to (and will) clean up when aborted, I have (for a long time) used this console control handler:

BOOL WINAPI CtrlHandler(DWORD dwSignal)
{
    if ( dwSignal == CTRL_BREAK_EVENT || dwSignal == CTRL_C_EVENT )
    {
        Qprintf(STD_ERR, L"%s", dwSignal == CTRL_BREAK_EVENT ? L"^BREAK" : L"^C");
        return bInterrupt = TRUE;
    }
    return FALSE;
}

The Qprintf() instruction was causing the crash. It was no doubt being executed while a ProcessWindow() function (called by either EnumWindows() or EnumChildWindows()) was using Printf(). I would expect oddly-placed (unsynchronized) output (and have seen it) but not a crash (in XP but not Win7). Rex ... any thoughts?

 

[Steve Fabian]

From: vefatica
| I see those 4510 (or so) lines in under a second. If the crash occurs after
| WHICHWIN has returned and before console output has finished, there's nothing I
| can do about it. And if I can't reproduce it there may be little I can do
| (sound familiar?). I'll look at the code and try to guess what might be
| happening.

I think somewhere my console has been set to smooth scrolling (I'd like to kill that!), as a result of which it takes forever for all those lines to be displayed. That's why I tried to interrupt it. The crash was consistent.

I just checked, and the GPF below was created:

TCC 13.00.27
Module=F:\JPSOFT\IZ\TakeCmd.dll
Address=100C3F47
Exception=C00000FD
EAX=01E02000 EBX=00000000 ECX=01DFFEC8 EDX=7C8856A0
ESI=00000000 EDI=00000002 EBP=01E3FF10 ESP=01E3FF08
CS=0000001B DS=00000023 ES=00000023 SS=00000023
Flags=00010206

Stack:
1 : TakeCmd.dll 00000001:000c2f47
2 : sysutils.dll 00000001:00003ae6
3 : kernel32.dll 00000001:0000a729
--
Steve

 

[rconn]

> Rex ... any thoughts?

Qprintf & Printf (which calls Qprintf) are not reentrant, and can certainly
crash if you use them that way.

 

[vefatica]

On Wed, 26 Oct 2011 22:07:04 -0400, rconn <> wrote:

|---Quote---
|> Rex ... any thoughts?
|---End Quote---
|Qprintf & Printf (which calls Qprintf) are not reentrant, and can certainly
|crash if you use them that way.

Thanks!

 

[Steve Fabian]

From: vefatica
| it (at least for WHICHWIN). Steve, please get/try a new one (at
| ftp://lucky.syr.edu/4plugins).

Thanks, no more crash with the version below:
2011-10-26 20:20:47 107,008 A93946F2 sysutils.dll

However, the smooth scrolling still takes its toll - the ctrl-C stops generating data to be displayed, but it still takes a long time before the command prompt appears.

Any suggestion how to turn off smooth scrolling?
--
Steve

 

[Charles Dye]

Any suggestion how to turn off smooth scrolling?

It's on the Tabs page of the "Configure Take Command" dialog.

 

[Steve Fabian]

From: Charles Dye
| Originally Posted by Steve Fabian
|| Any suggestion how to turn off smooth scrolling?
|
| It's on the Tabs page of the "Configure Take Command" dialog.

That's not for stand-alone TCC...
--
Steve

 

[Charles Dye]

From: Charles Dye
| Originally Posted by Steve Fabian
|| Any suggestion how to turn off smooth scrolling?
|
| It's on the Tabs page of the "Configure Take Command" dialog.

That's not for stand-alone TCC...

As far as I know, there is no such option for TCC, or for standalone console apps in general.