get full paths of selected files on Desktop and Common File Dialogs

Get help with using AutoHotkey and its commands and hotkeys
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

get full paths of selected files on Desktop and Common File Dialogs

28 Apr 2017, 23:58

[UPDATE:]

Common Item Dialog (Windows)
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx
Starting with Windows Vista, the Common Item Dialog supersedes the older Common File Dialog when used to open or save a file.

For the Common File Dialog:
CDM_FIRST := 0x464
CDM_GETSPEC := 0x464 ;focused item get name
CDM_GETFILEPATH := 0x465 ;focused item get path
CDM_GETFOLDERPATH := 0x466 ;get folder
CDM_GETFOLDERIDLIST := 0x467 ;get folder ID for special folders e.g. 'Computer'

For the Common Item Dialog:
[script by qwerty12:]
get full paths of selected files on Desktop and Common File Dialogs - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=31135&p=145577#p145577
[notes by jeeswg:]
get full paths of selected files on Desktop and Common File Dialogs - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=31135&p=145883#p145883

[a simple approach:]
get full paths of selected files on Desktop and Common File Dialogs - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=31135&p=165840#p165840

To get files from desktop:
Explorer interaction (folder windows/Desktop, file/folder enumeration/selection/navigation/creation) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=35041
- On older systems (Windows XP and older I believe), you may be able to use window messages to retrieve information from the Desktop listview control, including PIDLs, and convert those PIDLs to file paths. This PIDL method may also to apply to listview controls in Common File Dialogs on older systems.

==================================================

It appears that PIDLs may provide a way to obtain the full paths of selected files on Desktop and Common File Dialogs. Any help with this would be most appreciated. It involves WM_USER+7 (0x407) and IShellView.

What I have found out so far:

==================================================

c++ - Obtain the true name of the currently select file in the common file dialog? - Stack Overflow
http://stackoverflow.com/questions/1757093/obtain-the-true-name-of-the-currently-select-file-in-the-common-file-dialog

We used to rely upon the fact that the Windows 9x, 2000, and XP version of the common file dialog stored each item's PIDL in the LVITEM data (original credit to Paul DiLascia):

Send WM_USER+7 to get the browser, and then get its active shell view's IShellView interface.


==================================================

[the page above has a link to this:]
How to change a current directory from a CFileDialog-based class after the call to DoModal()?
https://social.msdn.microsoft.com/Forums/vstudio/en-US/30cf16d3-d4a5-4feb-9031-35cfbc669998/how-to-change-a-current-directory-from-a-cfiledialogbased-class-after-the-call-to-domodal?forum=vcgeneral

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



The only minor problem - like one can see from comments - is that the call to BrowseObject() returns S_FALSE, despite that works fine.
Why? Any misunderstanding on my side regarding flags definition, or something else?

use SUCCEEDED(hr) or FAILED(hr) to determine success or failure. Error codes generally begins with E_.


==================================================

[a similar question]
c# - Get PIDL's of items in GetOpenFileName dialog - Stack Overflow
http://stackoverflow.com/questions/5369349/get-pidls-of-items-in-getopenfilename-dialog

Thanks for reading.

[EDIT:] Btw I was also having difficulty trying to navigate to a PIDL e.g. via Navigate2. Which I thought may be a possible solution to this problem, relating to navigating to folders that contain hashes:
4 options to change the current folder in Windows Explorer - Page 3 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=526&start=40

Note: there is code here to convert a path to a PIDL:
SHMultiFileProperties - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=30483&p=145200#p145200

==================================================

[EDIT:]
[This link mentions 'WM_GETISHELLBROWSER', which may be an unofficial name for the message.]
How to change location of Open Save Dialog (COMDLG32) cwith DllCall? - Ask for Help - AutoHotkey Community
https://autohotkey.com/board/topic/91096-how-to-change-location-of-open-save-dialog-comdlg32-cwith-dllcall/

