Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

An annoying bug with TCC's icon handling in the taskbar

Jun
9
0
I have found a very annoying bug in the TCC (9.02.152) in connection with tasklist button icons changed by the TCC.

The problem described step-by-step:


- I start a TCC console window.

The TCC shows the shell nesting level as "0"

The associated tasklist button shows the TCC icon.


- Now, I start the console version of the Semware Editor Professional (TSE) within this console window.

The associated tasklist button shows the TSE icon


- Within the TSE I call a further TCC-Shell.

The TCC shows the shell nesting level as "0"

The associated tasklist button shows the TCC icon


- I exit the TCC-Shell executed from within the TSE

The associated tasklist button shows the TCC icon furthermore


Sometimes the associated tasklist button shows permanently the TSE icon, and the title bar of the window with a Commander clone shows the cmd icon instead of the commander icon.

The problem only occurs in programs, that allow to start further tcc shells.

The problem is more annoying, when I start a Norton Commander Clone (a console program) in the TCC shell (and I have permanently a console window running with this clone). Now, when I start a programm like the TSE from this commander clone and I start a TCC-Shell from the TSE, the icon from the tasklist button shows permanently the TCC icon.

If I have several program buttons in the tasklist (which will not show the hole text in it), it's very difficult to find the button, there is representing the commander clone. This will hindering the workflow considerable.

I would be very glad, if this behaviour could be fixed as soon as possible. With 4NT version 7.01.370 and befor, this problem was not in existence.

In expecting of your help I would be very pleased...

Best regards,
-Urmel-

P. S. When Rex says, that Windows handles this behaviour, then I say that I've never seen this problem, until I've installed tc/tcc.
 
A very annoying bug with TCC's icon handling in the tasklist button

Urmel wrote:

> I have found a very annoying bug in the TCC (9.02.152) in connection
> with tasklist button icons changed by the TCC.

I don't know what you're referring to with "tasklist button icons".

> The problem only occurs in programs, that allow to start further
> tcc shells.

Starting a shell from an app is an obsolete DOS concept. There's no
reason to ever do that nowadays -- just switch to another TCC window.

Rex Conn
JP Software
 
A very annoying bug with TCC's icon handling in the tasklist button

JP Software Forums" <[email protected]>; "rconn wrote:
| Urmel wrote:
|
|
| ---Quote---
|| I have found a very annoying bug in the TCC (9.02.152) in connection
|| with tasklist button icons changed by the TCC.
| ---End Quote---
| I don't know what you're referring to with "tasklist button icons".
|
|| The problem only occurs in programs, that allow to start further
|| tcc shells.
|
| Starting a shell from an app is an obsolete DOS concept. There's no
| reason to ever do that nowadays -- just switch to another TCC window.

Not true. Many applications use that method to utilize command processor
features, and process the result. All versions of the C standard require the
availability of a library function to do that (system()). Admittedly, the
only thing passed back directly to the application is the command processor
exit code, anything else has to be done through file system changes, or the
application has to retrieve the changes directly from the OS.

Most IDEs and "make" programs require this feature.
--
Steve
 
I don't know what you're referring to with "tasklist button icons".

The icon on a button on the taskbar, that refer a running program.

Starting a shell from an app is an obsolete DOS concept.

I know several programs, that use this concept till this day...
And Steve writes several good examples in his comment.

There's no reason to ever do that nowadays -- just switch to another TCC window.

I can't do this! The Shell-command in the TSE (Editor) is hard coded in the program file. And I use this editor very often a day! In some cases, I must use the shell from the editor (e. g. run a converter/compiler/external calculator, and so on).

I'm working very, very often in a TCC window and use the TSE a lot of a day. I'll do this, to speed up my work - and the icon problem makes me slower...

I've updated my 4NT to the actual version, which I will use several of the new commands (especially the monitoring commands and others).

But the behaviour with the shell is so cramping, that I consider to go back to the 4NT 7.01 that I've used befor the actual version.

