PDA

View Full Version : Controlling Form Load at Startup



dalej_k
2004-09-16, 05:29 PM
What is the best way to control the loading of a VBA form when AutoCAD is first opened.
In this case I do not want it to load all the time, only if specific conditions are met.

The form gives users a choice of menus to load. I have it loading successfully when AutoCAD is first started by using:

(VL-VBALOAD "R:\\....\\Menu.dvb");initializing vb
(vl-vbarun "MenuSelect")

in my acad.lsp file.

Users can also enter AutoCAD by shortcuts. The shortcuts call scripts which load the appropriate menu. In this case, I do not want the Form to load.

Is there a simple way to do this or is it best to use a system variable or store data in drawing , with extended entity data or registry.


Thanks!

Ed Jobe
2004-09-17, 02:33 PM
What about loading profiles instead of menus? Since a profile stores the loaded menus, you wouldn't need to do any menu selection. Just start acad with the /p switch and specify the profile.

dalej_k
2004-09-20, 06:18 PM
Loading menus is more flexible as the menu can be loaded independantly of the entire profile. I have used this approach for several years without any problems. The support file search path is the only part of the profile that needs to be controlled.

In this case I think the sequence of events is throwing me off.

I may experiment with form show and hide properties. It may be obvious, but I can't figure out, how to indicate to the VBA app that the script has been run and the menu loaded before it activates.

Thanks for your input!

Ed Jobe
2004-09-20, 06:27 PM
If you insist on having the user manually configure their menus instead of using profiles, try this. Create a dvb called acad.dvb. This will act just like acad.lsp, it loads automatically, once at startup. Then in a public module (its name in not important), add a public sub called "ACADStartup()". Add code here that does your form loading and whatever other startup you need and it will be run automatically at startup.

dalej_k
2004-09-22, 11:09 PM
Users are not manually configuring their menus, paths to menus are programmed into the registry with Visual LISP. Profiles are superflous for this.

I think the problem is the sequence of loading. The acad.lsp file loads the VBA app first then the script is loaded from the shortcut. When vba app is loaded, user can select which menu to load , if script is loaded, menu should load automatically. At this point I need to turn the VBA ap off.

Most likely I am lacking in knowledge of VBA.

I tried the acad.dvb but will check into it again.

Ed Jobe
2004-09-23, 02:28 PM
I meant "manual" in the sense that they have to pick which menu/s they want. With profiles, if you are going to work in an arch environment, for example, you set everything up the way you want, save it as a profile, and then configure a desktop shortcut to start acad with that profile. Now all the user has to do is start acad and everything is the way they need it automatically.

As far as acad.dvb goes, the suggestion implied that you get rid of all phases of your previous method, e.g.

Sub ACADStartup ()
'load form for choosing menus

'If your menuloading app is small, you may choose to just
'move it to acad.dvb. Then you can use the following to call it.
Dim frm As Form_MenuChooser 'or whatever you called it
frm.Show

'Otherwise you will have to load it here.
'RunMacro syntax: ProjectFilePath!MacroName
AcadApplication.RunMacro("c:\AcadCustom\support_GS\utils.dvb!AutoStamp")

'The form should have a Close/Done button that includes "Unload Me".
'When the form is unloaded, your "app" is terminated and execution returns here.
End Sub

ntaylor
2004-09-24, 12:12 AM
I meant "manual" in the sense that they have to pick which menu/s they want. With profiles, if you are going to work in an arch environment, for example, you set everything up the way you want, save it as a profile, and then configure a desktop shortcut to start acad with that profile. Now all the user has to do is start acad and everything is the way they need it automatically.
Hi Ed
His current setup is that the user can select a shortcut which does load the correct menu using a script. The problem is that if the user does not select one of the shortcuts he wants them to be forced to choose which menu. He can write code to do this but the problem is it would also run if the user selected one of the shortcuts. If he used shortcuts with a switch to a profile he would still want the user to be forced to select a profile if they did not use a shortcut.
Regards - Nathan

Ed Jobe
2004-09-24, 02:19 PM
After several back-and-forth posts, I forgot about that part. He could have the script set a OS environment variable. The vba form could check it before running, if set it doesn't show the form and then resets the var for next time. If its not set, it loads the form. I still would go with keeping the vba in acad.dvb.

dalej_k
2004-09-24, 08:02 PM
Ntaylor has perfect grasp of the task outlined.

Acad.dvb, I think is too limiting and does not resolve the sequencing of events. I am not having a problem getting the form loaded and showing it, which is the point of acad.dvb.

Unfortunately, form prevents the script from running until user interacts with form. Then the script runs and is superflous.

The problem is that the script is called from the shortcut after the form has loaded.

if I resolve this, will post solution. I don't advise mixing scripts run from desktop shortcuts with:-( vba forms at load!

Ed Jobe
2004-09-24, 08:53 PM
I can't think of a solution at this moment. The problem is that the script is always going to run last. The only thing I can think of at the moment is add to the shortcut that doesn't run your setup scripts and have a script that runs the dialog macro.

dalej_k
2004-09-25, 04:11 AM
It is a tough one. I think the users are going to scrap the shortcuts. They are really not needed. At least, everyone who posted has helped me to determine that this is not an efficient option.

Thanks to all!

richard.binning
2004-09-25, 05:26 PM
What is the best way to control the loading of a VBA form when AutoCAD is first opened.
In this case I do not want it to load all the time, only if specific conditions are met.

The form gives users a choice of menus to load. I have it loading successfully when AutoCAD is first started by using:

(VL-VBALOAD "R:\\....\\Menu.dvb");initializing vb
(vl-vbarun "MenuSelect")

in my acad.lsp file.

Users can also enter AutoCAD by shortcuts. The shortcuts call scripts which load the appropriate menu. In this case, I do not want the Form to load.

Is there a simple way to do this or is it best to use a system variable or store data in drawing , with extended entity data or registry.


Thanks!
Hey Dale,

Since you are willing to use lisp and VBA, why not just keep your loading mechanism as shown above and simply check the menugroup prior to calling it. If your menugroup name is "Productivity" then the following could be used in your acad.lsp (although, I think I would put it in the acaddoc.lsp instead.)



(if (menugroup "Productivity")
(prompt "\nProductivity Menu found...")
(progn
(VL-VBALOAD "R:\\....\\Menu.dvb");initializing vb
(vl-vbarun "MenuSelect")
;;; You could unload your VBA routine here if you want
);end progn
); end if

Nothing hard about that...unless I missed something???

dalej_k
2004-09-25, 06:21 PM
Richard:

I tried this yesterday, using Visual LSIP to check for all menu groups in both the acad.lsp s::Startup and also the acaddoc.lsp. In this case the acad.lsp loads, finds the menugroups are not loaded and loads the VBA form. Fine, this is a good backcheck.

However, if run thru the desktop shortcut with a b switch to load a script. The steps above occur, and then the form hangs, waiting for user input. If user inputs, ie, hits a command button, then the vba form runs and then the script runs.

I think that running an autocad script in a shortcut is the problem.

Thanks, I really appreciate all suggestions.

Dale

dalej_k
2004-11-22, 06:26 PM
For any one who needs this info, I resolved this problem by loading a switch function in the acad.lsp which reads an external file with user logon data. The dialog box can be turned on or off by specific users. If switch is active then the form is hidden.