PDA

Click to See Complete Forum and Search --> : [VB] Form_Load is NOT a proper program entry point


penagate
Oct 3rd, 2005, 01:54 AM
When you start a program, after performing some various management tasks the Windows PE loader calls your application entry point procedure. This is where your application begins.

By default, Visual Basic assigns a "startup object", usually Form1. This is a very bad design because it leaves you with no control over the startup process. The form is loaded whether you want or not, and your code begins effectively in Form_Load().

Instead of leaving it be, go into Project -> Properties and select "Sub Main" as your startup "object". Make a new standard (.bas) module and enter the following stub in
Public Sub Main()

End Sub


Your code now begins in that procedure, before any forms or objects are instantiated. Also by using the runtime Command$() function you can retrieve the command-line arguments that are passed by the Windows loader.

|2eM!x
Oct 5th, 2005, 08:42 PM
Is there a speed advantage?

penagate
Oct 6th, 2005, 03:17 AM
It depends, but using Sub Main can give you a speed advantage if using references to form objects. If you let VB manage your forms for you you end up with loose-bound references to every form. You can call Form1.Show and it will load Form1 if it has not yet been loaded. This does slow things down slightly if you reference forms that way because on every call VB has to check whether the form has been loaded or not. If you do it yourself you can use strong binding and pass references to form objects as needed. Also, it is preferable anyway to pass references to forms to abstract procedures, rather than hardcode the form names into the method body, as that keeps your code reusable and more readable.