There is a way to control the file dialog without sending keystrokes, messages or mouse clicks - it involves sending an undocumented message (WM_GETISHELLBROWSER = 0x407) to the dialog and using the IShellBrowser interface pointer which it returns. This will completely fail with dialogs which were created by some other process. That can be worked around by injecting code into the process which owns the dialog, but that cannot be done with AutoHotkey alone.


[It turns out I'd found out some of this information before, regarding a related but separate issue. Although this time around I found out some additional information, and everything makes much more sense.]
get/set path of external Common Item Dialog possible? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=28603
Last edited by jeeswg on 22 Aug 2017, 22:21, edited 6 times in total.
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: get full paths of selected files on Desktop and Common File Dialogs

30 Apr 2017, 20:30

jeeswg wrote:It appears that PIDLs may provide a way to obtain the full paths of selected files on Desktop and Common File Dialogs. Any help with this would be most appreciated. It involves WM_USER+7 (0x407) and IShellView.


For file selection common file dialogs, you can try this:

Code: [Select all] [Expand] [Download] (Untitled.ahk)GeSHi © Codebox Plus



It works from a 64-bit AutoHotkey process to a 64-bit process and from a 32-bit AutoHotkey process to a 32-bit one.Mixing the two isn't possible (at least with this, and I don't care to try anything different to make it possible). I'm not interested in other options personally, but using TCC isn't the only option; you could use InjectAhkDll to load AutoHotkey_H into the remote process and do kinda the same thing. If you need to get results from a 32-bit process from a 64-bit AutoHotkey, then do something like spawning AutoHotkeyU32 and finding some suitable from of IPC to get the filenames out of there back to your first script.

I tested with what you linked: https://gist.github.com/BiggerDigger/69 ... 4d2263867e

Drop tcc.dll from tcc-0.9.26-win32-bin.zip/tcc-0.9.26-win64-bin.zip into the same folder as the script. The C code is shittily written (something I'll mostly blame on me being silly enough to redefine the WinAPI... :/) and there might be memory leaks in the remote process (although, AFAICT, I do clean everything up).

It works by using TCC to compile a function that does the SendMessage in the context of the process to get an IShellView that can actually be worked on. From there, the filenames are obtained and stored. Once the function returns, the AutoHotkey script reads the memory of remote process to get the filenames.
Last edited by qwerty12 on 01 May 2017, 11:33, edited 1 time in total.
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

30 Apr 2017, 20:39

Cheers qwerty12, I thought this might be your area of expertise, thanks so much for this, I'll test it quite soon. I was under the impression that this would fail for external programs, unless you used dll injection, or does TCC use dll injection?

It could also be useful for dialogs created in AutoHotkey. One thing though, I don't know if this method will help with getting the full paths of selected files on Desktop.

==================================================

[EDIT:] Here is a link to some related areas of code, that may be of interest to you.
get a process's GDI handles (e.g. get/set title bar font and apply WM_SETFONT to a control) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=31228
c++ - How to get list of GDI handles - Stack Overflow
http://stackoverflow.com/questions/13905661/how-to-get-list-of-gdi-handles
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: get full paths of selected files on Desktop and Common File Dialogs

30 Apr 2017, 21:03

jeeswg wrote:Cheers qwerty12, I thought this might be your area of expertise, thanks so much for this, I'll test it quite soon. I was under the impression that this would fail for external programs, unless you used dll injection, or does TCC use dll injection?


Yes, you're right, this would fail for external programs - sure, you can SendMessage WM_USER + 7 to an external file dialog window fine, but the address returned is not going to make any sense in the context of your program...

So this uses TCC to compile a C function and then using WriteProcessMemory to write the resulting assembled function into the external process. DLL injection would be far, far easier - I'm copying raw functions that do not know where anything else is, hence me using AutoHotkey to get the library function address beforehand and shoving them into the C code TCC compiles and allocating space for a struct that contains data I need to share between the two compiled functions.

If you were to inject a DLL to do it, I'd look at HotKeyIt's AutoHotkey_H dll - the syntax is the same, which helps immensely... I used TCC because I don't fully understand how to use AHK.dll and I'm too lazy to look at the documentation, and because with TCC, you don't actually need a full blown compiler setup to change what the compiled code does. Think of it as MCode but the mcode is compiled on the fly.

One thing though, I don't know if this method will help with getting the full paths of selected files on Desktop.


Probably not. I was careful enough to only say "for file selection common file dialogs". ;)

