Open path of Unicode files not working properly

[nagan]

653b x 64 . Open path of Unicode files or files with unicode extensions open up only in My documents. I just checked 649b and it is the same.

[void]

Appears to work fine here, what is displayed in the debug output when you try to open a path?

Are you using a custom command for opening paths?

[nagan]

Code: Select all

load localization
load everything icon
create mutex
bookmarks
set hook
create tray
db_load
new thread (0)
_db_filesystem_add 0: 0, 002b6be0
_db_filesystem_add 1: 0, 002b6c40
_db_filesystem_add 2: 0, 002b6ca0
open volume \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963}
opened 668 0.000359
open volume \\?\Volume{4664a6b1-8fed-11e1-8c14-806e6f6e6963}
opened 668 0.000255
open volume \\?\Volume{1e20383c-a7d0-11e2-901b-dd8a203cfbaa}
opened 668 0.000240
WM_ACTIVATE 00000001 00000000, lastfocus 00000000, current focus 00000000
enter setfocus
leave setfocus
invalidate
enter main loop
loaded 0 of 0 changes in 0.001068 seconds
recent changes memory usage: 0 bytes
loaded 30 run history in 0.001043 seconds
run history memory usage: 132795 bytes
update filesystem C:
open volume \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963}
opened 688 0.000570
updated in 0.003000 seconds
update filesystem D:
open volume \\?\Volume{4664a6b1-8fed-11e1-8c14-806e6f6e6963}
opened 692 0.000617
updated in 0.001044 seconds
update filesystem F:
open volume \\?\Volume{1e20383c-a7d0-11e2-901b-dd8a203cfbaa}
opened 696 0.000703
updated in 0.001338 seconds
loaded db in 0.098081 seconds
_DB_WAIT: _db_load_successful_proc waiting...
_DB_WAIT: _db_load_successful_proc waited 0.000973 seconds
start all monitors (3)
open volume \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963}
search '' filter ''
opened 704 0.002810
term 04e88bc0, flags: 0140, next: 00000000, notnext: 00000000
folderop: 0, fileop: 0, term:
new thread (1)
open volume \\?\Volume{4664a6b1-8fed-11e1-8c14-806e6f6e6963}
opened 724 0.002126
found 47948 folders, size 394504, db search time taken: 0.000217 seconds
open volume \\?\Volume{1e20383c-a7d0-11e2-901b-dd8a203cfbaa}
opened 732 0.001089
waiting for 4 handles, isdelay 0...
found 239364 files, size 1970368, db search time taken: 0.001511 seconds
_DB_WAIT: db_get_selection_count waiting...
_DB_WAIT: db_get_selection_count waited 0.000445 seconds
new thread (2)
Updating \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963} (C:):
waiting for 3 handles, isdelay 0...
update filesystem C:
updated in 0.000109 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002929 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.000255 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002618 seconds
waiting for 4 handles, isdelay 0...
new thread (3)
Updating \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963} (C:):
waiting for 3 handles, isdelay 0...
_DB_WAIT: db_get_result_count waiting...
update filesystem C:
updated in 0.000126 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: db_get_result_count waited 0.005651 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.001182 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002804 seconds
waiting for 4 handles, isdelay 0...
Updating \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963} (C:):
waiting for 3 handles, isdelay 0...
update filesystem C:
updated in 0.000343 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002491 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.000853 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001849 seconds
selection: 1/1: D:\Name\Imageedit\for sorting\Sony\copied and sorted 05-07-11\T
ransfer 4\Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»ì Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»ì Ó«¬Ó»éÓ«®Ó»êÓ«òÓ»üÓ«ƒÓ»ìÓ«ƒÓ«┐.g
if
exec: first expr
exec: command $exec("%SystemRoot%\explorer.exe" /select,"%1")
exec: fullfilename D:\Name\Imageedit\for sorting\Sony\copied and sorted 05-07-1
1\Transfer 4\Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»ì Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»ì Ó«¬Ó»éÓ«®Ó»êÓ«òÓ»üÓ«ƒÓ»ìÓ«ƒÓ«
┐.gif
exec: depth 0
exec: exec "%SystemRoot%\explorer.exe" /select,"%1")
exec: depth 1
exec: got "%SystemRoot%\explorer.exe" /select,"D:\Name\Imageedit\for sorting\So
ny\copied and sorted 05-07-11\Transfer 4\Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»ì Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»ì Ó
«¬Ó»éÓ«®Ó»êÓ«òÓ»üÓ«ƒÓ»ìÓ«ƒÓ«┐.gif"
exec: expanded "C:\Windows\explorer.exe" /select,"D:\Name\Imageedit\for sorting
\Sony\copied and sorted 05-07-11\Transfer 4\Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»ì Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»
ì Ó«¬Ó»éÓ«®Ó»êÓ«òÓ»üÓ«ƒÓ»ìÓ«ƒÓ«┐.gif"
exec: shellexecute (idlist) file:C:\Windows\explorer.exe param:/select,"D:\Name
\Imageedit\for sorting\Sony\copied and sorted 05-07-11\Transfer 4\Ó««Ó«┐Ó«»Ó«¥Ó«
ÁÓ»ì Ó««Ó«┐Ó«»Ó«¥Ó«ÁÓ»ì Ó«¬Ó»éÓ«®Ó»êÓ«òÓ»üÓ«ƒÓ»ìÓ«ƒÓ«┐.gif"
Enter ShellExecuteExW
C:\Windows
waiting for 4 handles, isdelay 0...
Leave ShellExecuteExW
sub buf killed
set 1 run history in 0.000067 seconds
exec: main thread regained focus
Updating \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963} (C:):
waiting for 3 handles, isdelay 0...
update filesystem C:
updated in 0.000260 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002832 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.011082 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001527 seconds
WM_ACTIVATE 00000000 00000000, lastfocus 000b0a66, current focus 000b0a66
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.015434 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001293 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.025083 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002062 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.042154 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001693 seconds
waiting for 4 handles, isdelay 0...
Updating \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963} (C:):
waiting for 3 handles, isdelay 0...
update filesystem C:
updated in 0.000219 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.003787 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
waiting for 3 handles, isdelay 1...
updated in 0.000896 seconds
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001213 seconds
WM_ACTIVATE 00000001 00000000, lastfocus 000b0a66, current focus 00000000
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.000345 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002332 seconds
waiting for 4 handles, isdelay 0...
WM_ACTIVATE 00200000 00000000, lastfocus 001308c4, current focus 00000000
Updating \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963} (C:):
update filesystem C:
updated in 0.000167 seconds
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002116 seconds
waiting for 3 handles, isdelay 0...
waiting for 3 handles, isdelay 1...
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.000343 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001013 seconds
waiting for 4 handles, isdelay 0...
Updating \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963} (C:):
update filesystem C:
waiting for 3 handles, isdelay 0...
waiting for 3 handles, isdelay 1...
updated in 0.003928 seconds
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001343 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.000042 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001328 seconds
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.000864 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002614 seconds
waiting for 4 handles, isdelay 0...
Updating \\?\Volume{4664a6b0-8fed-11e1-8c14-806e6f6e6963} (C:):
update filesystem C:
updated in 0.000033 seconds
waiting for 3 handles, isdelay 0...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.001337 seconds
waiting for 3 handles, isdelay 1...
DeviceIoControl already complete (C:)!
waiting for 3 handles, isdelay 1...
update filesystem C:
updated in 0.000060 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: _db_ready_proc waiting...
_DB_WAIT: _db_ready_proc waited 0.002606 seconds
waiting for 4 handles, isdelay 0...

