Welcome!

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

SignUp Now!

March Plugins

Charles Dye

Super Moderator
May
4,948
126
Staff member
A number of minor updates this month:

ISO8601 plugin v1.2.4
Converted to Visual Studio 2010; disallow negative values for @ORD; close help file on shutdown.

SafeChars plugin v1.6.5
Minor tweaks to @UQUOTES, and documented its control variables.

Fortune plugin v1.1.2
Updated to handle UTF-8 text files; documented the environment variables which affect quote replacement.

PrinterStuff plugin v0.65.1
Tweaked to recognize Windows 8; added PRINTERDATA command, /R option to ADDPRINTER; close help file on shutdown.

UIStuff plugin v0.55.0
Many minor improvements to the MKSC command.

The complete list of my plugins is here: http://www.unm.edu/~cdye/plugins/index.html
 
Charles:
Thanks for your plugins, I use several regularly, and am about to switch to using UIStuff instead of qres.exe, etc. I often use older TCC versions, though usually for just a few minutes at a time. I hardly ever go back to V10 or earlier. Regardless, it would be useful if your index would have a TCC version compatibility column, showing the earliest 4NT/TCC version with which a specific plugin is compatible with.

Regarding UIStuff:MKSC command -
1/ modifying existing shortcut, I presume I need to specify only those fields that are to be modified?
2/ modifying existing shortcut, it would be nice to be able to override attributes RHS
3/ modifying existing or creating new shortcut it would be nice to be able to specify its attributes
4/ is it possible to specify a hidden window?
5/ all of my "global hotkeys" require all 3 modifies keys: alt, control, and shift - WinXP likes it, and I never saw an application that uses it. MKSC reports them properly, did not try creating / modifying.
6/ when a shortcut is created by MKSC, or a hotkey is added or changed using MKSC, when is it registered? IIRC, TCC's internal SHORTCUT command defining new hotkey requires logging out and back in for effectuation. (Restart is, of course, a superset).
 
I often use older TCC versions, though usually for just a few minutes at a time. I hardly ever go back to V10 or earlier. Regardless, it would be useful if your index would have a TCC version compatibility column, showing the earliest 4NT/TCC version with which a specific plugin is compatible with.

I'm not aware of any issues with most of them, though I haven't done any real testing with older versions. SafeChars and PopInfo have special limitations, which are documented. Other than those two, I don't know of any reason why they shouldn't work with old versions.

Regarding UIStuff:MKSC command -
1/ modifying existing shortcut, I presume I need to specify only those fields that are to be modified?

Yes; and you don't have to enter unneeded info when creating a shortcut, either. (Design goal #2 was "Optional arguments are optional, and may be entered in any order.")

2/ modifying existing shortcut, it would be nice to be able to override attributes RHS
3/ modifying existing or creating new shortcut it would be nice to be able to specify its attributes

Easy enough to add, but would it really be useful? (And what conceivable use does a hidden shortcut have, anyway? Does Explorer read hotkeys from hidden shortcut files?)

4/ is it possible to specify a hidden window?

I originally had about eight specific design goals for MKSC, and that's the only one I was never able to achieve. You can set any value you like, but Windows only seems to honor SW_SHOWMINNOACTIVE and SW_MAXIMIZED. Anything else just gives you a regular window.

6/ when a shortcut is created by MKSC, or a hotkey is added or changed using MKSC, when is it registered? IIRC, TCC's internal SHORTCUT command defining new hotkey requires logging out and back in for effectuation. (Restart is, of course, a superset).

I haven't seen that documented anywhere; possibly Microsoft's programmers doesn't clearly understand it themselves. My experience (under XP) suggests that hotkeys are recognized as soon as they are defined, but not "de-recognized" if you remove or change them. After changing the hotkey for a single shortcut a couple of times, I've seen Explorer blissfully launching the same program for any of three different hotkeys -- until Explorer was restarted.
 
Thanks for your answer. I keep a set of directories named PL07 ... PL13; my "plugins" directories are junctions. Every plugin is hardlinked into all version-specific directories where it is usable. Accordingly, I will do that for all your plugins but for the two version-limited ones.

I use the R attribute on all shortcut files, and I have a few (related to games) that I modify after each round. I don't use the HS attributes, just listed them by habit.

I love your "design goal #2". BTW, how do you restart Explorer without logging out?
 
Do you use an alias ("effectively")? Should this (explorer restart) be an option of the MKSC command when it does hotkey changes? Of course, I may want to make many shortcut changes in a row before activating the new hotkey set - so I'd have to set the "explorer restart" option only in the last one to avoid unnecessary delays...
 
