VBA: Exit SW event

I want to catch an event at the exit of a SW session, I can't get it to work

Ok in SolidWorks Objects/ThisLibrary
there is a Workspace_Exit event. so I added this code to check it out

Private Function Workspace_Exit() As Boolean
MsgBox "You are exiting SolidWorks"
End Function

Nothing

I presume that I need to set the workspace object but to what I also checked
into using

Public WithEvents swApp as Sldworks.Sldworks

but there is no exit event just open and close of documents.
Does anyone have any insight, thank you

Corey Scheich

 

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.

 

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:estroyNotify (). 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

 

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.

 

Bob Hanson Wrote:

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

1) SolidWorks 2004 API SDK does give you development project templates for
both VB.Net and C#.

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
http://www.centare.com

 

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:isconnectFromSw to perform any cleanup
of COM-based DLL add-ins."





I use C++ for my COM dll addins, and cleanup using SwAddin:isconnectFromSw
because SldWorks:estroyNotify 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