|
-
Oct 3rd, 2005, 01:54 AM
#1
[VB] Form_Load is NOT a proper program entry point
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
VB Code:
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.
-
Oct 5th, 2005, 08:42 PM
#2
Re: [VB] Form_Load is NOT a proper program entry point
Is there a speed advantage?
-
Oct 6th, 2005, 03:17 AM
#3
Re: [VB] Form_Load is NOT a proper program entry point
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.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|