My experience (under XP) suggests that hotkeys are recognized as soon as they are defined, but not "de-recognized" if you remove or change them. After changing the hotkey for a single shortcut a couple of times, I've seen Explorer blissfully launching the same program for any of three different hotkeys -- until Explorer was restarted.
My experience under XP is that you can make Explorer release a hotkey H assigned to shortcut S as follows: create a temporary shortcut T with hotkey H; set T's hotkey = H; reset T's hotkey ( =0 ) ; reset S's hotkey; delete T; delete S. This will free H for reuse with no need to restart Explorer.
 
Charles:
Stefano's procedure is logically sound, if complicated (until doing it becomes habit). I assume when he write "set T's hotkey = H" he means interactively, by opening T's property dialog in explorer. Would you test if it can be done through repeated use of MKSC (and ERASE), or better yet, directly though the underlying API calls that MKSC uses, so it could be automated?
It could then be made into another option for MKSC. By the way, is it possible for a plugin to locate the shortcut which registered a particular hotkey?
 
My experience under XP is that you can make Explorer release a hotkey H assigned to shortcut S as follows: create a temporary shortcut T with hotkey H; set T's hotkey = H; reset T's hotkey ( =0 ) ; reset S's hotkey; delete T; delete S. This will free H for reuse with no need to restart Explorer.

And end up deleting both shortcuts? Um....
 
I assume when he write "set T's hotkey = H" he means interactively, by opening T's property dialog in explorer.
No, programmatically. Sorry, I don't have C code to show, I scripted all this a long time ago. The script silently managed S and T when a new H value was being set for an existing S. I guess MKSC could do the same. Note: the procedure I suggested is untested on Win7.
 
UIStuff issues

General
"Status and Licensing" page has a link from "issues" to a Wikipedia page [informative for people who haven't lived through the early days of computers]; I'd rather have the link point to a way to report the issue, either by email preaddressed to you, or by a link to this or some other forum.

@SCINFO issues
1/ it quotes the string values even if they are already surrounded by quotation marks. This makes it impossible to use its output directly in MKSC. This failed:
mksc z.lnk /a:%@replace[12,14,%@scinfo[z.lnk,1]]
because the function value was
""F:\JPSOFT\IZ\tcmd.exe /@F:\JPSOFT\TC12.INI""

This can be worked around by using %@quote[%@unquote[%@scinfo[file,index]]] but it is quite inconvenient...
2/ using an info index higher than the last valid one defaults to 0 - e.g. % @scinfo[z.lnk,19] is the same as
%@scinfo[z.lnk,0]
3/ instead of using indexes the same mnemonic letter codes as are used by MKSC would simplify usage
4/ many functions built into TCC accept unquoted filenames with embedded spaces when it is clear to the parser that everything up to the closing bracket ] must be part of a single filename, e.g.
%@crc32[f,JP TZ acsX.lnk]
This would be a nice (though not a necessary) enhancement, but would require swapping the order of the parameters for unambiguity; of course a new name could be used for the function for backward compatibility, but the clause "consider this beta software" would allow this change before you officially release it. Actually, I like the reversed order, when tabular listing of the code is made, the information category would always be in the same column, and it would match many built-ins.

Thanks for a very very useful tool!
 
General
"Status and Licensing" page has a link from "issues" to a Wikipedia page [informative for people who haven't lived through the early days of computers]; I'd rather have the link point to a way to report the issue, either by email preaddressed to you, or by a link to this or some other forum.

Hmmm....

@SCINFO issues
1/ it quotes the string values even if they are already surrounded by quotation marks. This makes it impossible to use its output directly in MKSC. This failed:

Working as documented; but not everything is documented. Try adding 256 to info.

2/ using an info index higher than the last valid one defaults to 0 - e.g. % @scinfo[z.lnk,19] is the same as
%@scinfo[z.lnk,0]

So don't do that already! I reserve them for future expansion. In the meantime, assume that invalid arguments will reformat your hard drive, post your credit card info on Twitter, and cause spontaneous human combustion.

3/ instead of using indexes the same mnemonic letter codes as are used by MKSC would simplify usage

That's an idea.

4/ many functions built into TCC accept unquoted filenames with embedded spaces when it is clear to the parser that everything up to the closing bracket ] must be part of a single filename, e.g.

You don't actually have to quote the filename, unless it contains commas. (But it never hurts.)
 

Similar threads

Back
Top