Here is a link to some related areas of code, that may be of interest to you


Interesting links, thanks. Your conversion would be good to see :thumbup:. Incidentally enough, Chrome keeps crashing here because I think it's approached the desktop heap limit... :\

EDIT: I knew there was already code out there to get the names of selected desktop items: https://autohotkey.com/board/topic/6098 ... er-window/
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

01 May 2017, 23:04

That script to get selected Desktop items has several drawbacks, comments lower down. Btw LOL at big text.

- My PC is x64, I created a folder with AHK x64 (latest version, renamed it to AutoHotkey.exe to match the script), CommonItemDialog.ahk, your script, libtcc.dll (x64 version).
- I had CommonItemDialog.ahk open at the Select File(s) dialog.
- I added a line to confirm WinExist had found an hWnd.
- The code looks amazing, but unfortunately it wasn't working, I put a MsgBox just before the ExitApp line, which was triggered.
- I presume that when it is working it lists each file individually in a MsgBox.
[EDIT: I made sure to open both ahk files with the AutoHotkey.exe that was in the same folder.]
[EDIT: also, select some files.]
[EDIT: at the time of writing, the script only works if the Common Item Dialog is displaying the contents of the Desktop folder, but this may change if qwerty12 updates the script in future.]

Btw are these the recommended safe links for TCC?
TCC : Tiny C Compiler
https://bellard.org/tcc/
Index of /releases/tinycc/
http://download.savannah.gnu.org/releases/tinycc/

Btw, also, it appears that CommonItemDialog.ahk is actually opening the new (Windows Vista and after) Common File Dialog. Also, I had believed that this technique would work only with the old-style Common Item Dialog prompt.

==================================================

Desktop paths.

On Windows XP and 7, Desktop uses a listview, and the old Common Item Dialog's used a listview. Apparently in Windows XP and earlier, in each listview item's LVITEM structure, in the lParam, were PIDLs which could be used to retrieve the full paths for those listview items.

[EDIT:] You would use LVM_GETITEM, you prepare an LVITEM struct, with details of which item to get information for, and what information to get (e.g. LVIF_PARAM := 0x4), send the message, the LVITEM struct is updated, and then you can retrieve the PIDL from the lParam parameter. You'd also need the classic 6 dll functions: OpenProcess,VirtualAllocEx,WriteProcessMemory,ReadProcessMemory,VirtualFreeEx,CloseHandle.

It looks like now, that a method using objects may work for the old Common Item Dialog, but so far, no news on Desktop items. Does the Desktop on Windows 10 still use a listview (where if you press End it selects the wrong icon, because items are added 'by columns', but the last icon is determined 'by rows').

Anyhow, the best solution I have so far is based on listing all the full paths and display names for Desktop files and retrieving the display names for selected Desktop files, and checking in case there is more than one file with the same display name.

Btw the script you linked to, I believe depends on extensions being shown, plus lnk files for example always hide extensions (and dll files always show extensions).

(will post code ...)
[EDIT:] Here's the code:

It uses the display name and type name, that can be retrieved from the listview. The main difficulty is ambiguous filenames, e.g. with extensions hidden, 'MyFile.log' and 'MyFile.txt', have the same display name, 'MyFile', and the same type name, 'Text Document'. If for example, there are exactly 3 files with a particular Name/Type combination, if none or all of those files are selected, the function can proceed, otherwise the function fails, because we can't be sure which files were selected.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

Last edited by jeeswg on 02 May 2017, 16:09, edited 7 times in total.
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: get full paths of selected files on Desktop and Common File Dialogs

01 May 2017, 23:31

jeeswg wrote:Btw LOL at big text.


Sorry, it's just I was thinking "I'm sure I've seen something like that in the past" and then I saw a post on this forum with what I was thinking of and was surprised...