[nagan]

649b and 653b x 86 work well in x86 environ.

[nagan]

Strangely شوف القمر.gif is supported but not மியாவ் மியாவ் பூனைகுட்டி.gif though on double click both files open

EDIT Uploaded the files

[void]

This is an issue with Explorer, I get the same problem from start -> run and other programs.

A work around would be to set the command for open path to:

Code: Select all

$exec("$parent(%1)")

[nagan]

There is a downside. The files are no longer highlighted. Also do you mean Explorer discriminated between languages?

EDIT Also tried with duplicate cleaner with similar folder tracking features. One language works fine ,but not the other. Strange explorer issue....

[void]

It appears Explorer doesn't parse the வ் character correctly.

[everythinguare]

Hi

Sorry to dig up this OLD thread,

However, does anyone find another better solution for this?

I mean it's working when I change it to $exec("$parent /select, %1"),
but just like the OP describe, it does NOT HILIGHT or Directly Select that file or folder, I have to select it manually.

As "void" describe, the problem looks like from the "EXPLORER" itself, which it may be yes.
However, I have tried using Everything on Windows XP (32 bits), and problem does NOT occur.
In another words, the problem is only happen on Windows 7 (both 32 & 64 bits).

So maybe you're right that it's something to do with the Windows or Explorer itself especially for Windows 7.

