Change in Behavior of Activate Command

[Jay Sage]

I have a batch file for resetting the position of various windows. With TCC17, the command "POS FOX" resets the position of my Firefox window and makes it active. With TCC19, the same command resets the position but does not make Firefox the active window.

I see that there is a note in the version-19 help about the Activate command running in a batch file, but I don't see how this can be a Windows issue when the same command in the same batch file behaves differently (though I'm sure that Rex will explain why this is happening).

I don't have any strong feeling about which behavior I prefer.

-- Jay

 

[vefatica]

What exactly is the command?

 

[rconn]

Not reproducible here. What is the exact syntax you're using?

There was a (Windows) bug in v17 x64 where it wouldn't always foreground the window when running TCC inside a TCMD tab window; v19 has a workaround for that.

ACTIVATE can be a little problematic with some apps, particularly those with multiple top-level windows (like FireFox), and some apps will not let themselves be resized and/or moved.

 

[Jay Sage]

I just modified the batch file to echo the command. When I run "position firefox", the following command is generated:

activate "*Mozilla Firefox" /pos=0,0,1115,985​

I have both TCC17 and TCC19 running in tabs in TCMD17. With TCC17, the Firefox window is not only repositioned but also brought to the foreground. With TCC19, it remains in the background (behind TCMD).

The difference in behavior is the same when other windows are activated using the batch file (e.g., my VEDIT text editor or Quicken) or when the "activate" command is entered directly at the command prompt (so it's not a batch-file issue).

Ah, but it appears to be a TCMD issue. When I detach the TCC19 session from TCMD (version 17), the designated task does come to the front. I had not yet tried running TCMD19 but did so just now. The problem does not occur with TCC19 in a TCMD19 tab. I guess I better make the full switch.

 

[rconn]

Ah, but it appears to be a TCMD issue. When I detach the TCC19 session from TCMD (version 17), the designated task does come to the front. I had not yet tried running TCMD19 but did so just now. The problem does not occur with TCC19 in a TCMD19 tab. I guess I better make the full switch.

The interprocess communication between TCC and TCMD is tied to the version. Running a mismatch is not recommended, and depending on the command, may not do anything at all.