- The code looks amazing, but unfortunately it wasn't working, I put a MsgBox just before the ExitApp line, which was triggered.


At the risk of sounding like an idiot, especially when it seems like you got everything correct, did you actually highlight a bunch of files? The script isn't very descriptive when it comes to error messages, sorry (the script used to show AutoHotkey exception messages when a throw was hit - but I somehow messed that up). Also, for some reason, it doesn't work when started in some folders - I've had success running from my Desktop and Downloads folder.

I'll set up a Windows 7 x64 VM soon to see if I'm relying on behaviour specific to my Windows 10 system.

But you're not missing out on much, TBH - see below:

- I presume that when it is working it lists each file individually in a MsgBox.


Yes, but I also messed that up - SHGetPathFromIDListW returns the correct filename indeed, but with %A_Desktop% as the path, even when the files are not on the desktop... I didn't notice before because I was only testing with files on the desktop... :oops: I'll try and fix it to use the proper COM interface methods instead of taking shortcuts :(

Btw are these the recommended safe links for TCC?


Yessir

Btw, also, it appears that CommonItemDialog.ahk is actually opening the new (Windows Vista and after) Common File Dialog. Also, I had believed that this technique would work only with the old-style Common Item Dialog prompt.


Don't quote me on this, but while I don't know how, IIRC it's easier to do for the old dialog box.

Desktop paths.

Does the Desktop on Windows 10 still use a listview (where if you press End it selects the wrong icon, because items are added 'by columns', but the last icon is determined 'by rows'.


Presumably so - the script from the old forum still works here

Anyhow, the best solution I have so far is based on listing all the full paths and display names for Desktop files and retrieving the display names for selected Desktop files, and checking in case there is more than one file with the same display name.


That sounds good - will be very interested to see.

Btw the script you linked to, I believe depends on extensions being shown, plus lnk files for example always hide extensions (and dll files always show extensions).


You raise a good point - as I always keep extensions turned on, it's not something I thought of.

https://blogs.msdn.microsoft.com/oldnew ... 0/?p=93535 might be what you're after.
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

01 May 2017, 23:38

You were right about selecting files, I didn't have any selected, although in my defence, I might want this to list all files, not just selected files. Unfortunately it still didn't work after I selected some files. HOWEVER, I navigated to Desktop, and tried it, and your script *did* work, so thanks again qwerty12. (Tested on Windows 7 x64.)

Yes I'm glad I listed all the steps I took to test this script, because it was quite easy to slip up.

[EDIT:] Woah, read your link, does that mean there's an object approach to retrieve the selected files from the Desktop after all?
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: get full paths of selected files on Desktop and Common File Dialogs

02 May 2017, 00:14

jeeswg wrote:although in my defence, I might want this to list all files, not just selected files. Unfortunately it still didn't work after I selected some files.


You raise a good point. After I fix getting the correct path returned, what I'll do is if there are no files selected, the path of the open folder will be returned instead - if you want to know what files are in there, you can do that from AutoHotkey anyway. As for it still not working, that's not good indeed. I'll definitely give it a whirl under Windows 7.

[EDIT:] Woah, read your link, does that mean there's an object approach to retrieve the selected files from the Desktop after all?


Yes, kinda - I just tried out the program. It doesn't return the selected files, but rather the path of the focused item (you can select multiple files, but the last selected file is likely to be the one with focus). Saying that, now that we have a IShellFolder for the actual desktop, getting the selected items' paths can be done in the same way it's done in my script - just without the messy remote code injection...
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

02 May 2017, 00:41

Just to be clear, when I navigated in the dialog prompt to Desktop, and selected some files, the script did work.

Haha good point, about listing *all* the files, just use an AutoHotkey file loop. Although, it might be a special folder. Btw, being able to get the folder/special folder of a dialog prompt, is as important as getting the focused/selected/all files.

When I read that Raymond Chen link and it said *focused* file, I thought that most likely it would only need a little modification to get the selected files instead. Reliably getting a list of selected files on Desktop, without using the clipboard, has been a key AHK desire for a long time. I'm surprised nobody mentioned the PIDL method (for older OSes), on the older forums, although I may have missed it (and maybe there were some problems I don't know about).

If you do ctrl+arrow keys on Desktop, the focused file is not necessarily selected.

[EDIT:] I added my 'desktop get selected files' function above.
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: get full paths of selected files on Desktop and Common File Dialogs

02 May 2017, 15:16

jeeswg wrote:Btw, being able to get the folder/special folder of a dialog prompt, is as important as getting the focused/selected/all files.


For special folders, you should get the GUID back. I'll leave interpreting it up to you back in the script; the injected function is quite large already.

I added my 'desktop get selected files' function above.


Thanks for the code - I had a similar idea in mind, but no idea how to do it in code.

For selected desktop items, try this: - https://autohotkey.com/boards/viewtopic.php?t=9618 is easier

Spoiler


as for getting the path/selected items from common item dialogs, try this revised version of the script:

Code: [Select all] [Expand] [Download] (SelectedFileNames.ahk)GeSHi © Codebox Plus



If nothing's selected, the path of the folder is returned instead; else, you should hopefully get back the full paths of selected items. You can force the retrieval of the folder path regardless of whether anything is selected by uncommenting the "NumPut(True" line.

I tried in WIndows 7 64-bit SP1 on a CID open in Chrome and I was successful on my first attempt: Image
Last edited by qwerty12 on 09 Jun 2017, 07:25, edited 3 times in total.
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

02 May 2017, 15:59

qwerty12, this 'desktop get selected files' script of yours is absolutely amazing, cheers.

In summary, I'm interested in get/set, selected 'listview' items/navigated-to folder or 'folder'/file in Edit control, for Common File Dialogs/Common Item Dialogs, that are internal/external to the AHK script. Which it seems you have collected most/all of the techniques for.

Other issues I plan to return to:
- My Notepad replacement 'notify of file selection' issue, for both Common File Dialogs and Common Item Dialogs.
- If a script can be significantly simplified for internal dialogs only, to make a separate simplified script for it.
- The get GDI handles script.
- Explorer windows: set which columns are displayed, change the left/right column order, and set columns to ascending/descending order. Although one workaround is that the Acc library can be used to click on a column header to trigger a sort.

I'm going to have to spend a good deal of time going over your scripts. Possibly in a month's time, because I've got a lot I need to finish.

Btw how did you come across the Desktop link, and have you got any other object-and-Explorer or object scripts in mind to do? Thanks again.
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: get full paths of selected files on Desktop and Common File Dialogs

02 May 2017, 17:47

jeeswg wrote:- If a script can be significantly simplified for internal dialogs only, to make a separate simplified script for it.


For internal dialogs, it's probably easier to just use the actual file dialog APIs.

Btw how did you come across the Desktop link


Just a Google search

and have you got any other object-and-Explorer or object scripts in mind to do? Thanks again.


No, I don't really know what I'm doing here - these are just (mostly) AutoHotkey versions of the code found on Raymond Chen's blog...
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

20 Jun 2017, 00:32

@qwerty12: I've made a few small edits and wrapped up your code for getting the paths of files on Desktop as a function:

I've:
- brought out the curly brackets from the ends of lines
- replaced 'path' with 'vPath' so that the function will work without #NoEnv being set
- made it add all the paths to a variable
- prepared a variable with sufficient capacity in advance, by using ControlGet on the Desktop listview
- given the user the option of what separator string to use

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



[EDIT:] Btw re. libtcc.dll, you might be interested in creating machine code functions instead, see:
InBuf function currently 32-bit only (machine code binary buffer searching) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=28393
Last edited by jeeswg on 20 Jun 2017, 05:54, edited 1 time in total.
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: get full paths of selected files on Desktop and Common File Dialogs

20 Jun 2017, 05:51

jeeswg wrote:@qwerty12: I've made a few small edits and wrapped up your code for getting the paths of files on Desktop as a function:


Very useful edits, thank you, but while writing this, I came across this post of Lexikos'. I found out then that you could get the selected names on the desktop through an IDispatch interface, which is far easier... I didn't bump this thread (not my style), but I did edit my previous post in this thread with a link to Lexikos' post: "Last edited by qwerty12 on 09 Jun 2017, 13:25, edited 3 times in total."

- prepared a variable with sufficient capacity in advance, by using ControlGet on the Desktop listview


I see what you're doing and I like it, but I think you're missing the use of the vCount variable in your VarSetCapacity line.


I see you edited your post before I had a chance to post this :-)

