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 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" <neil@jpsoft.com>; "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
The icon on a button on the taskbar, that refer a running program. I know several programs, that use this concept till this day... And Steve writes several good examples in his comment. 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-
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: 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" <neil@jpsoft.com>,Charles Dye <> 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?
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
It's very hard to read this... I'm a declining holdover of users that today works as on a DOS system. (But a DOS system with 4DOS and Norton Commander ;-) It means, that I must see to life with a parallel installation. Thank you, for your informations. Best regards, -Urs- aka Urmel
vefatica wrote: 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
Urmel wrote: > Rex' output of new versions is very high. We put out a new version roughly once a year -- I don't think I've heard that referred to before as "very high"! Rex Conn JP Software
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" <neil@jpsoft.com>,rconn <> wrote: 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: 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" <neil@jpsoft.com>,rconn <> wrote: I misspoke. TCMD is not involved. It's TCSH that has trouble when a spawned TCC in the same console exits.
vefatica wrote: 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" <neil@jpsoft.com>,rconn <> wrote: 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: 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" <neil@jpsoft.com>,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.
