Modiify Online Store Online Retail Store
XNA Games Xbox 360 - Windows 7 Phone
Silver: The Dark Fiend Xbox 360 Platformer
Baskets: Slam Dunk Windows 7 Phone Sports
ALightsOut: A Classic Windows 7 Phone Puzzle
Software
SaveAsX
LaserMRP
Property Extractor
Property Wiper
Engineering Toolbox
SWTools
Config Searcher
Circle Centers
3D Matrix
GUID Creator
Fuel Economy Calculator
SolidWorks API Books
SolidWorks Macros
Tutorials
Message Boards
Merchandise AngelSix branding fun
Free Products
News
Clients & Testimonials
Shipping & Returns
Terms & Conditions
Privacy Policy
Contact Us
SaveAsX is a free tool that allows the user to quickly and easily save the active SolidWorks model into Jpeg, Tif, DXF or DWG at the click of a button, with the powerful ability to change the location and filename to anything they like based on normal text, the existing filename, any custom property within the model, and any combination of them. All of this happens in real-time with a preview output of the filename that will be created. Enjoy!
[span class=download]Download links: Download Link 1[/span]
| < Prev | Next > |
|---|
Comments
Glad you like the enhancements.
The issue with custom property names is that you have to put them all in upper case. That fact was simply due to the fact that when I wrote the program it was a 1 day project and to save hours of work on writing a parsing engine, keeping them all uppercase makes the job much faster.
As for the screen movement, this is purely a SW thing if it is moving as SAX just does normal API calls so shouldn't effect the screen positioning at all.
The addition of page numbering and other processing etc... is just beyond the scope of this little tool as that is what BatchProcess is for when you want to do more. The idea of SAX is a short and sweet but powerful saving tool.
Luke
Ken,
Glad you like the enhancements.
The issue with custom property names is that you have to put them all in upper case. That fact was simply due to the fact that when I wrote the program it was a 1 day project and to save hours of work on writing a parsing engine, keeping them all uppercase makes the job much faster.
As for the screen movement, this is purely a SW thing if it is moving as SAX just does normal API calls so shouldn't effect the screen positioning at all.
The addition of page numbering and other processing etc... is just beyond the scope of this little tool as that is what BatchProcess is for when you want to do more. The idea of SAX is a short and sweet but powerful saving tool.
Luke
Really great enhancement! I've been testing for a little bit, and in general most things seem to be working well -- change SW parts, remember settings from invocation to invocation, etc.
Currently I have only found a couple of items that you might want to take another look at:
1) In a drawing file, the configuration name associated with the underlying part (i.e. $PRPSHEET:"SW-Configuration Name") is shown as by @@CONFIG@@. In part files this is reported correctly.
2) I'm not sure why, but with the exception of "Description", custom properties with names in mixed- or lower- case are not shown by @@. For example, a custom property named ABC works fine; but one named Abc or abc fails.
3) Really a nit, but there is a lot of screen movement when saving as a .pdf. In addition, a drawing not not left in the same position on screen as before. Not sure if this if beyond your intended scope, but you cannot specify the pages for a .pdf. I also received the "...program busy..." message when saving a drawing as a pdf.
Again, a really nice effort and much appreciated.
Ken
The SPR for your drawing file with images produces temporary files is :
SPR 468674
Luke
Just to let you know I don't get the double warning about the file existing after testing on 3 machines so it is best leaving the check in as it will be a system level setting that some people may not have enabled.
Luke
3) If a same named .dxf file already exists, then an overwrite warning is presented twice -- once by SAX and then other by SW. I didn't try this on other file combinations (.dwg, .jpg, etc.), but I would suspect that at least .dwg would behave the same.
4) Filepath, I think that there is a need for something like "Write to the same directory as the Part's". Currently, if you want to save the file to the same directory as the underlying SW file, then you have to browse every time that your part directory changes.
Thank you for your consideration.
1) If SAX is kept open after a run and the underlying SW part is changed, then SAX has an unhandled exception (HRESULT 0x800706B5) or it will give an invalid file type message. Closing and then opening SAX with the same file open in SW that caused the error, clears this issue. This problem does not seem to occur if the sheet is changed, as long as the SW file remains the same.
2) The Filename template is not remembered after closure. That is, it always returns to @@NAME@@ - Copy, regardless of the previous setting. I think that this should be remembered as it is likely that once a convention is established, it will remain in place for some period of time, at least for that production run.
...Continued
Thank you for your consideration.
I will update the program over the weekend for you with all of the features.
In the mean time can you email me the sample drawing you have that is exporting the images so I can get a better idea?
Luke
1) Currently the default filetype is set to .jpg. Like the path(s), I think it would be worthwhile to remember the MRU filetype. We would be using SaveAsX to process dxf's maybe 95% of the time, so having it open with "our" filetype would be helpful.
2) At the completion of the process, a Windows Explorer window is popped. I would prefer that the process just exit as we probably already have open the directories that we want anyway.
2) I like your suggestion of highlighting the MRU path.
3) The ones that come quickly to mind are ConfigName and (possibly) SheetName.
Regards,
2. The button is disabled because if you don't select a path it doesn't know where to save it to. Just select the path and the button will enable. I can change the program to select the first path available or better yet the last used path when the program opens.
3. The functions are only the ones specified the moment. Do you have any other requests to be added?
I have a couple of comments regarding usage that I wanted to pass on.
1) There is a .bmp temp file that gets created, but does not get removed. This seems to occur when there is an image file (Insert-->Picture) in the SLDDRW.
2)The "Save As" button doesn't activate even when there is only one path specified (or you could look at it that the path doesn't get highlighted when there is only one path)and all other items filled in.
3) I understand the @...@ custom prop references, but other than @@NAME@@, what other special tags are available?
Again, thank you.
I did what you have suggested in your last comments. Rest is all except for SldWorks.Application.18 name. It is rather SldWorks.Application.1 which I don't think should be making much difference. Also I'm running 32 bit OS.
And sorry but I'm not familiar with C# app, so I may not be able to do what you have suggested in that comment.
Go to the Registry and browse to HKEY_CLASSES_ROOT\SldWork s.Application.18 and take a look at the CLSID folder. Get the value in there. It will be a big long number.
Right-click the (Default) and click modify so you can copy the long number. Then go to the top of the registry tree again and Ctrl+F to do a new find, then paste that number in and search. The first find should take you to HKEY_CLASSES_ROOT\CLSID\{ your-number-here}
In there you should have a folder called ProgID and VersionIndependentProgID, both of which should equal SldWorks.Application.18 or SldWorks.Application.
If any of these folders are missing then SolidWorks hasn’t installed correctly.
If the names are different than SldWorks.Application.18 or SldWorks.Application then also let me know.
Try making a quick C# app that just attempts to connect to SW using:
SldWorks mSolidWorks = (SldWorks)Marsh al.GetActiveObject ("SldWorks.Application");
and then check if mSolidWorks is null. If it is then your SolidWorks doesn't seem to be registered correctly in the COM table.
You may also try overwriting the solidworks dll files in the installation folder (Program Files\AngelSix\SaveAsX) with those in your SolidWorks installation folder.
Is there any other way I should be running it or simply double click?
I have just re-tested this on 2009 and 2010 and both work fine. It uses the normal (SldWorks)Marshal.GetActiveObject("SldWorks.Application") method so shouldn't have a problem.
RSS feed for comments to this post.