However, I hope you can find the other workarounds for this Unicode, double click path issue to be working more properly (including HILIGHT OR Directly Selected to the searched folder or file)

BTW, my asian language is Thai (country is Thailand)
If you need more info or any other log in order for you to debug it,
please do not hesitate me asking to me provide it for you.

ps. actually I know this problem for quite a long time since using Windows 7 and thought it was only me, until recently I got Everything update Notification, and then I upgrade, but
Coincidentally, I just found ONLY this thread that exactly similar to my problem. So I dig this thread up just in case someone or Admin can put better solutions or workarounds for this.

Thank you so much,

[therube]

See also, The system cannot find the file specified.

Translated, The system can not find the file specified

[everythinguare]

Over 2 years, but I still can't find the solution.

Any update here?

[everythinguare]

Sorry to BUMP this topic again,

but Is there any Solution for this, yet? Now I'm on the latest beta version 1.4.0.709b.

Again
1)while I am searching for the "file(s)" in some folders.
---Result comes up
2)I DO NOT want to open a files, INSTEAD I want to open those Folders contain those files (that shown in the result window),
so I "Double Click" in the "Path" column, AND yes it opened those FOLDERs (paths) correctly.

HOWEVER, if in the path contain any "UNICODE" character (for me is "THAI" characters), those opened folders are not correct,
INSTEAD, it ALWAYS open "C:\Users\xxx" where "xxx" is the username on my computer. And I don't want that.

For example,
If I search for "love", then 2 results come up.
1)Name -> I love you (file)
Path -> c:\abc\xyz
when I double click the "result path" in the Path column, it open the correct folder
-> ACCURATE

2)Name -> I love you so much (file)
Path -> c:\abc\xyz
when I double click the "result path" in the Path column, it ALWAYs open the "C:\Users\xxx" where "xxx" is the username on my computer
-> IN-ACCURATE

Please help me on this issue, Otherwise I have to right click on the file name and choose "M:\+ZZZZZ PEND - 1\SexArt - Silvie Deluxe 'I'm Here For Love'",
then open the "Explorer.exe" then paste the path in the address bar, then press "Enter" button.

The above workaround is so TEDIOUS.

FYI, it's working correctly (even there is a "Thai" character (Unicode) in the the "Path" on Windows XP, but NOT working AT ALL on Windows 7 (both 32 & 64 bits).

I'm still looking forward on how to make this "Double click" to re-direct me to the correct "PATH"

Thank you so much for the help!!

[void]

Please try changing the open path command:

In "Everything", from the Tools menu, click Options.

• Click the Context menu tab.
• Select Open Path
• Change command to:

  Code: Select all

  $exec("$parent(%1)")

Does this help?

[therube]

Note that while the (default) Open Patch command does not work, you can use 'Copy Path to Clipboard' (either by context menu or Keyboard Shortcut ) & use that to paste elsewhere.

Still a work-around, but it might make it easier.

(I use that a lot when I run into Long Full File Name [> 260 or so char] related issues.)

[everythinguare]

Hi,

Thanks "void" for the help, but the solution you just suggested are the same one you had suggested in the earlier post in this topic (about 2 years ago), and I had tried at that time (for the earlier version), and try it now, but the result are still the same. I mean it's working ("double click" go to the CORRECT path), but it has a drawback like "nagan" described earlier (2 years ago).

