AutoHotkey Community

;=== BEGIN ScanStartMenu SUBROUTINE ...

After changing "Start Menu" to the term used in my language, the main problem seems, when the results of the dir command are written to file ">"

When opening the _Seek.list in "C:\Dokumente und Einstellungen\user-name\Lokale Einstellungen\Temp" you can see, that the special German chars cannot be displayed any more (a placeholder is there).

I think, this used technique is unfortunately not reliable (for non-English systems) and would need a complete workaround.

_________________
blackrat


Panoshots from Game-Screenshots

blackrat, I'm sorry this isn't working for you. I think you're right. The problem is probably caused by the 'dir' command of cmd.exe, which doesn't handle non-English unicode characters. The same thing happens when I try out on Chinese characters on my PC.

There is not going to be an easy solution to this. Besides finding an alternative method to properly output non-English characters from cmd.exe, AutoHotkey (and/or AutoIt) will also need to internally support non-ANSI character codes in the string manipulation functions. That will be a major overhaul. I'm not sure if this is part of Chris' todo list.

I think I would like it to support Unicode someday, perhaps as a separate version because otherwise I think non-Unicode users would see a large increase in memory and a reduction in performance. This is based on flimsy evidence since I have no real experience working with wide characters.

I will surely look forward to that day. With it, AutoHotkey will be able to reach international audience.

i use this script to search for my mp3s.

with a little change in the code i've added enhanced search. earlier typing 'michael' used to list 'michael jackson' and 'george michael' now if i want just 'george michael' then i'd have to delete and retype the search string to get 'george' before 'michael'... now i can just type 'mich geo' or 'michael geor' or 'geo mich' or any strings that appear anywhere in the path to get the correct results.

here's the code:



it can ofcourse be used in the same way for start menu searches.
the above searches the whole path and not just file name (helps me in searching for album name) but if u like it the old way then just remove the 'CurrentFile = %A_LoopReadLine%' line and replace 'IfNotInString, CurrentFile, %A_LoopField%' with 'IfNotInString, Name, %A_LoopField%'

this fuzzy searching could be a nice addition to the official seek.

_________________

Thanks Rajat for the good suggestion. I've added it to Seek. The next version will get this fuzzy-search feature.

This is an awesome script, I really like being able to search directories quickly and then being able to access it too. However, my first impression before I ran it was that it would activate the Programs menu, but disable the items that didn't match the query. I think something closer to a menu and less like an app would work better for me. It just seems a tad bit clunky right now. For me, the ideal would be something very close to Rajat's winamp script, except that it displays a menu with the results of the search. (Btw, good job on that rajat!) I'm going to start working on this a little bit myself, tell me if you think this is a good idea.

sure... go ahead! ...and i'd quite forgotten about posting that script (though i use it often).

_________________

Wow... after taking a closer, look, I'm totally at a loss of how to do that. I've never worked with GUIs in AHK before. My next self-assignment: read up on both gui's and menus, come up with a solution.

jonny, your approach is refreshing. Do post your script when it's ready. Can't wait to get a feel of how that really works.

I found that the dir command's output of characters from the Extended Character Set (ANSI) has a one-to-one translation to the same characterset in all but 29 characters.
These 29 are all in the range 80 to 9f; the 3 exceptions in that range being 83, 86 and 87.
I would not expect any of these 29 to be found in the dir command's output on my systeem, maybe with the exception of the Euro symbol.

So I wonder if e.g. German users might be helped with a function that converts the other 99 characters.
Personally I would like to have such a function, that given a string would return the string with any of those 99 extended chars converted and an error if not completely succesful.

Does something like that already exist?

Cheers

I don't know if I fully understand the goal, but there are two functions built into Windows that seem related:
These functions can be added if anyone can demonstrate a scripting use for them.

Also, it might be useful in some cases to copy a Unicode string to the clipboard, and then reference the clipboard as %clipboard%, which I believe translates Unicode to ANSI (to the extent that a mapping can be found).

The Seek script has a problem with file names that contain chars from the Extended Characters Set.
Should you have e.g. a directory named Übersicht then none of the files therein are accessable for Seek.
Seek (or every script that depends on the output of the DIR command) could use at least a partial work-around for e.g. German or French users.

A (partial) work-around could be that the script e.g. in case of "File not found" would use a function that checks if the full file path as returned by DIR contains extended chars and then if possible converts those to the proper chars.
In the case of Übersicht it would find the char 9A and convert it to char DC = Ü, according to the conversion table below.
(I created a file with a name consisting of all "extended chars" and this is what DIR made of it.)

It shows in red the chars that cannot be handled this way.

80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F

80 3F 3F 27 9F 22 2E C5 CE 5E 25 53 3C 4E 3E 5E 3F
90 3F 27 27 22 22 07 2D 2D 7E 54 73 3E 6F 3F 7F 59
A0 FF AD BD 9C CF BD DD F5 F9 B8 A6 AE AA F0 A9 EE
B0 F8 F1 FD FC EF E6 F4 FA F7 FB A7 AF AC AB F3 A8
C0 B7 B5 B6 C7 8E 8F 92 80 D4 90 D2 D3 DE D6 D7 D8
D0 D1 A5 E3 E0 E2 E5 99 9E 9D EB E9 EA 9A ED E8 E1
E0 85 A0 83 C6 84 86 91 87 8A 82 88 89 8D A1 8C 8B
F0 D0 A4 95 A2 93 E4 94 F6 9B 97 A3 96 81 EC E7 98

I'm new to scripting and could probably create such a function, but that might be far from optimal.
And, if I may be blunt, I would like to have such a function for AutoIt as well.
I'm pretty sure I could make the latter myself once I have the framework, though.

A better solution would be to have a function that provides the same functionality as DIR /b /s (and preferrably accepting multiple paths like the WinXP DIR) but without this extended chars problem.
For AutoIt I came across _FileSearch somewhere, but for searching a complete hd with many files it is (too) slow.

The best solution I guess for both AutoIt and AutoHotkey would be having a fast built-in function like that.

Assuming I understand the problem correctly, I think this all goes back to the lack of Unicode support in AutoHotkey. I believe NTFS is capable of storing Unicode characters. Perhaps I can alter the file-pattern loop so that Unicode filenames are retrieved in some other way, perhaps UTF-8.

Thanks for mentioning this issue because it has cropped up before and I'm beginning to believe it's a priority to fix it (if there's an easy way).

Well, the menu search idea is kind of hard to implement, I'm finding. Basically I'd have to re-write it from the top. While technically this shouldn't be too hard, I have no idea how to "extract" the code that does the actual searching. I didn't write the script, so it's much harder for me to see all the connections and references in it. At first glance, it seems like it is intimiately associated with the gui. If it wouldn't be too much trouble, could you write a segment that will simply search the directory(s) and output the content of it in a way that will allow me to make the menus? I'll be able to write the rest from that point. (I hope )