Results 1 to 3 of 3

Thread: [VB] Form_Load is NOT a proper program entry point

  1. #1

    Thread Starter
    I'm about to be a PowerPoster!
    Join Date
    Jan 2005
    Location
    Everywhere
    Posts
    13,647

    Arrow [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:
    1. Public Sub Main()
    2.  
    3. 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.

  2. #2
    Admodistrator |2eM!x's Avatar
    Join Date
    Jan 2005
    Posts
    3,900

    Re: [VB] Form_Load is NOT a proper program entry point

    Is there a speed advantage?

  3. #3

    Thread Starter
    I'm about to be a PowerPoster!
    Join Date
    Jan 2005
    Location
    Everywhere
    Posts
    13,647

    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
  •  



Click Here to Expand Forum to Full Width