Macro to Open File Dialog Box to a Specific Location

I have created a new menu item which will allow a user to bring up the Open File Dialog window. But I need to request that it open up to a specific default location each time it's run rather than the last opened folder.

Right now the macro for this new command is ^C^C_open.

Is there a method which will allow us to specify the folder location to open?

I was pointed in the right direction by another co-worker on this. She suggested

^C^C^P(startapp "explorer.exe T:")

and she was right. It worked fine. Still I was hoping to get the real "Open" window in autocad, not just the generic explorer window.

Thank you for sharing that solution with us Brenda. Now if everyone who came here could be as efficient as you (ask and answer your own question) we could all take the day off and go to the beach and enjoy a frosty cold beer too. LoL

So, you were looking to access a network drive mapped as T:? This is equivalent with:

^C^C^C(startapp "explorer.exe” “T:\\") ^P

Your first post let me the impression that you were looking to have the drawing selection dialog of OPEN command pointing to a predefined path, rather than default, current folder.

Thanks again to all of you. I would prefer to have the OPEN command pointing to a pre-defined path. This macro uses Windows Explorer, which is ok, but it doesn't bring up the typical File Open window in Autocad, instead it brings up an instance of Windows Explorer. Which if it works is ok.

I am still having some troubles with this macro, for instance this morning I can type this at the command line:

(startapp "explorer.exe" "T:\\Checker")

and it opens up Windows Explorer at this folder location on the T: drive. But I copy and paste the same thing in the CUI for this particular menu command and nothing happens.

^C^C(startapp "explorer.exe" "T:/Checker")

This macro, however, works just fine from the menu item or from the command line.

^C^C^P(startapp "explorer.exe "T:")

MSasu,

Thanks again for your replies, but I tried the syntax you offered and all it did was dump the contents of that syntax on the command line. What's so difficult about this is that I can do this on the command line:

(startapp "explorer.exe" "T:\\Checker")

and it works fine. Yet the macro in the CUI for this menu item like this:

^C^C^P(startapp "explorer.exe" "T:\\Checker")

produces nothing...no message or error indications at all and mostly no Windows Explorer opened up to the T:\Checker folder. I'm really perplexed on this one.

When create the macro for toolbar button, you should pay attention to end it with a space character - it act like an to run the statement.

Yes, that you are correct on...and I should say that I've been cognizant of that. I have tried it using a space, a semi-colon, two semi-colons...etc. Just about anything to get it to work. What I can also say is that if I leave off the folder name and just use the drive name "T:" it works fine from the cui menu macro. I can make this work also from the command line in addition to adding the folder name. It all seems to work well from the command line but not when it's inserted as the syntax for the menu macro. I don't get it.

Brenda, if no one offers to test this until tomorrow, I will do some tests for you in AutoCAD's menu (don't have access to it right now).

I would prefer to have the OPEN command pointing to a pre-defined path. This macro uses Windows Explorer, which is ok, but it doesn't bring up the typical File Open window in Autocad, instead it brings up an instance of Windows Explorer.

There are multiple ways to accomplish this, using GETFILED function for example, but just for fun:

Here's a sample Macro for a predefined location:

** Note - The use of a single forward-slash "/" in the macro, as double back-slash "\\" will result in a PAUSE for user input.

^C^C^P(_OpenHere "T:/Checker");._open;^P

... And the supporting "_OpenHere" LISP sub-function:

This sub-function accepts a single argument, a file path as String, and verifies that the file path is a valid location prior to updating the aptly named "InitialDirectory" registry key which defines the starting point for the OPEN dialog. This code also accounts for both pre, and post 2013 LISP functions for product key.

(vl-load-com)

(defun _OpenHere (filePath / key)

 (if vlax-user-product-key                                             ; If using 2013
   (setq key (vlax-user-product-key))                                  ; Then, use new lisp function
   (setq key (vlax-product-key))                                       ; Else, use legacy function
 )
 ;; More info here:
 ;; http://www.cadtutor.net/forum/showthread.php?70845-AutoLISP-API-Changes-for-AutoCAD-2013-Updated

 (if (setq
       filePath (vl-string-translate
                  "\\"
                  "/"
                  (findfile (vl-string-right-trim
                              "/"
                              (vl-string-right-trim "\\" filePath)
                            )
                  )
                )
     )
   (vl-registry-write
     (strcat
       "HKEY_CURRENT_USER\\"
       key
       "\\Profiles\\"
       (vla-get-activeprofile
         (vla-get-profiles
           (vla-get-preferences (vlax-get-acad-object))
         )
       )
       "\\Dialogs\\OpenSaveAnavDialogs"
     )
     "InitialDirectory"
     filePath
   )
 )
 (princ)
)