The file OR folder AFTER the path had been opened are NO LONGER highlighted. Please see the difference between the 2 images below.

CORRECT


WRONG


Actually, It's not difficult to find IF those searched file OR folder within that path are not that many,
but if that path has lots of (similar) files or folders name, it would take some more time to find the "searched file OR folder" in that path.


Thanks "therube", actually I have done that since for quite sometimes as a workaround like you said, but yeah it's still take more time than just "double click" and yeah, open that path & highlight the "searched file or folder" like how it should be.


Again, this is only happen for the path that contain "UNICODE" name in it, don't know for other languages (but it's a problem for a "THAI" characters, and also for the path (with or without) unicode character that has a very long file name in path like "therube" described in above post.


So, now I can only use this workaround, but I really hope this problem can be fixed finally, that would be a huge saving time for me. Yeah, actually "Everything" software has been saving my time of my life for many years already, and if this problem has been fixed (hope very soon) lol, it would be a great news for me indeed.


Thank you so much, I will wait for a fix anyway, but please have a rest too. I see you both have been very active in this forum (website) and have helped many people here for a very long time.

You guys have done very glorious works.

!!CHEERS!!

[void]

The current problem lies with Windows Explorer not parsing the /select parameter correctly.

Does the right click context menu show correctly for a file in Everything that will not open correctly with Explorer?
I'm just wondering if Everything is creating a valid PIDL for the file....

If it does work, I will look into implementing SHOpenFolderAndSelectItems which will fix the problem.

Could you please post an example path with a Thai character that is giving you trouble so I can test the issue?

[therube]

Using Nagan's filename, it appears the context menu is correct.
Expected items work as wanted, including those found in Send To & Open With.

Everything Unicode Filename Open Path Context Menu.png (19.1 KiB) Viewed 15196 times

[void]

I've added the $openpath() command for the next beta update. This command will use SHOpenFolderAndSelectItems which fixes the issue.
If SHOpenFolderAndSelectItems is not available or fails, $exec(parent("%1")) is used.

$openpath("%1") will now be the default command for opening paths.
The parent folder of %1 is opened with the default file browser.
%1 is the full path and file name of the file to be selected.

[everythinguare]

Hi, void

The right click context "Copy Path to Clipboard" is always CORRECT (does NOT matter whether or not if the "searched" (file OR folder) contain Unicode (Thai) or just plain English character.

Also, I have done some experiment and I've found something that might be useful for you in order to fix it.
OK, I can tell you here before you see the images below, so it's easier to follow.
What I've found is .... IF & ONLY IF "files OR folders" which are shown in "Name" OR "Path" column that contain UNICODE character(s) that stay ABOVE or UNDER the Unicode character, then BOOM problem appears!!.

for example,
WORKING GOOD --> สวยมาก really
WORKING GOOD --> yummy หอมหวาน
WORKING GOOD --> ปากกา pencil ยางลบ

PROBLEM --> วันนี้ weather is cold
PROBLEM --> perfect ถูกต้อง สุดๆ
PROBLEM --> กุญแจ pen เก้าอี้

as you can see from the above,
WORKING GOOD --> will have NO character "ABOVE" or "UNDER" another character
PROBLEM --> will HAVE 1 or more character "ABOVE" or "UNDER" another character

IMAGEs

1)I made 2 Folders

Folder 1


Folder 2


2)If I search for the word "ค้นหา" --> yeah there is some character ABOVE another character, then you guess what all 4 results (2 folders & 2 files), when I double click in any path (from those 4 results), it ALWAYS (re-direct) & OPENs C:\Users\xxx where "xxx" is PC's username


3If I search for the word "ทดสอบ", from the image below, I'm sure you can guess which one (out of 4 results) can open the "Correct" path.
Answer:The 2nd & 4th opened the "CORRECT" path,
but 1st & 3rd opened the "WRONG" path, BECAUSE there is some UNICODE characters "ABOVE" another character.