[EDIT:] Btw re. libtcc.dll, you might be interested in creating machine code functions instead, see:
InBuf function currently 32-bit only (machine code binary buffer searching) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=28393


MCode wouldn't be the right approach here: it's the same as what I'm already doing, except that currently the C code is in the AHK script itself (bastardised as it is) as opposed to a bunch of base64-encoded opcodes (and I know what I far prefer seeing). I also don't get the benefit of being able to use AHK as a preprocessor, which is extremely important because SetWindowsHookEx doesn't provide a way of passing an arbitrary pointer to the callback function; this is why I allocate the memory for the threadData struct in the remote process first - I then have an address I can hardcode into the compiled code. It's also nicer to be able to hardcode the address for functions instead of saving them into the threadData struct and then getting the C code to look them up out of the struct.

If you want to supply code that's already compiled (it is true that MSVC or GCC will produce far more optimised code than TCC), it would be far, far easier to just compile it into a DLL, with its fancy features like dedicated memory for global variables, and just share that, using AutoHotkey to load that into the remote process.
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

20 Jun 2017, 06:12

That Lexikos script looks great, I will try and adapt it for listing files on Desktop. I had wondered if there was a more direct way to get access to the interface, I don't really know much about what starting point object to use, and then the quickest route to get the desired interface, i.e. 'hopping' between interfaces.

