Copy names as 8.3 not working for me

[otlaolap]

For some reason on my system the 8.3 variants of the copy-names command are not working from the keyboard. Alt+Shift+C and Ctrl+Alt+Shft+C both return the long, non 8.3, format names rather than the dos-mode 8.3 format names. If I press and holld Alt+Shift or Ctrl+Alt+Shift, however, and then use the mouse to navigate to and click the "Edit->Copy names" menu item , the names do get copied correctly with the 8.3 format style. But I am a keyboard person and I want the keyboard version back. All of this is done using 64-bit X2 3.2.0.1 (the current release) on 64-bit Win 7.

Can someone on a similar system please try this and see what happens?

[Kilmatead]

Win7 x64, the above keyboard shortcuts work as expected for me.

If you go to Customise -> Keyboard -> (Category) Edit -> Copy names, does the current keys window show the 4 default variations?



As a complete (and crazy) last resort, you can also check to see if 8.3 names have been enabled (or disabled) for the particular volume you are using... just type:

$ FSUTIL.EXE 8dot3name query C:

into the x2 addressbar, obviously replacing C: with whatever volume you are using. (Just thinking outside the box, though if using the mouse to copy the names works for you, I doubt the format is disabled - it may be disabled on formatted volumes to increase speed by removing overhead, in case you're wondering.)

[otlaolap]

Thanks, and your comments directly solve the question I asked. The "Customize -> Keyboard -> (Catetgory) Edit -> Copy names" keys are all missing (because long ago I took them out). What I really am trying to do, though, is figure out why a script I have used for a long time is no longer working. The question I asked above I thought was an intermediate step to a solution, but it likely is a red herring.

The script (AutoHotkey) worked in the past. It sends keydowns for Ctrl and Alt (depending on what mode of copy I am requestion), then message 32786 (the number corresponding to copy names), and then keyups for the Ctrl and Alt keys that were down. The state of Ctrl and Alt, as sent by this mechanism, is now no longer detected; all copys are processed as if plain copy-names was specified. For a long time I have believed that there are a couple of 3XXXX routines in which the Esteemed Programmer interrogates the physical state of the modifier keys at the time his code is running (and does not use their logical state at the time the keybord 3XXXX message was sent), and it may be that I am now stumbling because of a change here or because I've messed something else up.

In any case, my question, reformulated as a result of your answer, can now only be "why does my hack no longer work", and this is too laughable a question to be asked.

[Kilmatead]

...interrogates the physical state of the modifier keys at the time his code is running (and does not use their logical state at the time the keyboard 3XXXX message was sent) [...] "why does my hack no longer work", and this is too laughable a question to be asked.

Au contraire! This is quite topical. Actually since rewriting MenuHack into C myself recently instead of using AutoIt, I ran across exactly the same problem. Under the hood of the WinAPI (which AutoHotKey is using, obviously) the keyboard/mouse input (asynch) stream and the window's message queue stream are handled separately, contrary to appearances ("sending" keycodes does not result in messages being added to the event queue). Thus, there's no "sequential" guarantee in processing order. This can be further exacerbated by exactly which subcontrol within the parent window handle itself has the focus at any given time (from menu/toolbar to active pane).

I initially used (as a blunt solution) the simple injection of a 150-millisecond delay between the last modifier (KEYEVENTF_KEYDOWN) and the sending of the queue ID itself (yes, MenuHack can handle modifier keys). This seemed to work, but goes directly to what I hate about scripting - too much is beyond the direct control of the coder and most of that is hidden as trial and error.

A secondary solution (which after a few weeks of testing seems to be working solid) is to send a "dummy" WM_COMMAND message of 0,0 between the (last) KEYEVENTF_KEYDOWN modifier and the primary SendMessage. x2's queue ignores 0 codes, but it is actually seen as a null MENU event nonetheless, which seems to have the extra benefit of "waking up" (or flushing) the message queue so that the modifiers are actually engaged properly before the real msgID is sent into proper focus. I'm still not entirely sure exactly why it works as it does, but it's better than sprinkling random millisecond delays all around the shop in the hope that they will work.

Anyway, just something for you to consider.

...because long ago I took them out

Were you delusional at the time or something? What an odd thing to do. People have been known to tear out their hair in expressions of grief, but I've never heard of anyone taking it out on keyboard shortcuts before.

[otlaolap]

Were you delusional at the time or something?

No. Long ago I wrote, and still use, a general keybord hotkey remapping tool for X2 and a general menu augmentation (replacement in my usage) tool for X2. The standard hotkeys and menu layouts make no sense to me, and so I wanted something much more metrical and logical to me. There were strange restrictions and limitations in what I could do with X2's customization at that time (maybe it has changed but I've not used it since). Any of the 3XXXX codes can be assigned to any keyboard key and any modifiers. I had forgotten that a side effect was that, even when I kill these tools for a testing session as I did here, I have overwritten X2's registry entries for hotkeys. Therefore my testing session with Ctrls, Alts, Shifts, and Cs, which I had thought was testing the native X2 hotkeys, was in fact running with my registry quirkery remaining.

I'll gladly experiment with the SendMessage suggestion and hope for a good result. (Already I'd tried a delay but after the SendMessage.)

[Kilmatead]

Any delay (in the interests of giving the modifiers time to kick in) should always be before the SendMessage, because your script won't actually continue until the WM_COMMAND has been processed. That's the way SendMessage works - if you don't want to wait for the message to complete before continuing you would use the API's PostMessage, which in this case wouldn't be of any use and would only cause more grief by potentially sending the keyup-releases before x2 even received the copy command in the first place. Welcome to the wonderful world of multitasking logic.

[otlaolap]

Things are working once again. The sleeps or the extra sendmessage sometimes seemed to help, but ultimately what was required was a change in my AutoHotkey script. Possibly sleeps and messages might have been enough to fully fix the problem, but I discoverd the following before completing the tests. I had been using the SendPlay function to send the modifiers. After looking at your C code, I changed SendPlay to SendEvent, which is described as much more a character-by-character operation rather than a buffered send of a whole series of characters (I've got the AHK source so I could look it up but haven't done so). The keys being sent are simply the modifier key-downs before the actual 3XXXX message and the modifier key-ups after the message. This now works with SendEvent, with no other changes (sleeps or messages or anything else). Since SendPlay used to work, I infer that AutoHotkey made an internal change at some point (it is farily often updated and I always fetch the updates) but that I never noticed the change until yesterday. I've retained, in comments, the extra sleeps and sendmessage to give me a tickle the next time this fails. Maybe I'll go back and put them in under the belts-and-braces philosopy. Posibly AHK has equivalent internal logic (its comments show a lot of attention to the real-world compensations needed to make Windows do what its users want).

Why do I care about 8.3 names? Because problems problems problems mumble mumble. I am trying to diagnose a problem in another program (a commercial one) that uses a command to start a target program, and I simply wanted to remove the possibility that a quoted target string containing a file name with spaces was causing the problem. So I thought I'd just plop in the 8.3 target instead and test it, but then . . . detour.

Tbanks again for your help here, and throughout the forum.