multiple file selection in macro 1

[JordonMusser]

I have several macros that do various things to drawings (alter file names, save as PDF, change revisions, sign offs etc). Right now I either have the macro process a whole directory, or all open files. Is there a way to use a dialog to select multiple files, and I guess it would return an array of files I can iterate through?

 

[handleman]

SolidWorks doesn't have a multi-select "Open" dialog. I think you have two options. You can use Windows API, methodology for which is described in a FAQ (faq559-1164), or you can "cheat" and use Excel's API, as shown in thread559-215560.

-handleman, CSWP (The new, easy test)

 

[JordonMusser]

Although multi-select would be nice, I probably do not need it.. to just be able to fumble around in a directory structure clicking "add" until I have all the files I want, since I might not have them in the same directory.

btw, the macro on that 2nd link doesnt work. It crashes and says my machine is out of memory and a couple other goofy things.

 

[JordonMusser]

another option I am entertaining is just writing the code in VB, and accessing SW objects. but NOT being a software engineer I am not sure how to do that, (I am guessing I need to "load" the SW library from my VB program, etc).

Any links to snippets that might show how this is done? I can write everything in SW API easily, 'cept the multiple file/add etc setup. So this might be a good project to learn with!

 

[handleman]

Did you look at the code in the second link? It's really quite simple. At what point does the macro crash? If you want to just pick one file at a time, you could use SldWorks::GetOpenFileName. As far as adding filenames to an array, this is possible. However, if you want to pick a bunch of files from different directories, I would suggest that you create a form with a list box and some buttons - one for "Add", one for "Process", one for "Cancel", and one for "Remove". The list box can function pretty much like a dynamic array. You can add items or remove them quite easily in code, with the added benefit of the user being able to visually see the entire list they are creating.

-handleman, CSWP (The new, easy test)

 

[handleman]

Attached are a user form and a sample macro using it. To include this form in a macro you are already using, just import the .frm file in the VBA editor. Of course, you'll have to unzip the .frm and the .frx file into the same directory. The macro file is a quick sample to show how to use the form.

To add one file at a time, leave the box on the form un-checked. This will use the SolidWorks GetOpenFileName function, which only allows for one file at a time to be selected but it shows the thumbnail preview, etc. Checking the Multi-Select box will cause SW to create an instance of Excel and use the multiple file selection capability of Excel's API to select multiple files at once. All files selected by either method are added to the list on the form. The code checks for files that are already in the list, so duplicates can't be introduced. However, there is no error checking for the user simply typing in some name that doesn't exist, so the macro you use will have to check for the possibility of non-existent files.

-handleman, CSWP (The new, easy test)

 

[IvanaX]

Dim s As String
Dim arr() As String

s = Dir("C:\temp\*", vbNormal)
ReDim arr(0)
Do While s <> ""
Select Case MsgBox("Add file " & s & " to array?", vbYesNoCancel Or vbExclamation Or vbDefaultButton1, App.Title)

Case vbYes
arr(UBound(arr)) = s
ReDim Preserve arr(UBound(arr) + 1)

Case vbNo

Case vbCancel
Exit Do
End Select
s = Dir
Loop

 

[JordonMusser]

It actually crashes before it even runs- even trying to edit it I get all these memory errors. very odd.

Handle, thanks I just downloaded the file and am going to look at it.

Any comments on launching SW functions from a general VB program?

 

[handleman]

You can't "launch SW functions from a general VB program". You can use Automation and the SolidWorks API to create or attach to an instance of SolidWorks and then use the VB program to control that instance. However, SolidWorks will still be doing the heavy lifting. In most cases it's easier to just write all the code in a SW macro. Off the top of my head, reasons to use a standalone .exe controlling SW are:

1. Lots of stuff going on that's not particularly related to SW - database stuff, external calculations, etc. A compiled .exe will run faster, although not noticeably unless you are really doing a lot.

2. More GUI stuff available, including file/folder browsing.

3. Better IDE.

4. More code security if you care about that stuff. It's harder (although far from impossible) to reverse-engineer compiled code than a .swp!

Reasons to use a SolidWorks macro include:

1. Easier to integrate into SolidWorks - you can make a button or shortcut key for a macro very easily.

2. Slightly easier to code, since you are controlling SolidWorks with SolidWorks.

3. Easy to tweak/improve after you get it working - no recompiling, etc.

4. Everything is in one file rather than a collection of files.

-handleman, CSWP (The new, easy test)

 

[ShaggyPE]

Have a look at Lenny's macro PropertyEditorSpec:

http://www.lennyworks.com/solidworks/default.asp?ID=20

It has a good interface to select files in a directory.

-Dustin
Professional Engineer
Certified SolidWorks Professional
Certified COSMOSWorks Designer Specialist
Certified SolidWorks Advanced Sheet Metal Specialist