I've added vCount to the VarSetCapacity line now, cheers for pointing it out, I hadn't noticed. (In my defence, the script works without it!)

Re. the Common File Dialog script. I'd be tempted to create two versions: a machine code version (no additional files needed) and a dll required version if it is superior in some way. Although from what you're saying it sounds like you do need the dll in this case. You're right that it's better to have the C/C++ code, although, you could just use machine code *and* include it in the script as comments, and/or add a link to it, possibly with some details, e.g. 1/2 lines, of how you converted the C/C++ code to the machine code.

[EDIT:] It's always a major advantage for scripts, whenever they: don't require external files, don't require Admin mode, don't require dll injection (or multithreading?) (i.e. require AutoHotkey_H), and are written to be as compatible as possible, requiring minimal or no changes to work in other older/newer AHK versions.

Cheers, I think at least twice I've had it reported in my feed that you made updates to posts in threads I've been in. I checked the posts, and I couldn't tell what had changed. So maybe if you use '[EDIT] / [EDIT:] / EDIT / EDIT: / edit / edit:' or something like that, I could tell. Btw is there some special way to 'bump' a post without changing it!?

I'll be going over all posts that feature both me and you at some point ... it will be interesting.
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

20 Jun 2017, 06:45

FindWindowSW line based on code by Lexikos here:
Create new file in current explorer window? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=9618&p=53361#p53361

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: get full paths of selected files on Desktop and Common File Dialogs

20 Jun 2017, 07:01

jeeswg wrote:That Lexikos script looks great, I will try and adapt it for listing files on Desktop. I had wondered if there was a more direct way to get access to the interface, I don't really know much about what starting point object to use, and then the quickest route to get the desired interface, i.e. 'hopping' between interfaces.


Yes, neither do I. I wish I had known that was possible before I wrote my non-IDispatch one as it's so much easier :(

Re. the Common File Dialog script. I'd be tempted to create two versions: a machine code version (no additional files needed) and a dll required version if it is superior in some way. Although from what you're saying it sounds like you do need the dll in this case.