HTH

Thank you very much RenderMan, this looks like a good start but for some reason it's not picking up the filepath variable. The OPEN dialog box opens just fine but it's opening up to something Windows must have in it's memory...a folder on the local C:\ drive.

I'm very grateful for your guidance and advice here. We just threw the 800 lbs gorilla at this issue and mapped a new drive letter to T:\Checker...it's called just plain old Q:. This allows the macro to work from the menu (CUI). The IT guys are telling me that we must be missing something. If it works from the command line then it should work as a macro for a menu item. I would tend to agree with them.

Thank you very much RenderMan, this looks like a good start but for some reason it's now picking up the filepath variable. The OPEN dialog box opens just fine but it's opening up to something Windows must have in it's memory...a folder on the local C:\ drive.

You're welcome, Brenda.

The sub-function I posted checks for a valid file path (the argument you specify in the macro), and only if it (the argument) is a valid location, changes the registry key value that the Open dialog uses, otherwise no change is made prior to the macro calling the Open Command.

The sample macro posted is using the file path you specified in an earlier post. As I do not have this drive mapped in my setup, I used a different file path as String for my testing, but was successful in opening to multiple network locations.

Please post the macro you're attempting to use.

^C^C^P(I:/ACAD/VLISP/OpenHere "T:/Checker");._open;^P

I have located the lisp file in a folder on the servers reserved for such things. The lisp file is running ok, it's just not picking up the filepath variable. Could it possibly be that my limited rights on this machine do not allow an edit to the Registry. I have asked IT about this and they kind of think that might be the issue but as always they are too busy putting out other fires to spend time with me on this...maybe later they can offer assistance.

OK...I just checked and writing to the Registry is not the problem. I made a new entry in it and added a few keys, then deleted them. All that worked well. Also I changed the name of the lisp file from _OpenHere to OpenHere.

Stop ... Your macro is incorrect.

Lets backup a bit, to make sure we've got the basics covered....

If you haven't already, please copy the LISP code I posted here into an empty text file, and save with the .LSP file extension. Name this file anything you wish, but for these instructions I'll use "OpenHere.lsp" as a given for the file's name.

Save "OpenHere.lsp" to any location that resides within your Support File Search Path (SFSP), and load this file either via APPLOAD, or via AcadDoc.lsp, or YourCuiName.mnl using the LOAD function.

_OpenHere is the function name, and not the file name (for "OpenHere.lsp"), thus the file path is not needed within the macro. Your macro should look like this:

^C^C^P([b][color=red]LispFunctionName [/color][color=blue]Argument[/color][/b]);._Open;^P

... Or:

^C^C^P([color=blue][b][color=red]_OpenHere[/color] "T:/Checker"[/b][/color]);._Open;^P

Try that, and see if that corrects the undesired behavior. Let us now how this works out for you?

RenderMan,

You're right. That took care of it. Now to convince the IT guys to autoload this LISP file. They are always skeptical about this kind of department wide policy change...in fact they hate any kind of change. Still, they serve their purpose around here fairly well.

OK. Just avoided that problem. Added something to the macro to have it load the LISP file on the fly. It works fine and IT will never have to be bothered with a policy change. Thanks.

No worries; glad you got it sorted.

We too have strict guidelines from our corporate CAD group (separate from IT), but AcadDoc.lsp falls under my realm of authority (as a CAD Lead for my regional group).

FWIW - *IF* your IT permits user customization (as we do), then ask them instead to simply consider incorporating this into the code that is loaded:

