Here is a macro starter that I wrote for creation of the macro launching addin mentioned earlier. It would allow novice to intermediate macro writers to easily trigger their macros by SolidWorks events.
To use it, put the macro path, module name, and procedure name in the EventAssignments.MDB file in the EventList table for the event you want to trigger the macro. Of course, you will have to tell the macro where the mdb is, either by changing the constant at the top of the form code or by hitting the "Update Path" button on the form itself.
I'm guessing the addin will have to store the data file path in the registry?
Following are some limitations:
1. Running the end-user's macros uses the SldWorks::RunMacro function, which doesn't allow any passing of the arguments generated by the events.
2. Actions (such as saving) can't be cancelled because the user's macro can't return any value to the addin. Cancelling an event-triggered action requires some value to be set in the event's code.
3. An error caused by a user's macro will crash the main macro. Not sure if changing to and addin will fix this, but I'm hoping it will.
4. Only events for the application and part/dwg/assembly document objects are handled. Mostly because other objects' events are beyond the beginner/intermediate level.
5. There is a Busy flag as vbSpawn suggested. However, Any non-modal macro that is launched (e.g. one with a form) allows the main macro/addin code to continue running, which sets the Busy flag back to False. There's no way to determine if a user's non-modal macro is finished running. If the user's macro is non-modal and triggers events by its own running, those events will be seen by the main macro/addin.
I'm sure there may be others, but this is a start.
Comments?
![[soapbox]](/data/assets/smilies/soapbox.gif "[soapbox] [soapbox]")
.![[cheers]](/data/assets/smilies/cheers.gif "[cheers] [cheers]")