I use your tools since 4DOS/4OS2/4NT. And this fine tools (and Take Command I hope) are great tools TO ENHANCE the standard concepts from DOS, OS/2 and Windows. It is impossible to support the shell concept whitout the icon problem? 4NT 7.01 dosn't have the behaviour of the actual version - so it is possible to fix this - or not?

Currently its my greatest wish, that I don't must downgrade to the old version because a small cosmetic problem that's so hindering.

I hope, that you can understand my problem...

Best regards,
-Urmel-
 
But the behaviour with the shell is so cramping, that I consider to go back to the 4NT 7.01 that I've used befor the actual version.

Currently its my greatest wish, that I don't must downgrade to the old version because a small cosmetic problem that's so hindering.

I hope, that you can understand my problem...

I sure don't. You're seriously considering reverting to a much older version, with far fewer useful features, over a "small cosmetic problem"?
 
Urmel wrote:

>
> Quote:
> Originally Posted by *rconn* View Post <SHOWTHREAD.PHP?P=2752#POST2752>
> I don't know what you're referring to with "tasklist button icons".
>
> The icon on a button on the taskbar, that refer a running program.

The change (made in v8) was at the request of a LOT of users, who were
having problems with the Windows bug that causes it to only occasionally
update the console icon. (So a 4NT session usually showed the CMD icon,
unless you manually flushed the Windows icon cache.)

There isn't any option in v9 or v8 to switch back to the old way of
(usually futilely) hoping that Windows would get around to updating the
icon. (Yours is the only request we've had for this in the last 3
years.) I will add it to the suggestion list for a future version.
 
On Sat, 25 Oct 2008 11:52:22 -0500, "JP Software Forums"
<[email protected]>,Charles Dye <> wrote:


>I sure don't. You're seriously considering reverting to a much older version, with far fewer useful features, over a "small cosmetic problem"?

Can't you ...

... before doing anything to the console icon, get a handle to the current one
(the default or that of whatever console app started TCC) and purposefully
restore it when TCC exits?
 
You're seriously considering reverting to a much older version, with far fewer useful features, over a "small cosmetic problem"?

Technically it's imho a small cosmetic problem, for the daily work it's a middling horror for me...

Just imagine you have so much buttons on the taskbar, so that their text labels are strongly shortened. You can't distinguish the buttons based on their text labes. Now, you must select a running program by means of the icon on the buttons on the taskbar. But now, several buttons will have the same icon although this buttons represents different programs. Because you permanently starts and exits programs, the position of their buttons on the taskbar is every so often different. Therefore you'll find out the wished button by trial and error. A very frustrating way.

I works very often with several console programs, so I have permanently several buttons their icon are not squared with the linking program. Therefore I have a very big frustration.

Rex' output of new versions is very high. I'm a correct user and I have all my programs buyed or unsolicitous donated. But my financial resources are limmited due a severe accident and the following life situation. I should like to have the possibility to buy all new versions.

But I hope, that Rex is able and willing to fix this behaviour.

Even perhaps a parallel installation is a practicable way - I hope not.

Best regards,
-Urs- aka Urmel
 
There isn't any option in v9 or v8 to switch back to the old way

It's very hard to read this...

(Yours is the only request we've had for this in the last 3 years.)

I'm a declining holdover of users that today works as on a DOS system.
(But a DOS system with 4DOS and Norton Commander ;-)

I will add it to the suggestion list for a future version.

It means, that I must see to life with a parallel installation.

Thank you, for your informations.

Best regards,
-Urs- aka Urmel
 
vefatica wrote:

> On Sat, 25 Oct 2008 11:52:22 -0500, "JP Software Forums"
> ,Charles Dye <> wrote:
>
> Quote:
> >I sure don't. You're seriously considering reverting to a much older
> version, with far fewer useful features, over a "small cosmetic problem"?
>
> Can't you ...
>
> ... before doing anything to the console icon, get a handle to the
> current one
> (the default or that of whatever console app started TCC) and purposefully
> restore it when TCC exits?

I *could*, but Windows is supposed to to be doing that. If Windows is
working correctly (which seems to vary on a system-by-system basis),
anything I wrote would be immediately destroyed when TCC exits. I don't
know if Windows would even allow TCC to manipulate an icon handle
belonging to another process.

I haven't seen this problem in Vista or Server 2008, so perhaps MS
finally fixed it.

Rex Conn
JP Software
 
We put out a new version roughly once a year -- I don't think I've heard
that referred to before as "very high"! :-)