((lambda (user / file)
  (if (setq file (findfile (strcat user ".lsp")))
    (load file)
  )
)
 (getvar 'loginname)
)

We build into our SFSP several paths that reside on the user's personal network space for customizations in each deployment for things like Main CUIx, LISP, Scripts, etc.. All of which are loaded prior to our corporate customizations. This both allows the user to be creative, and enforce our standards.

HTH

OK. Just avoided that problem. Added something to the macro to have it load the LISP file on the fly. It works fine and IT will never have to be bothered with a policy change. Thanks.

Provided "OpenHere.lsp" resides within SFSP:

^C^C^P(if (not _OpenHere)(load "OpenHere"));(_OpenHere "T:/Checker");._Open;^P

Thanks a million for all your advice. But as they say about the best laid plans...

1. The method of using the LISP and ._Open command worked fine the first time. Then of course the user wants to open another file, but this time they will not be using the menu item I created because that's for a different set of files in a special folder. Of course when they choose . the same special location opens up.....WHACK...ticked off users who now have to navigate back their other typical folders.

2. OK...that being said and the user cools off. Now they choose the new custom menu again and go to open a file from the special location again. WHACK! The macro does not function now. The Open menu comes up but the Registry Key apparently has been written back to the same typical folder the user just opened.

3. On top of all this, we are finding that loading the custom menu into other user's computers is a hit or miss thing. I cannot believe what I'm seeing but I saw it now on two different machines. We loaded the menu file and all looked well. The user selected the choice from the menu and the macro executed. Now, we made a slight change to the macro and resaved the menu in the CUI screen. The user then tried to execute the menu choice again and it was still performing the old operation. WHACK! We then unloaded the menu and reloaded it. WHACK! Same thing. We shutdown AutoCAD and restarted it. WHACK the menu choice was still executing the old macro. I looked at the macro in the CUI and it shows the changes we made. We then unloaded the custom menu, cold booted the computer and reloaded the menu and it worked. The menu choice still has the big trouble of not keeping it's state over the session. If the user used the Open menu and changes the location where they select a file, when we run the macro again, it opens up to this new folder, not the targeted one we want.

The boss finally got ticked off enough at me to say just go back to the drive mapping method you had working and let's move forward. So for now at least, the macro:

^C^C^P(startapp "explorer.exe" "T:")

We will have to insist that all users map T:\ drive to this special location. But for now it's on to the next phase.

Not sure what's different on your end, but this works perfectly fine here, repeatedly.

FWIW - I'd like to think I do good work more often than not, but I would never incorporate something picked up from a CAD forum into our deployment, affecting multiple users, without first extensively testing on my own. Just saying.

When using the macro, a predefined location is set. So, yes, when a user issues the Open Command rather than using the Macro, the last location is now default. You've not implemented any sort of Command Reactor to reset that registry key, so yes, of course it's in that location.

We heavily use shortcuts here, so navigating to another project is a non-issue for us.

Sorry for any confusion, and good luck.

LISP I picked up years ago from an unknown source - works for me on 2011.

;========= Explorer to Current Directory

(Defun C:ECD ()
  (Setvar "Cmdecho" 0)
  (Command "Shell"
     (Strcat
        "Explorer /n,/e,"              ;Explorer, New Window, use Explorer View 
        (Chr 34)                       ;Quote marks
        (Getvar "dwgprefix")           ;Current drive and folder
        (Chr 34)                       ;Quote marks
     )                                 ;Close Strcat
  )                                    ;Close Command
  (Princ)
)                                       ;Close Defun on C:ECD

;========= Explorer to AutoSave Directory

(Defun C:EASD ()
  (Setvar "Cmdecho" 0)
  (Command "Shell"
     (Strcat
        "Explorer /n,/e,"              ;Explorer, New Window, use Explorer View 
        (Chr 34)                       ;Quote marks
        (getvar "savefilepath")        ;Current drive and folder
        (Chr 34)                       ;Quote marks
     )                                 ;Close Strcat
  )                                    ;Close Command
  (Princ)
)                                       ;Close Defun on C:EASD 

Another from Lee Ambrosius;-

;; Created by: Lee Ambrosius
;;                HyperPics, [url]http://www.hyperpics.com[/url]
;;
;; Last revised on: 06/15/03
;; Program is used to search for a file with in the AutoCAD Support paths.
;; It then will display the file in Explorer or folder view
;; Opens Explorer w/ Treeview and highlights the file
(defun c:BrowseToFileWithTree( / fileLoc fileName)
;  (setq fileName (getstring "\nEnter file name and extension to find: "))
; Added to open current file in Explorer 18/08/2005 JGA
 (setq fileName (getvar "DWGname"))
 (if (setq fileLoc (findfile fileName))
   (startapp "explorer" (strcat "/n, /e, /select," (substr fileLoc 1 (- (strlen fileLoc) (+ (strlen fileName) 1))) " \\" filename))
 )
)
;; Opens Explorer w/o Treeview and highlights the file
(defun c:BrowseToFileWithoutTree( / fileLoc fileName)
 (setq fileName (getstring "\nEnter file name and extension to find: "))
 (if (setq fileLoc (findfile fileName))
   (startapp "explorer" (strcat "/n, /select," (substr fileLoc 1 (- (strlen fileLoc) (+ (strlen fileName) 1))) " \\" filename))
 )
)
(defun c:B2FT()(c:BrowseToFileWithTree))
(defun c:B2F()(c:BrowseToFileWithoutTree))

(prompt "\nType B2FT or B2F to display a file in Windows Explorer.")
(princ)