AutoHotkey: copy path of office documents
Hello experts,
I was wondering how to create an AutoHotkey to perform this daily action:
Copy path of word, excel, powerpoint document.
The idea is the following:
I am working on an office document. I launch the related AutoHotkey through shortcut set up to recover path to clipboard and then paste the clipboard if I want to attach it instead of closing the file and trying to find where is located the document.
Here is the option available in word:
It can be activated through Alt + F
I don't know how to select this copy path button through the keyboard.
If you have advice or an smart way to cover this daily action please let me know.
I was wondering how to create an AutoHotkey to perform this daily action:
Copy path of word, excel, powerpoint document.
The idea is the following:
I am working on an office document. I launch the related AutoHotkey through shortcut set up to recover path to clipboard and then paste the clipboard if I want to attach it instead of closing the file and trying to find where is located the document.
Here is the option available in word:
It can be activated through Alt + F
I don't know how to select this copy path button through the keyboard.If you have advice or an smart way to cover this daily action please let me know.
ASKER
Thank you Joe, I will wait don't worry and have a great return!
If you have advice or an smart way to cover this daily action please let me know.Hi Luis,
The "smart way" is not to send mouse moves/clicks or keyboard keystrokes, but to write a "real" program that utilizes the Component Object Model (COM) of Microsoft Office. It's time to raise your AutoHotkey game! :)
AutoHotkey has built-in/native support for COM. Here's a Microsoft link where you may learn more about COM:
https://docs.microsoft.com/en-us/windows/win32/com/component-object-model--com--portal
This sub-link there is helpful as a brief introduction:
https://docs.microsoft.com/en-us/windows/win32/com/the-component-object-model
Here's a post of mine at EE where I made a similar comment to a member, i.e., that there's a much better way...namely, stop the whole "ControlClick/Send/Sleep" approach...write a "real" AutoHotkey program calling COM:
https://www.experts-exchange.com/questions/28973610/AutoHotKey-vs-Pulover's-Macro-Creator-syntax.html?anchorAnswerId=41824810#a41824810
I'm working on an AutoHotkey script now that will determine the full path of the active file in these Microsoft Office apps: Access, Excel, PowerPoint, Publisher, and Word. It will put the full path in a variable so that you may then do anything you want with it. I think this will be useful for folks besides you, so I plan to publish an EE article about it...I'll try to do it this weekend. Regards, Joe
ASKER
Noted, Thank you very much for your advice.
ASKER
Hello Joe,
I hope all is ok.
I was wondering if you were able to work on AutoHotkey script that determine the full path of the active file in microsoft office apps.
Thank you for your help.
I hope all is ok.
I was wondering if you were able to work on AutoHotkey script that determine the full path of the active file in microsoft office apps.
Thank you for your help.
ASKER
Hello Joe,
I made a test for word and the following works for me:
Is there a way to put text inside of ComObjActive as an array or set up multiple if conditions?
Thank you for your help.
I made a test for word and the following works for me:
;~ Get full path of active word document into clipboard
+F4::
Clipboard:= % ComObjActive("Word.Application").ActiveDocument.FullNameIs there a way to put text inside of ComObjActive as an array or set up multiple if conditions?
Thank you for your help.
Hi Luis,
Yes...the AutoHotkey script is working perfectly here with Office 365 on W7. Haven't tested yet with Office 2019 on W10.
I created a function called GetActiveOfficeFile. It returns the full path/name of the active office file for Access, Excel, PowerPoint, Publisher, Visio, and Word (it returns an error if the active program is not one of those apps). It does this by calling AutoHotkey's built-in/native support for the Component Object Model (COM).
I then wrote a sample program that utilizes the function. The sample program establishes a hotkey that calls the function and simply displays a message box with the active file's full path/name. For example:
If the active program is not one of the six supported Office apps, the sample program displays a message box with the Title, Class, Process Name, and Handle of active window. For example:
Of course, you may do whatever you want with the file's full path/name. For simplicity, my sample program simply puts out a MsgBox. Also, the sample program uses Alt+Ctrl+F12 for the hotkey, but, as always, you can make it whatever you want.
I'm not ready to publish it yet, but I hope you find this status update to be helpful. Regards, Joe
Yes...the AutoHotkey script is working perfectly here with Office 365 on W7. Haven't tested yet with Office 2019 on W10.
I created a function called GetActiveOfficeFile. It returns the full path/name of the active office file for Access, Excel, PowerPoint, Publisher, Visio, and Word (it returns an error if the active program is not one of those apps). It does this by calling AutoHotkey's built-in/native support for the Component Object Model (COM).
I then wrote a sample program that utilizes the function. The sample program establishes a hotkey that calls the function and simply displays a message box with the active file's full path/name. For example:
If the active program is not one of the six supported Office apps, the sample program displays a message box with the Title, Class, Process Name, and Handle of active window. For example:
Of course, you may do whatever you want with the file's full path/name. For simplicity, my sample program simply puts out a MsgBox. Also, the sample program uses Alt+Ctrl+F12 for the hotkey, but, as always, you can make it whatever you want.
I'm not ready to publish it yet, but I hope you find this status update to be helpful. Regards, Joe
ASKER
Thank you very much for this update Joe. When the article is ready, please let me know.
Hi Luis,
My last post crossed with your previous one, so I'll address that now. It's not very tricky to set it up for different apps. There are just two items needed...the EXE name or Class of the app (both well-known and easy to determine) and the full path/name property for each (well-documented at the Microsoft COM doc). Then it's a simple set of IF checks for the EXE name or Class (I decided to use the EXE name in my function, such as winword.exe) followed by the assignment statement for the full path/name property (such as ActiveDocument.FullName for Word).
The truly tricky part is writing rock-solid code that does a lot of error checking, such that the AutoHotkey script never blows sky high. For example, try the script that you posted on a non-Word window. You'll get this:
I write code that catches errors like that and provides more meaningful output for users, such as the second screenshot in my previous post. To give you a better idea of what I mean, the function that I wrote is currently 101 lines of code (not counting blanks and comments). The sample program that I wrote is currently 85 lines of code (not counting blanks and comments). A lot of that code does error checking.
Btw, since you seem to want it on the clipboard (that's in the code you posted), I updated my sample program to do that, too (along with the MsgBox, which, of course, you may easily remove). Regards, Joe
My last post crossed with your previous one, so I'll address that now. It's not very tricky to set it up for different apps. There are just two items needed...the EXE name or Class of the app (both well-known and easy to determine) and the full path/name property for each (well-documented at the Microsoft COM doc). Then it's a simple set of IF checks for the EXE name or Class (I decided to use the EXE name in my function, such as winword.exe) followed by the assignment statement for the full path/name property (such as ActiveDocument.FullName for Word).
The truly tricky part is writing rock-solid code that does a lot of error checking, such that the AutoHotkey script never blows sky high. For example, try the script that you posted on a non-Word window. You'll get this:
I write code that catches errors like that and provides more meaningful output for users, such as the second screenshot in my previous post. To give you a better idea of what I mean, the function that I wrote is currently 101 lines of code (not counting blanks and comments). The sample program that I wrote is currently 85 lines of code (not counting blanks and comments). A lot of that code does error checking.
Btw, since you seem to want it on the clipboard (that's in the code you posted), I updated my sample program to do that, too (along with the MsgBox, which, of course, you may easily remove). Regards, Joe
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Joe,
I tested on Excel, Powerpoint, and Word 2016 and it works!
This script is extremely useful and it will help me to save time on my repetitive tasks.
Saying that, I would like to know if there is an open window to extend the approach to other applications different than office such as
-Notepad++
-SSMS
-Powershell
-Vbsedit
I know that extending the script will be subject to another question, however I would like to know your though about the fact to extend the approach to other office applications.
Thank you for your help.
Regards,
Luis.
I tested on Excel, Powerpoint, and Word 2016 and it works!
This script is extremely useful and it will help me to save time on my repetitive tasks.
Saying that, I would like to know if there is an open window to extend the approach to other applications different than office such as
-Notepad++
-SSMS
-Powershell
-Vbsedit
I know that extending the script will be subject to another question, however I would like to know your though about the fact to extend the approach to other office applications.
Thank you for your help.
Regards,
Luis.
> I tested on Excel, Powerpoint, and Word 2016 and it works!
Glad to hear it!
> extend the approach to other applications different than office
Some yes, some no, some I don't know. You would need a different method, because the posted code is specific to Office COM calls.
> extend the approach to other office applications
To be clear, the approach can be extended to other Microsoft Office apps, such as Access, Publisher, and Visio. But for non-Office apps, the approach needs to be different, although many other apps do have an API/SDK. I always prefer the COM/API/SDK approach to sending mouse moves/clicks and/or sending keystrokes. Regards, Joe
Glad to hear it!
> extend the approach to other applications different than office
Some yes, some no, some I don't know. You would need a different method, because the posted code is specific to Office COM calls.
> extend the approach to other office applications
To be clear, the approach can be extended to other Microsoft Office apps, such as Access, Publisher, and Visio. But for non-Office apps, the approach needs to be different, although many other apps do have an API/SDK. I always prefer the COM/API/SDK approach to sending mouse moves/clicks and/or sending keystrokes. Regards, Joe
ASKER
Noted. Thank you very much for comment and your help Joe!
I'm leaving my office now and will be offline for a while. I'll post a reply for you when I return, but it could be several hours. Regards, Joe