For a basically one-man operation, and considering that "new versions" often do add significant new functionalities, I'd say that's a very impressive rate.
 
On Sat, 25 Oct 2008 14:50:33 -0500, "JP Software Forums" <[email protected]>,rconn
<> wrote:


>> Can't you ...
>>
>> ... before doing anything to the console icon, get a handle to the
>> current one
>> (the default or that of whatever console app started TCC) and purposefully
>> restore it when TCC exits?
>---End Quote---
>I *could*, but Windows is supposed to to be doing that. If Windows is
>working correctly (which seems to vary on a system-by-system basis),
>anything I wrote would be immediately destroyed when TCC exits. I don't
>know if Windows would even allow TCC to manipulate an icon handle
>belonging to another process.

I never thought Windows bothered with the console icon after the console was
created. I did a lot of experimenting when I wrote SETICON.EXE (and later the
SETICON plugin function) and I have never seen windows change a console icon
except in the case where SetConsoleIcon() (kernel32.dll) is called with an
invalid HICON.

FWIW, I can duplicate the OP's problem with K95.EXE (Kermit95). If I shell out
to TCC and quit TCC the icon stays TCC's icon.

I noticed something peculiar when trying to repro this with TCSH. In TCSH, if I
issue "f:/WINDOWS/system32/cmd.exe" then CMD starts in the same console; exiting
CMD takes me back to the TCMD prompt. It's the same for, say, FTP.EXE or
K95.EXE. But if I issue "d:/tcmd9/tcc.exe" (TCC starts in the console), when I
exit TCC, TCSH "encounters a problem" (message box appears) and TCMD gives the
message

free(0x7fbdad88) bad block. (memtop = 0x7fc10800 membot = 0x7fbb0000)

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

TCC is the only console app I can find that causes TCSH to do that.
 
vefatica wrote:
> Quote:

> I noticed something peculiar when trying to repro this with TCSH. In
> TCSH, if I
> issue "f:/WINDOWS/system32/cmd.exe" then CMD starts in the same console;
> exiting
> CMD takes me back to the TCMD prompt. It's the same for, say, FTP.EXE or
> K95.EXE. But if I issue "d:/tcmd9/tcc.exe" (TCC starts in the console),
> when I
> exit TCC, TCSH "encounters a problem" (message box appears) and TCMD
> gives the
> message
>
> free(0x7fbdad88) bad block. (memtop = 0x7fc10800 membot = 0x7fbb0000)
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
>
> TCC is the only console app I can find that causes TCSH to do that.

You seem to be referring to TCMD and TCSH interchangeably - how can TCMD
be involved in what happens when you exit CMD from TCSH?

That message box is not coming from TCC or TCMD.

Rex Conn
JP Software
 
On Sat, 25 Oct 2008 16:55:21 -0500, "JP Software Forums" <[email protected]>,rconn
<> wrote:


>vefatica wrote:
> > Quote:
>
>
>---Quote---
>> I noticed something peculiar when trying to repro this with TCSH. In
>> TCSH, if I
>> issue "f:/WINDOWS/system32/cmd.exe" then CMD starts in the same console;
>> exiting
>> CMD takes me back to the TCMD prompt. It's the same for, say, FTP.EXE or
>> K95.EXE. But if I issue "d:/tcmd9/tcc.exe" (TCC starts in the console),
>> when I
>> exit TCC, TCSH "encounters a problem" (message box appears) and TCMD
>> gives the
>> message
>>
>> free(0x7fbdad88) bad block. (memtop = 0x7fc10800 membot = 0x7fbb0000)
>>
>> This application has requested the Runtime to terminate it in an unusual
>> way.
>> Please contact the application's support team for more information.
>>
>> TCC is the only console app I can find that causes TCSH to do that.
>---End Quote---
>You seem to be referring to TCMD and TCSH interchangeably - how can TCMD
>be involved in what happens when you exit CMD from TCSH?