It wouldn't be impossible to do it in MCode that's injected into the remote process like I do my TCC-compiled code (off the top of my head, you'd need to make the C code look for the function pointers from the threadData struct and, additionally, you'd need to numput the address of whereever the threadData struct has been allocated in the rmeote process into the MCode buffer directly. Again, blame SetWindowsHookEx :)), but providing DLLs with the compiled code would be far easier as there'd be no creating multiple buffers to store the two functions inside the remote process, no need to look up the function addresses for WinAPI functions yourself etc. Though you would need to distribute two DLLs with your script. OTOH, it's not like it's any different with TCC now and I think you would also get the benefit of being able to target x86 process from an x64 script too.

Of course, who says that writing C code has to be the way? Like you mention, you could just as easily use AutoHotkey_H and do it with AutoHotkey code running inside the remote process :-)

You're right that it's better to have the C/C++ code, although, you could just use machine code *and* include it in the script as comments, and/or add a link to it, possibly with some details, e.g. 1/2 lines, of how you converted the C/C++ code to the machine code.


For me, while I'm aware half of the code I post looks dodgy as hell, I find MCode downright arcane. I'm sure the MCode for these functions would come out as pretty large, making me especially mistrustful of it, and I don't have the knowledge to use objdump or IDA to verify that, indeed, the MCode roughly matches the commented code given. I mean, I'm not saying my current script looks great, but assuming the TCC DLL is OK, you know what's being executed in the remote process because the C code is compiled then and there from what's in the script.

[EDIT:] It's always a major advantage for scripts, whenever they: don't require external files, don't require Admin mode, don't require dll injection (or multithreading?) (i.e. require AutoHotkey_H), and are written to be as compatible as possible, requiring minimal or no changes to work in other older/newer AHK versions.


I agree, but sometimes ya gotta do what ya gotta do. I mean this script's raison d'être is that WM_GETISHELLBROWSER returns an address that's inside the remote process itself...

Cheers, I think at least twice I've had it reported in my feed that you made updates to posts in threads I've been in. I checked the posts, and I couldn't tell what had changed. So maybe if you use '[EDIT] / [EDIT:] / EDIT / EDIT: / edit / edit:' or something like that, I could tell. Btw is there some special way to 'bump' a post without changing it!?


You're right, sorry, I usually do add an "EDIT: " to the start/end of my posts but in this case, I didn't bother, opting to hide my old script inside a spoiler block and using [strike] instead. I think two consecutive posts by the same person causes this forum software to join the two together, but I think that's only done if the two posts are made on the same day or something.
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

15 Aug 2017, 21:39

These are links for getting the folder/selected file from a Common Item Dialog (new since Windows Vista).
[script by qwerty12:]
get full paths of selected files on Desktop and Common File Dialogs - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=31135&p=145577#p145577
[notes by jeeswg:]
get full paths of selected files on Desktop and Common File Dialogs - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=31135&p=145883#p145883

I'm mentioning here in case anyone has found any ways to simplify the script, and/or, if anyone feels capable of converting it, so that AutoHotkey (i.e. AutoHotkey_L v1.1/v2.0) and AutoHotkeyMini.dll can be used instead.

I will be returning to the script at some point, but it may be many months, and I would have to acquire some new skills. I might even consider creating an exe that could return a path for a given hWnd. Cheers.
User avatar
jeeswg
Posts: 4481
Joined: 19 Dec 2016, 01:58
Location: UK

Re: get full paths of selected files on Desktop and Common File Dialogs

19 Aug 2017, 11:37

Here is a fairly basic script for getting the folder and selected file from a Common Item Dialog. The new style dialog that appears since Windows Vista e.g. for Notepad open/save as.

There is a control that seems to consistently contain the folder name.

Also, by grabbing the text from the Edit control, and checking for files in the folder, you can try to retrieve the path of the selected file. The script lists any files whose display name matches the text in the Edit control.

Note: if extensions are hidden, and more than one file with the same name (but different extensions) exists in the folder, then there are multiple possibilities for the selected file. E.g. 'MyImage.gif' and 'MyImage.jpg' would both have display name 'MyImage' if file extensions are set to hidden.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


Return to “Ask For Help”

Who is online

Users browsing this forum: Calimero 0euf, Zurydix and 24 guests