VBA: Exit SW event

I found and successfully used an event called "DestroyNotify". If you look that up in the help, you should find how to use it. It's been to long since I did it, so I really don't remember.

I'm not sure what I am doing wrong. I know that I am keeping the swApp object because other events are working such as swApp_FileNewNotify2

Public WithEvents swApp as SldWorks.SldWorks

Private Function swApp_DestroyNotify() As Long MsgBox "Corey, SolidWorks is closing!" End Function

I tried to modify the example that is on the Sw website to do this too but I got nothing. Confucious say "I confuse"

Corey

you need to create a solidworks dll add-in. then you can capture the destroy notify event. you can also capture solidworks load to do things like add toolbars and drop down menu's. so look into "solidworks add-in" in the solidworks api help file.

snipped-for-privacy@hotmail.com (Sean Phillips) wrote in news: snipped-for-privacy@posting.google.com:

Mine is a stand-alone .exe that captures the DestroyNotify. I don't have VB6 installed right now, so I can't look up how to do it. If necessary, I can install it later this weekend to look at it.

I thought it should work from VBA. You see SolidWorks put a VBA example on their website for events, one of the events on their example is clearly the SldWorks::DestroyNotify (). So my question is: IF THIS DOESN'T WORK WHY DO THEY GIVE IT AS AN EXAMPLE?????????????????????? I would write an .exe but I don't have VB6. Quick question. Do any of you know if I get VB6 will it require alot of rewriting to convert VBA macros into VB6 applications.

Thanks Corey

They often mix VBA and VB. I found several examples that won't run when compiled, others that don't work as macros... One thing is sure : event handling won't run in macros. You should consider that VBA macros do not "live" whiloe they aren't explicitely run. Event handlers require a process or task to run "in parallel" with SolidWorks, such as a separate .exe or an add-in (dll).

No, it's pretty straightforward as VBA is a subset of VB

Would you recommend VB.net not that 2004 supports .net add-ins? As I recall, it's a lot cheaper than VB 6.0, and updated too.

VB.NET is quite different from VB6, and from VBA. I'd say the future of VB.NET isn't clear yet. There is a HUGE amount of existing VB6 code around and many developers prefer to switch to C# rather than VB.NET... I'd also wait to see how SW macros evolve (does anyone know their projects about this? Python ? ;-)

cheaper ? mmmh.... I paid roughly the same price for both. I love products that aren't updated anymore : they're finally reliable. (or dead...)

Actually I have been able to Handle Events such as new document and such during an entire session of SW. The only things I was unable to handle were the opening and closing of the session itself. It makes sense to me that with a macro that you wouldn't be able to watch for startup but according to the documentation you should be able to watch for shutdown. It says that it pre-notifies, well I guess it pre-notifies after stopping all macro processes, this seems silly to me.

"Pre-notifies the user program when the application is about to be destroyed."

Anyway I was able to handle some just not all. The only reason I really wanted to do this is so I could stay attached to a session of excel and close it with SolidWorks, just to make things run a bit quicker.

Corey Scheich

VBA is a choped up version of VB6.0 its missing a lot of stuff. I feel that .net is very new and finding help online will be hard. and if you dont know c++. there is no need to upgrade to .net so fast.

As I have been working very actively using .Net technology along with both VB and C#, I would like to correct some misinformation:

2) VB.Net is not going away. There are not any plans for Microsoft to have that happen. I am now working for a Microsoft Certified Partner and I have been taking my tests for MCAD certification so I have been very involved with this technology.

I am only hoping to help ease the anxiety.

Best Regards,

Bob Hanson Centare Group, Ltd. - Custom Software and Systems Integration Specialists

Corey,

The SW API documents that the SldWorks.DestroyNotify event is not sent for COM-based DLL add-ins:

"SolidWorks sends this event to an MFC-based DLL add-in when SolidWorks is about to be destroyed. This is a pre-notification. Add-ins should perform any cleanup inside this event."

...

"This event is only sent to MFC-based DLL add-ins; it is not sent to COM-based DLL add-ins. Use SwAddin::DisconnectFromSw to perform any cleanup of COM-based DLL add-ins."

I use C++ for my COM dll addins, and cleanup using SwAddin::DisconnectFromSw because SldWorks::DestroyNotify never gets sent. I guess that it should work OK for VB6 based COM dlls too. Maybe, VB6 based exes are different - the API documentation does not mention them. I know that up until SW2003 at least COM DLL add-ins were destroyed earlier in the shutdown sequence than MFC based DLLs, so I guess that the SldWorks COM object was already dead when SolidWorks wanted to send the 'pre-notify'.

VB.NET is essentially VB7 that is what I read in a VB.NET book.

Thank you all for your input.

Corey Scheich

SwAddin::DisconnectFromSw