I misspoke. TCMD is not involved. It's TCSH that has trouble when a spawned
TCC in the same console exits.
 
vefatica wrote:

> On Sat, 25 Oct 2008 16:55:21 -0500, "JP Software Forums" ,rconn
> <> wrote:
> I misspoke. TCMD is not involved. It's TCSH that has trouble when a spawned
> TCC in the same console exits.

That has to be a TCSH bug; there's no way that TCC could affect the
parent process (barring a catastrophic Windows bug).

Have you contacted the TCSH developers?

Rex Conn
JP Software
 
On Sat, 25 Oct 2008 19:32:11 -0500, "JP Software Forums" <[email protected]>,rconn
<> wrote:


>> On Sat, 25 Oct 2008 16:55:21 -0500, "JP Software Forums" ,rconn
>> <> wrote:
>> I misspoke. TCMD is not involved. It's TCSH that has trouble when a spawned
>> TCC in the same console exits.
>---End Quote---
>That has to be a TCSH bug; there's no way that TCC could affect the
>parent process (barring a catastrophic Windows bug).
>
>Have you contacted the TCSH developers?

That's hard to do and unlikely to do any good. Besides, TCC is the only app to
cause such trouble. All versions back to 4NTv5 cause the problem. 4NTv4.02
does not cause a problem. While the error happens in TCSH it seems oddly
connected to what TCC does.

The error apparently happens when 4NT exits and TCSH tries to execute its
"precmd" alias, which, here, is: 'title "$cwd"'. TCSH's "title" command uses
SetConsoleTitleA().

No error occurs if I "unalias precmd" before starting TCC.

No error occurs if the TCC session is transient, even if TCC messes with the
console title; for example with

TCSH> d:/4nt/4nt.exe /c title foo \& delay 2

but the error occurs when any non-transient instance exits.

The error occurs with no plugins loaded.
 
vefatica wrote:

> On Sat, 25 Oct 2008 19:32:11 -0500, "JP Software Forums" ,rconn
> <> wrote:
>
>
> Quote:
> >> On Sat, 25 Oct 2008 16:55:21 -0500, "JP Software Forums" ,rconn
> >> <> wrote:
> >> I misspoke. TCMD is not involved. It's TCSH that has trouble when a
> spawned
> >> TCC in the same console exits.
> >---End Quote---
> >That has to be a TCSH bug; there's no way that TCC could affect the
> >parent process (barring a catastrophic Windows bug).
> >
> >Have you contacted the TCSH developers?
>
> That's hard to do and unlikely to do any good. Besides, TCC is the only
> app to
> cause such trouble. All versions back to 4NTv5 cause the problem. 4NTv4.02
> does not cause a problem. While the error happens in TCSH it seems oddly
> connected to what TCC does.

But since there's 0% chance of anything in TCC causing TCHS's problem,
it seems you'd have better luck fixing it in TCSH. Why would it be
"unlikely to do any good"?

Rex Conn
JP Software
 
On Sun, 26 Oct 2008 11:51:49 -0500, "JP Software Forums" <[email protected]>,rconn
<> wrote:


>But since there's 0% chance of anything in TCC causing TCHS's problem,
>it seems you'd have better luck fixing it in TCSH. Why would it be
>"unlikely to do any good"?

I was remembering the old days. Now there's a bug tracking system. I submitted
a report. I also found this:

http://support.microsoft.com/kb/884538
You receive a "This application has requested the Runtime to terminate it in an
unusual way" error message when you run a custom Microsoft Visual C++ 6.0
program in Windows XP.

