Forms in Solidworks VBA Editor

Swartzy,

You need to load the form before your show it. You will also need to unload before hiding it.

In the Module to call the form:

Load frmMyForm frmMyForm.show

and in the Form at the end:

frmMyForm.Hide Unload frmMyForm

Enjoy,

Matt

> I have a pretty extensive macro written in the VBA editor w/ one form

Interesting... I tried that. However... it was before I exported the form. Does the form in fact have to be exported?

Thx, Eric

Tried it again... still no luck.

I remeber having a problem at one point with the macro starting out in the wrong part of the program and thus skipping over some important code. The "main" routine needed to be at the bottom of the macro code to get it to start there.

I'm an novice VBA user so this may be way off base, but I had a problem with it at one point. I have a macro that I use daily that loads a form for user input just like fcsuper described...load it then show it.

MHill

I've written macros that use forms w/ no problem. Some examples available at .

For some reason, sometimes the position of "Sub Main" makes a difference. It sometimes needs to be at the very bottom of your code module.

Swartzy,

Without seeing the code, it is hard to tell. There's a lot of things it can be. Can you upload the macro somewhere so we can look at it?

Ideas so far:

The module that you think is supposed to be opening the form is different from where it actually is. Solution: Find it and fix the issue there.

As noted by others, your macro isn't starting from the correct Sub. Several solutions: Move "main" to the end. This doesn't always work, but worth a try. Also, if possible, turn other subs into functions instead. Many times macros are unnecessarily using "Sub" instead of "Function" for subroutines.

Make sure your Calls between subroutines are logically set up (things are happening in the order you intend them to).

Also, if it is running from the editor, but not live, then make sure you are running the macro from the module sub Main, and NOT from the form itself. VBA will allow you to run a form by itself without the module code. This could be creating the illusion of a functioning macro when it really isn't.

Check to make sure you have the Microsoft Forms reference library loaded in the macro, otherwise forms will not. Also, make sure you don't have any unnecessary libraries loaded which may interfer with the function of the macro.

Just some ideas. I hope they help.

Matt

Thanks for all the input. For what it's worth... the main subroutine is actually in a module all by itself. I suppose that could be part of the problem, but if you can't seperate out your subs to different modules then what's the point?

I ended up compiling it to an .exe in VB6 and it works fine that way. It seems more stable as well for one reason or another... I was randomly getting "Server Threw an Exception" errors when trying to close a drawing after processing it. It also does a better job of updating the form (w/ what's going on) then when run as a Solidworks macro.

I'd say your best bet is trying to "Divide and Conquer" the problem. Make a simple macro with a form and get that working and slowly introduce copies of your code until you see the behavior in your full macro.

I'm currently combined a few macros I had and made a gui interface right in Solidworks's VB. It has a module I called "main" with a subroutine called "main." The main sub just says formName.show and from there you should be able to handle the rest.

Ben

It has been a while since I have used VBA with SW but it seems like I ran into an issue that the code wouldn't work properly if there was a minor error. But, instead of reporting the error and stopping the VBA just skipped over some of the code, (something like this). The way that I found and fixed these problems was to move the code over to VB6. As a result I quit using VBA. Just too many limitations and problems.

As far as VB6 I was very reluctant to switch over to VB.NET, (put this off for several years). When I finally did change over I really regretted not doing so much sooner. There are some slight differences in thinking but for the most part .net is what one would expect. But, there are TREMENDOUS improvements in .net. The interface works better, errors seem to be much easier to find and correct etc. There are so many subtle improvements that the over all effeceincy with it is much better even when learning a new piece of software. And if you startout with Visual Studio 2005 MS has made considerable progress with "automating" many of the coding functions. This means that just by dragging many of the tools into your project that a fairly amount of code is automatically inserted and all that is often needed is to fill in a few properties.

Hope this helpes,

Ed

Try triggering your macro from the macro toolbar with a button pointing to your "Sub Main".

If you moved "Sub Main" from its original module (or renamed the module) that can cause issues. I don't know why, but sometimes it just does.