I don't think it's coming from an application not defined for swp files but rather linked to the macro that has no "automatic" execution. A bit like Word/Excel macros, it takes an execution at the time of the opening event to trigger actions afterwards.
Another point that bothers me, and that may have also stung your eyes, is the automatic closing of the document after export. If I want to work on my document in the normal way, there will be a problem: I open, and bam, it closes. If I don't embed my macro in the document, I should be able to trick me by temporarily moving the macro to another directory. But is there another way?
As you may have guessed, it's problematic to do this kind of macro. The best, in my opinion, is to make a macro button that will allow you to save your document in PDF/JPEG in the folders of your choice and close the drawing.
You can also make a macro that opens the drawing of the document you have selected in your tree, saved and closed the drawing.
You also have to be careful because when opening some drawings the documents are lightened and therefore the 'room bubble' is invisible (this is one of my drawing problems and I am looking for macro action to make the view solved)
Personally, I don't use any launch executable , I find it a bit too intrusive even if on some of my macros the application could be useful but they are only useful on old files and I think that I can't incorporate this kind of macro to existing files .
Back to the starting point/ according to all your remarks, what suits me best is a macro A integrated into the plan which asks when the plan is opened to execute a macro B present in a directory. This macro B should ask:
1: loading the plan and components in solved
2: Export the plan
3: Closing the Plan Without Saving
If I want to work normally on the plan, I delete macro B from its directory, which blocks the previous actions. I handle the error message "macro B not found" manually because it is an exceptional special case.
For those who find my request strange, I want to explain why, but I don't want it to turn this conversation into a battlefield to tell me if they think it's a good or bad idea. I have an excel file that modifies the custom properties of a room without having to open it. The geometry of the part is updated with the values of the excel. A simple click of a button should allow the publication of a plan of the room in pdf. All this so that the user does not have to use solidworks.
Thank you but it's not going to be suitable for my application. I will continue to work on the integrated macro solution that calls for the opening of other macros. For the moment it's skating
For those who find my request strange, I want to explain why, but I don't want it to turn this conversation into a battlefield to tell me if they think it's a good or bad idea. I have an excel file that modifies the custom properties of a room without having to open it. The geometry of the part is updated with the values of the excel. A simple click of a button should allow the publication of a plan of the room in pdf. All this so that the user does not have to use solidworks.
It would therefore be enough on your excel button to program the opening of your part and your plan in solidworks, to export your folio plan 1 in pdf and your folio plan 2 in jpeg. Then close the part and the assembly. All this while coding in excel.
Here is a piece of code that from excel opens a room and an MEP, I just tested out of curiosity and it works perfectly.
Sub EssaiSW()
Dim swApp As SldWorks.SldWorks
Dim swModelUn As SldWorks.ModelDoc2
Dim swModelDeux As SldWorks.ModelDoc2
If swApp Is Nothing Then
Set swApp = CreateObject("SLDWORKS.application")
swApp.Visible = True
Else
Set swApp = Application.SldWorks
End If
Set swDocSpecification = swApp.GetOpenDocSpec("C:\Users\sebastien.denis\Desktop\Pièce5.sldprt")
Set swModelUn = swApp.OpenDoc7(swDocSpecification)
MsgBox swModelUn.GetTitle
Set swDocSpecification = swApp.GetOpenDocSpec("C:\Users\sebastien.denis\Desktop\Pièce5.slddrw")
Set swModelUn = swApp.OpenDoc7(swDocSpecification)
MsgBox swModelUn.GetTitle
swApp.CloseDoc swModelUn.GetTitle
Set swModelUn = swApp.ActiveDoc
MsgBox swModelUn.GetTitle
Set swDocSpecification = swApp.GetOpenDocSpec("C:\Users\sebastien.denis\Desktop\Pièce6.sldprt")
Set swModelDeux = swApp.OpenDoc7(swDocSpecification)
swApp.CloseDoc swModelUn.GetTitle
MsgBox swModelDeux.GetTitle
swApp.CloseDoc swModelDeux.GetTitle
End Sub
Thank you @d.rogerfor this code available elsewhere in my link above.
Then there is no more to export the pdf and the jpeg. Which is largely achievable and should be fairly straightforward.
Unless of course I still miss a point?
For your information, the built-in macros for having tested several of them are complicated to implement and remain dangerous, not to mention the crashes with them.
I am of the same opinion that @sbadenis macro incorporated into the plan/room I have never practiced but it seems to me that it is quite complex and I find it too 'intrusive'.
Since you start from an excel file where you fill in the dimensions to be modified I think that the simplest remains an excel macro button that sends worked on Solidworks.
The button can allow you to open the room, fill in the dimensions, open the saved plan and then close, or continue to work by modifying the dimensions and then save again if you have a side table which can save you a few seconds each time you open/close.
If you want to avoid your users using Solidworks I think it's the best solution. You may quickly be annoyed if you have to change a plan and you forgot to move the macro, or if Solidworks opens a window for you every time you modify/create a plan saying that it didn't find the macro without mentioning the possible errors/bugs of Solidworks.
Otherwise, if I understand your request correctly, you would like the user to click on the DRWG file of the part in Windows Explorer. Solidworks opens this plan , correlates with the open excel file , updates the data and then automatically saves/closes the plan without the user seeing it.
I'd still like to try the built-in macro, if it doesn't bother you too much.
Can you explain to me what is the method to merge this macro that launches an action when opening a file, with this macro that executes a series of macros?
Plus, it's super simple to deploy on a series of documents.
I struggled a bit with the references to activate, but it's progressing well.
I still have a small bug: the "exortPDF" macro called pat the integrated macro crashes on the file path recovery, while if I run it manually it works.
It seems that it's because the "exportPDF" macro starts before the solid file is fully loaded (the error window offers me the debugging, but the solidworks file doesn't appear) Is it possible to put some kind of delay to see if that's it?
I had the same problem, impossible to launch an external macro with the method it offers and I didn't have time to dig into the subject.
I just managed to launch one try with this:
Option Explicit Dim swApp As SldWorks.SldWorks Dim boolstatus As Boolean Sub main() Set swApp = Application.SldWorks Dim runMacroError As Long boolstatus = swApp.RunMacro2("path", "module", "name", 1, 0) End Sub
I also changed 'swRunMacroUnloadAfterRun' to 1 and 'runMacroError' to 0
[ Unfortunately, it doesn't work anymore... The changes you make only affect the handlermodule, but it's in the other module that it gets stuck...] Error resolved
I replaced the content of the handlermodul with what you offered me, it still doesn't work. I still get the error message at the macro called by the andlermodule while the plan is not yet displayed in SW. If the macro tries to export a plan that is not yet open, it's not surprising. But I thought that the handlermodule was only triggered once the plan was completely loaded...
By the way, I don't understand what you mean by "I also replaced 'swRunMacroUnloadAfterRun' with 1 and 'runMacroError' with 0"
This macro works for me but indeed after trying it launches the requested macro before the document is displayed in SolidWorks so the macro must be launched before the document is displayed, you have to find another macro to make this kind of request.
By the way, I don't understand what you mean by "I also replaced 'swRunMacroUnloadAfterRun' with 1 and 'runMacroError' with 0"
It's just to simplify the reading on the forum. But it's the same thing.
In my opinion the solution would be to open the document, the past in solved, rebuild and then run this kind of macro
But concretely I think it would be easier to work only in excel for this kind of thing.
Totally agree with @mandragorethis kind of macro becomes a problem very quickly because it's impossible to know if it's launched when it needs to or not, and no feedback if it runs well or if it just started and then bugged. Launching a macro from a macro to have already done it is not great.
And since a macro feature, it's even worse and may make you change your mind quickly, believe me it's experienced, I've been there before, I tested the 2 with a quick rewind due to many problems.
The goal is to generate this PDF plan automatically from a web platform. So by definition, it will be fully automatic. if an incident prevents the creation of the PDF, I think I can be alerted at a level other than SW.
It is possible to attack the API in C++. I haven't found a topic on this forum. Do you know how well it works?