I have a hotfix but will wait for some feedback from the bug-track site.
 
On Sun, 26 Oct 2008 11:51:49 -0500, "JP Software Forums" <[email protected]>,rconn
<> wrote:




I was remembering the old days. Now there's a bug tracking system. I submitted
a report. I also found this:

http://support.microsoft.com/kb/884538
You receive a "This application has requested the Runtime to terminate it in an
unusual way" error message when you run a custom Microsoft Visual C++ 6.0
program in Windows XP.

I have a hotfix but will wait for some feedback from the bug-track site.

The Hotfix didn't help.

</[email protected]>
 
I'm not a Windows programmer. So I don't understand the following circumstance (which the icons on a button on the taskbar).

When I call e. g. the editor TSE from TCC, the icon from the TCC will be replaced with the icon from the TSE. When I exits the TSE, the Icon will replaced once again - now with the icon from the TCC. As far as this point, everything is functioning as expected.

When I exits a shell called from within the TSE, the re-change of the icon will not work. Likewise I do this from the Norton Commander clone in a TCC shell.

What's different - for the icon handling on the button - when I exits a TCC shell started from within a console app or when I exit a console app from within a TCC window.

Imho this is a indentical procedure. Why works the update of the icon in one case as espexted and in the other case it fails?

!!! Rex wrote, that the change of the icon handling was made due request of a lot of users because a Windows bug.

!!! Therefore I'm considering if it's possible to make this behaviour configurable in the option dialog?

!!! If there is no way for my interest, Rex it is legally to use two different version off TCC/4NT parallel on a system?

Best regards,
-Urs- aka Urmel
 
On Sun, 26 Oct 2008 15:51:28 -0500, "JP Software Forums" <[email protected]>,Urmel
<> wrote:


>I'm not a Windows programmer. So I don't understand the following circumstance (which the icons on a button on the taskbar).
>
>When I call e. g. the editor TSE from TCC, the icon from the TCC will be replaced with the icon from the TSE. When I exits the TSE, the Icon will replaced once again - now with the icon from the TCC. As far as this point, everything is functioning as expected.

Those happen because (1) TSE sets the TSE icon when it starts, and (2) TCC
resets the TCC icon when TSE exits.

>
>When I exits a shell called from within the TSE, the re-change of the icon will not work. Likewise I do this from the Norton Commander clone in a TCC shell.

Most likely this is because TSE/Norton, although they set their icon at startup,
do not **reset** their icon when a started app exits.


>What's different - for the icon handling on the button - when I exits a TCC shell started from within a console app or when I exit a console app from within a TCC window.

As suggested above, TCC resets its icon after a started app exits; not all apps
do that.


>Imho this is a indentical procedure. Why works the update of the icon in one case as espexted and in the other case it fails?

It's symmetric but not identical. It could be argued that TSE is at fault for
failing to reset its icon.
 
For a basically one-man operation, and considering that "new versions" often do add significant new functionalities, I'd say that's a very impressive rate.

This strays from the topic, but agreed, it's impressive, all the more that it's been so for a looong time. Chapeau to a consummate professinal. But this year the rate has decreased significantly, to wit 3 months between TCMD builds 151 and 152, and nothing since September. I'm hoping Rex is in good health, and not yet ready to hang up his spurs.
--
Peter
 
On Sat, 01 Nov 2008 18:39:38 -0500, "JP Software Forums" <[email protected]>,Peter
Bratton <> wrote:


>This strays from the topic, but agreed, it's impressive, all the more that it's been so for a looong time. Chapeau to a consummate professinal. But this year the rate has decreased significantly, to wit 3 months between TCMD builds 151 and 152, and nothing since September. I'm hoping Rex is in good health, and not yet ready to hang up his spurs.

Typically all you get with a new build is bug fixes. There might be a few
enhancements in a new minor version (9.01 to 9.02, say). Version 10 is in the
works and it will have, as usual, a handsome collection of new features.
 

Similar threads

Back
Top