Dumping global lists to the *sav files

[vefatica]

Does TCC have a built-in way to dump the global lists to SHRALIAS_SAVE_PATH\*.sav (in Unicode, with BOM)? ("SHRALIAS /D(ump)" might be a nice addition.)

I have crashed TCC about 20 times in the last day messing with ON BREAK. Every time it wipes out my global lists and the best I can do is manually replace them from the 21-day old *sav files. I'd like to make a scheduled task to keep the *sav files up-to-date.

 

[rconn]

No, though it would only require a trivial alias to do it.

 

[vefatica]

No, though it would only require a trivial alias to do it.

Yeah, I figured that shortly after posting.

CDD %shralias_save_path & %comspec /U /C do f in *.sav ( %%@name[%%f] > %%f )

(or something like that).

 

[Howard Goldstein]

Yeah, I figured that shortly after posting.

CDD %shralias_save_path & %comspec /U /C do f in *.sav ( %%@name[%%f] > %%f )

(or something like that).

Why not simply unload and then reload SHRALIAS?

--
Howard

 

[vefatica]

Why not simply unload and then reload SHRALIAS?

--
Howard

Because my SHRALIAS is in a DLL injected into Explorer.

 

[Steve Fabian]

Does it not still work in the same manner, i.e., cause the memory mapped files which contain the global lists to remain open when no TCC instance is active, and store their contents into the specified files when the SHRALIAS task is terminated?

 

[vefatica]

Does it not still work in the same manner, i.e., cause the memory mapped files which contain the global lists to remain open when no TCC instance is active, and store their contents into the specified files when the SHRALIAS task is terminated?

It works just like SHRALIAS.EXE. When the DLL in injected, if it finds shared files it guards them. And it dumps them on exit (which for the DLL is WM_QUERYENDSESSION ... logoff/shutdown). My DLL does a couple of other things unrelated to SHRALIAS ... provides a global hot-key server, and turns MBUTTONs into double left clicks.

 

[Steve Fabian]

It works just like SHRALIAS.EXE. When the DLL in injected, if it finds shared files it guards them. And it dumps them on exit (which for the DLL is WM_QUERYENDSESSION ... logoff/shutdown).

Does it obey the "shralias /u" command?

My DLL does a couple of other things unrelated to SHRALIAS ... provides a global hot-key server, and turns MBUTTONs into double left clicks.

I use Logitech software for the latter (I have Logitech trackballs; I remember you consider the Logitech software bloated). What does the "global hot-key server" do that is not provided by Windows Explorer, or does it just do some things better?

 

[vefatica]

No, it doesn't obey any SHRALIAS commands. Not knowing how the SHRALIAS command works, I can't build in that functionality.

Logitech Trackman Marble here ... love them ... a while back I replaced a worn-out left button switch in the one at home. IIRC, the Logitech software is bloated ... at least much more than my simple task needs (MBUTTON to double-click).

The hot-key server manages global hot-keys (RegisterHotKey()) and implements them (via messages to a window process). They work everywhere without a need for desktop shortcuts. Right now I have

v:\> shrhotkey list
 
Key: Ctrl-Alt-t
Command: taskmgr
Directory: c:\Windows\System32\
 
Key: Ctrl-Alt-d
Command: G:\Uty\schtasks.exe /run /tn dtswitch
Directory: g:\uty
 
Key: Ctrl-Alt-a
Command: g:\uty\schtasks.exe /run /tn TCC
Directory: g:\uty
 
Key: Ctrl-Alt-s
Command: g:\uty\showdesk.exe
Directory: g:\uty
 
Key: f9
Command: g:\uty\toggletcc.exe "g:\tc14\tcc.exe /q"
Directory: v:\
 
Key: f8
Command: g:\tc14\tcc.exe /q
Directory: v:\

The second and third above run on-demand scheduled tasks to, respectively, *switch to the services desktop (where my mail server runs) and *start an elevated TCC (both without a UAC prompt). The SHTASKS.EXE that they use is one which I changed from console app to GUI app (with EDITBIN.EXE) so I don't see an unsightly console. The fifth one cycles through running TCCs, bringing them to the foreground or toggles a single one between minimized and restored.

 

