Welcome!

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

SignUp Now!

Fixed Another Issue with XHISTORY

Jay Sage

Jay Sage

Jun
739
16
I just tried editing a command in the history and then pressing ENTER. The modified command was not executed; the original command was. The edited command appeared in the history only after I reopened the popup window, and then I could execute it.
 
At the upper-right corner there is an edit button and a delete button.
 
Jay Sage said:
At the upper-right corner there is an edit button and a delete button.
Click to expand...
OK, I missed that. Yeah, editing makes no changes in what's visible in the dialog or in what's executed. But if you edit and don't execute, the entry is changed in the "C:\ProgramData\JP Software\XHistory32" file (as soon as the edit's done).
 
There are still problem, even more serious ones.

If I type some characters on the command line and then open the popup, the list is properly filtered. And if I edit a command, the edited version appears after I press ENTER. However, if I then press ENTER again to execute the edited command, TakeCommand crashes or the TCC session gets detached. I've seen both behaviors. Something is definitely not working correctly.
 
Not reproducible here.

Please provide the exact reprocible details of what you're doing - the original line, how you edited it (added, deleted, etc.), and what happened when you tried to execute the modified command.

It's highly unlikely that TCMD would have crashed (barring a catastrophic Windows bug), as the XHISTORY code is entirely in the TCC session. If TCC crashed (and was the only tab window) then TCMD would exit (unless you told it to stay alive after closing the last console session).
 
As I wrote in another post, after that last crash the Ctrl-Shift-PgUp and Ctrl-Shift-PgDn keys just do an ENTER at the command line. The popup window does not appear. This continues even after I close TakeCommand and restart it.

Any suggestion for how to get things back to normal?
 
Thanks. The file must have gotten corrupted. I deleted it from the Windows file manager, and now the popup works again.

I now tried to reproduce the previous crashes, and they don't happen. So there may have been some corruption of the history file before. I'll keep experimenting and let you know if I see any problems again.
 
A little different from Jay's report (#6) ... "ech" on the command line, invoke the dialog, it's properly filtered, move to "echo a^tb^tc", change it to "x^ty^tz", Enter ... I get a crash right there (didn't need another Enter). Quite oddly, I got 2 crash dumps!

Code: 
2024-03-20  12:20     194,213,691  tcc.exe(1).3004.dmp
2024-03-20  12:20     194,218,099  tcc.exe.3004.dmp

Opened the dialog again and saw this.

1710952530769.png


I tried the experiment again. TCC didn't crash but it was left pretty useless.
 
The file is corrupted. These lines appear.

Code: 
2024-02-19 11:22:05|0.002|2|v:\|echo a^tb^tz-02-19 11:22:42|0.164|0|v:\|historecho x^ty^tz
2024-02-19 11:22:54|0.554|0|v:\|history
2024-02-19 11:23:01|0.002|0|v:\|hist:echo x^ty^tz 11:23:07|0.002|0|D:\data\tcchistory|d
 
rconn said:
It's highly unlikely that TCMD would have crashed (barring a catastrophic Windows bug), as the XHISTORY code is entirely in the TCC session. If TCC crashed (and was the only tab window) then TCMD would exit (unless you told it to stay alive after closing the last console session).
Click to expand...

Yes, at least in some cases it was that the TCC session spontaneously detached from TakeCommand, after which the latter closed. In other cases, the TCC task may have crashed, not just detached, and then TCMD closed. Unlike Vince, I don't know how to access the crash reports to learn the precise details of what happened.

-- Jay
 
See this page for enabling user-mode dumps. You'd need something like WinDbg to actually look at them (which I rarely do) but having them around is no inconvenience and they might be helpful to a third party. My settings are these.

Code: 
v:\> regdir /d /v "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps"
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
  DumpFolder : REG_EXPAND_SZ : d:\work\LocalDumps
  DumpCount : REG_DWORD : 22
  DumpType : REG_DWORD : 2
 
Rex, is it your intention that the edited_then_executed command replace the one edited in xhistory32? That would seem contrary to the intent of the file. Better, and maybe easier, would be to leave the history alone and if the edited command is executed, put it at the end where it belongs. Maybe that was your intention all along(?).
 
My intention is that you will almost never edit the command in the extended history list and then immediately execute it. (If you want to do that, it's easier to select the entry, hit Ctrl-Enter, and edit it on the command line & execute.

The point of editing the command inside the popup window is to support multiple selections - i.e., if you made a mistake or for other reasons need to change one of the lines before doing a multiple selection.
 
rconn said:
The point of editing the command inside the popup window is to support multiple selections - i.e., if you made a mistake or for other reasons need to change one of the lines before doing a multiple selection.
Click to expand...

Who knew that one could highlight multiple commands! The help says the following:

"You can view the extended command history in a scrollable popup window, and select the command to re-execute or modify from those displayed in the window."

That is singular: the command. But, indeed, one can select multiple commands. There are other important details missing from that help page.

In the section on searching, it does not say that if one does not start with ts=, rt=, or cmd=, etc., the default is cmd=. Moreover, I discovered that searching with cwd=*drop" finds commands run from the dropbox folder. I did not have to write cwd=*drop*. A trailing asterisk seems to be assumed for all searches.

What are the right-click context menu items supposed to do? In particular, of what use would "copy+append" be? It seems to add the additional command line without a command separator.

-- Jay
 
rconn said:
The old history windows also support mutiple selections. Seemed too obvious to me to make a point about it for the new one.
Click to expand...

I didn't check the help for the "old history windows", but the help should be changed, as the help text essentially says that ONE line can be selected.

rconn said:
A trailing * is assumed unless you are doing a regular expression search. This is also old behavior.
Click to expand...

I understand that. I'm only suggesting that the help include that information (and that "cmd=" is assumed in the absence of any column indicator).

-- Jay
 
David Marcus said:
I'm confused. Are we discussing this: Take Command / TCC Help v. 32 . I don't see anything about multiple selection.
Click to expand...

In What's New in Version 32, and in the Extended Command History topics:

-------------------------------------------------------------------------

You can select multiple entries (with Ctrl-Click or Shift-Click). TCC will append the commands (separated with a &) before passing the result to the command line.

-------------------------------------------------------------------------
 
You must log in or register to reply here.
Back
Top