---------------------------------------------------
Additionally,
Is there anyway to sort results by the "PATH" which do not make the "folders" come before "files"?
I mean if you see in all the images above you may can see that, I sort by "Path" not "Name", however, "Folders" are ALWAYS on TOP, then followed by "Files" (ignored the "file extensions")


I hope, I've provided you a bit regarding to the problem about "Double Click to open the folder which contain UNICODE (specifically UNICODE character "ABOVE" another character).


CHEERS!!


EDIT:oops I just saw you might already put some fix (work-around) on the next beta version already. Anyway I hope to help something from this post, and I really want to try the next beta version very soon.

[void]

If you would like to test the new SHOpenFolderAndSelectItems method, please try the unofficial Everything 1.4.0.710b update:
http://www.voidtools.com/Everything-1.4.0.710b.x86.zip
http://www.voidtools.com/Everything-1.4.0.710b.x64.zip

Please make sure you reset your context menu items to use the new SHOpenFolderAndSelectItems method:

• In Everything, from the Tools menu, click Options.
• Click the Context menu tab.
• Click Restore defaults.
• Click OK.

-or-

Set the open path command to:

Code: Select all

$openpath("%1")

[everythinguare]

Hi,

Thanks, void, for the the beta version, I've just tried it. I've tried double click in path for some file/folder, it appears to working correctly (Go to that path/folder, and "Highlight" that file/folder.

However, in some case (which I don't know why) it just go to the correct path/folder, but it still does NOT highlight that file/folder.

I still cannot figure it out what causes it to be sometimes highlight, and sometimes it doesn't because all I've tried, there are "unicode characters" and/or in "file's name", "path/folder's name".


EDIT:
oh, after I've tried to noticed what it cause, finally I know it.

Actually, now the "UNICODE" problem regarding to "double click in path" feature is now all SOLVED for the beta you gave me to test.

However, if the "Path" including "file's name"+"file extension" is GREATER THAN 256 character (with/without UNICODE character), "double click in path" will still work but, NO longer highlight that "file/folder" after go in that path/folder.

for example,

TOTAL characters = Path + File's name + File Extension

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
=256 characters --> file/folder is still highlighted

C:\ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..\abcdexy.txt

C:\ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..\ทดสอบนะ.txt

C:\ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..\abcdefghijk

C:\ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..\abcdefทดสอบ

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

=257 charcters --> file is no longer hightlighted

C:\ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..\abcdexyz.txt

C:\ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..\ทดสอบxyz.txt

C:\ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..\abcdefghijkX

C:\ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..ทดสอบอีกครั้งนะจะบอกให้..\abcdefทดสอบX

BTW, thank you so much for the quick fix about UNICODE problem,
You are very kind.

!!CHEERS!!

[void]

However, in some case (which I don't know why) it just go to the correct path/folder, but it still does NOT highlight that file/folder.

I've noticed this too.
The issue appears to be with Explorer.
It occurs more often when the opened folder contains many files.
Closing the Explorer window and reopening it with Everything appears to select the desired file..
I'm assuming that if Explorer takes more than 1 second to gather all the files for the folder it gives up on selecting the desired file.

=257 charcters --> file is no longer hightlighted

This is a limitation with the Windows Shell, nothing I can do about it, sorry.

[everythinguare]

Sorry to bump this post again after nearly 2 years,

But I'm so sorry to say, that for quite sometimes (I actually do not know from since version), it doesn't work again.

I mean, for the Default value in "Open Path" context menu -> $openpath("%1")
it's go to the correct path whether or not the path(or file's name) has the "UNICODE" characters in it,
but it does NOT HILIGHT the file name after go to that path.

However, when I change the value in the "Open Path" context menu to -> $exec("%SystemRoot%\explorer.exe" /n,/e,/select,"%1")
It DOES HILIGHT the file name after go to that path,
but it does NOT WORK if there is any "UNICODE" characters in those path or file's name.
I mean it always direct me to the "C:\Users\xxx\" where "xxx" is my Username of this computer, instead of the shown path in the result.

Could you please help me out again to see what's has happened since last 2 years.

Thank you so much