[jabelli]

I use this alias to not only dump them but also dump to a backup in case the regular dump-on-exit clobbers one due to it being cleared for some reason.

setlocal & set unicodeout=%@option[unicodeoutput] & option //unicodeoutput=Yes & for %a in (alias history dirhistory function) (%a | tee "%@path[%_ininame]%a.sav" > "%@path[%_ininame]%a.sav.bak") & option //unicodeoutput=%unicodeout & endlocal

 

[Steve Fabian]

1/ Internal variable _unicode is 0 for ASCII and 1 for unicode output. Quicker than using @option[], though you need to parse it for restoring the mode. You could make the mode changes conditional - do them only if current mode is ASCII.
2/ Your use of %@path[%_ininame] is not portable, though it happens to be where I save things, too, using the SHRALIAS_SAVE_PATH variable. In any event, since you use SETLOCAL already, it would require parsing it only once if you
CDD %@path[%_ininame]
before the FOR, making the alias easier to understand.
3/ Using a pipe and TEE is probably much slower than dumping the command output to the .SAV file, and using COPY to back it up.

 

[vefatica]

OK ... lots of ways to dump the lists to the SAV files. Thanks.

But I can't get it to work in a scheduled task. I run the task as "vefatica" the same user name used to name the memory-mapped files. During the task, _WINUSER reports "vefatica" but the task (TCC) doesn't see the memory-mapped files. I suppose the task is in another "session" (or something like that). Does anyone know? Does anyone know if I can make a scheduled task run in the logon session?

 

[jabelli]

setlocal & cdd "%SHRALIAS_SAVE_PATH" & set uni=%_unicode & iff %uni == 0 then & option //unicodeoutput=Yes & endiff & for %a in (alias history dirhistory function) (%a > %a.sav & copy /q %a.sav %a.sav.bak) & iff %uni == 0 then & option //unicodeoutput=No & endiff & endlocal

Yes it’s faster, by about half a second, thanks. I also made sure to use IFF rather than IF, so the “Duplicate CMD.EXE Bugs” setting doesn't matter.

 

[jabelli]

Vince-
“Run only when logged on” should do what you want. When you’re not logged on, there’s nothing to save because you haven’t changed anything. When you log off, it saves the changes anyway. The only problem is that it’s going to show a console window. I use HSTART to run batch files hidden. This saves having to create a copy of TCC and using EDITBIN from VS/WinSDK to change the subsystem.

 

[Steve Fabian]

I also made sure to use IFF rather than IF, so the “Duplicate CMD.EXE Bugs” setting doesn't matter.

In other words, those of us who can depend on the "DuplicateBugs=No" setting, could further simplify the alias to:

setlocal %+ cdd "%SHRALIAS_SAVE_PATH" %+ set uni=%_unicode & if %uni == 0 option //unicodeoutput=Yes & for %a in (alias history dirhistory function) (%a > %a.sav %+ copy /q %a.sav %a.sav.bak) %+ if %uni == 0 option //unicodeoutput=No %+ endlocal

Note that I used the symbolic form of the command separator, to provide independence from another custom setting.

 

[vefatica]

Vince-
“Run only when logged on” should do what you want. When you’re not logged on, there’s nothing to save because you haven’t changed anything. When you log off, it saves the changes anyway. The only problem is that it’s going to show a console window. I use HSTART to run batch files hidden. This saves having to create a copy of TCC and using EDITBIN from VS/WinSDK to change the subsystem.

I tried that. The task interacts with the logged-on user's desktop and @WINUSER is correct, but the memory-mapped files are not found.

 

[jabelli]

I tried that. The task interacts with the logged-on user's desktop and @WINUSER is correct, but the memory-mapped files are not found.

Strange, I tried it with creating a task for a batch file containing just the lines “alias” and “pause” and got an alias list when running it manually (on Windows 7). Maybe it has something to do with your DLL?

 

[vefatica]

Strange, I tried it with creating a task for a batch file containing just the lines “alias” and “pause” and got an alias list when running it manually (on Windows 7). Maybe it has something to do with your DLL?

Actually, when I tried it again, it did work. I don't know what I did wrong the first few times but it's OK now.