TCMD tabs and input focus

[vefatica]

If I start TCMD normally (default TCC12 in one tab), then Tabs\Run and enter "d:\tc12\tcc.exe" (start a new tab) ... OK, a new tab opens, it appears active, it's actual tab is in front (with the "X"), but there's no blinking cursor. If I type, I see nothing, and what I type (likewise any output if I type a command + [Enter]) actually goes to the other tab (the one TCMD started with).

A click anywhere on the new tab gets things working right.

 

[rconn]

If I start TCMD normally (default TCC12 in one tab), then Tabs\Run and enter "d:\tc12\tcc.exe" (start a new tab) ... OK, a new tab opens, it appears active, it's actual tab is in front (with the "X"), but there's no blinking cursor. If I type, I see nothing, and what I type (likewise any output if I type a command + [Enter]) actually goes to the other tab (the one TCMD started with).

A click anywhere on the new tab gets things working right.

Not reproducible here.

 

[Charles Dye]

Not reproducible here.

I can reproduce it. Windows XP SP3, 32-bit.

 

[rconn]

I can reproduce it. Windows XP SP3, 32-bit.

Tried it on four machines (including one XP) and can't reproduce it anywhere.

What happens if you double-click on an empty part of the tabbed windows bar?

 

[Charles Dye]

What happens if you double-click on an empty part of the tabbed windows bar?

In my case, keyboard input still goes to the previous (hidden) tab.

 

[vefatica]

On Mon, 16 May 2011 14:27:43 -0400, Charles Dye <> wrote:

|---Quote (Originally by rconn)---
|What happens if you double-click on an empty part of the tabbed windows bar?
|---End Quote---
|In my case, keyboard input still goes to the previous (hidden) tab.

Do you mean open a new tab by 2-clicking on the bar? ... in my case, that works
as desired, with with the command line cursor visible in, and kb input going to,
the new tab.

The problem I reported deals only with Tabs\Run, and though I didn't try it
yesterday, it happens regardless of what's started in the new tab (tried CMD and
PowerShell as well as TCC).

 

[Charles Dye]

On Mon, 16 May 2011 14:27:43 -0400, Charles Dye <> wrote:

|---Quote (Originally by rconn)---
|What happens if you double-click on an empty part of the tabbed windows bar?
|---End Quote---
|In my case, keyboard input still goes to the previous (hidden) tab.

Do you mean open a new tab by 2-clicking on the bar? ... in my case, that works as desired, with with the command line cursor visible in, and kb input going to, the new tab.

Ah. I misunderstood the question. I'm seeing the same as Vincent.

 

[rconn]

Do you mean open a new tab by 2-clicking on the bar? ... in my case, that works as desired, with with the command line cursor visible in, and kb input going to, the new tab.

How about if you click on "Tabs / New Tab"?

 

[vefatica]

On Mon, 16 May 2011 16:00:10 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|Do you mean open a new tab by 2-clicking on the bar? ... in my case, that works as desired, with with the command line cursor visible in, and kb input going to, the new tab.
|---End Quote---
|
|How about if you click on "Tabs / New Tab"?

No problem. There's a problem only with Tabs\Run.

 

[Jim Cook]

I reported something like this in http://jpsoft.com/forums/showthread.php?p=9937#poststop which I can now reproduce still:

TCC 12.10.65 x64 Windows 7 [Version 6.1.7600]
TCC Build 65 Windows 7 Build 7600

Start TCMD which opens a single tab.
Run a batch file that contains solely "delay 10"
Using only the keyboard and not the mouse,
1) Press ^C while the batch file is running.
2) Do not answer the "Cancel" question yet.
3) Touch Alt and then release. Touch t and then release. Touch t and then release.

The new tab comes to the front but the back window still has the focus. Typing puts characters in the back (first) tab.

Alt-tabbing away and back does not solve the problem. Clicking does. Using the keyboard to switch tabs (Alt-Left & Right on mine) solves it.

 

[rconn]

I reported something like this in http://jpsoft.com/forums/showthread.php?p=9937#poststop which I can now reproduce still:

External similarities notwithstanding, this has nothing to do with the focus issue Vince is seeing. Your problem is due to the way Windows handles exceptions in consoles, and it's unlikely there will be a workaround.

I was eventually able to reproduce Vince's problem on an old XP machine; it turns out to be an XP focus timing bug when returning from a dialog. I've added an ugly timer kludge for the next build to work around it. (Though a better solution would be for Vince to update to a version of Windows created sometime after the discovery of fire).

 

[Charles Dye]

I can't reproduce this in build 66.