CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 4 of 4

Hybrid View

  1. #1
    Join Date
    Aug 2003
    Location
    Sydney, Australia
    Posts
    1,900

    The use of NEW and Standard Modules

    Finally starting some coding in VB.Net
    I notice over the years, that we can say (in VB6)

    Code:
    Dim MyForm_Stock as NEW frmStock
    I have never really understood 100% what this does (other than create a form which can be used)

    Could someone please explain how this helps me in terms of the same person, in the same session, being able to open, say 3 Stock Forms at the same time and maintain details independantly of each of the other forms

    Also am I able to maintain separate Database connections and the same table being opened and updated independantly of each other by each separate form

    What is actually taking place in terms of memory being used by each process ?

    My ultimate goal is to be able to have ONE Module with all the possible data Connection and Recordset Opening and closing options, which I have failed miserably to do in my VB6 experience. Data access is an obvious module based set of subroutines. Others could be Date routines eg, Week Number of the year, Days Diff, Days to, etc. various other subroutines - any good ideas ?

    eg, For Data
    Make Database (Pass a string)
    Make Table (Pass a string for name and Fields)
    Open Database (Pass a string)
    Open table (Pass a string or SQL Statement)

    etc

  2. #2
    Join Date
    Jul 2000
    Location
    Milano, Italy
    Posts
    7,726

    Re: The use of NEW and Standard Modules

    ***edit: have been a bit too prolisse, I admit
    Thus in short:
    first take a look at Disconnected way to interact to db
    then make a small search for "Shared" and for "Singletone Pattern", if you really want the single centralized dal object
    then be careful: centralized Dal with datatables is not always considered the best way of doing stuff - you have also other choices.
    You could dreply that I pointed you there. Yes, I did: that is still the easiest way to start, coming from Vb6 and a connected model. This new long post of mine ois meant to expand - fill free to disregard what you do not like...
    If you need a more precise (or focused) and concise answer, say it.

    --------------------------------------------------------
    Introduction:
    --------------------------------------------------------
    The classes (or forms, or controls,or any reference type
    except strings which are a special case as they are unmutables and have thus their own rules)
    we write are the basis for the objects we commonly use.
    To use the objects, we instantiate them with the new keyword.
    Even when dealing whit modules (or nowaday "sealed static class" or "shared not inheritable class")
    , which apparently do not require instantiation, as it seems you could use them directly via their
    module (or class) name, there is an hidden instance under the hood of wich the virual machine (or the
    runtime) takes care.
    --------------------------------------------------------
    Approaching the sintax and what is behind in VB6:
    --------------------------------------------------------
    In vb6 we got a couple of ways to do what seemed (but was not) same thing:
    Code:
    Dim MyForm_Stock as NEW frmStock
    and
    Code:
    Dim MyForm_Stock as frmStock
    set MyForm_Stock = New frmStock
    The difference between the two ways is impoprtant:
    in the first case we get what is called an autoinstantiate variable:
    wherever MyForm_Stock is first used, it will be instantiated if it is nothing.

    This meant you could forget to code
    Code:
    set MyForm_Stock = New frmStock
    but also you could forget to code the important
    Code:
    set MyForm_Stock = Nothing
    Depending on how your code was written, forgetting the last could have lead to
    a lack in release references, thus in a lack to release resources and to really
    free your program. Not only, but the Autoinstatiate varaibles (first line of code
    up there) could lead to subtle bugs: if you want to test if a variable is instatiate
    or not, you could test for

    If MyForm_Stock Is Nothing
    but if it is an autoinstatiate variable, that check could instantiate it...

    Moreover, you could try to close an autinstantiate form. But if it were nothing,
    while trying to close it, it would be instantiate.

    This is why autoinstantiate variables were looked with extremely suspect from
    vb6 seniores, at a point that some of us required from juniores to forget that
    sintax...
    --------------------------------------------------------
    Going to modern days: Net revolution
    --------------------------------------------------------
    You might have heard nowaday that with the Net revolution related to the undeterministc
    way objects (=refereces) are released, even if you can have aautoinstantiate variables,
    no senior will anymore cut your right hand if you code them.
    That is because of there is no real way to "impose a deterministc finalization to objects"
    (saing it the easy way: the
    Code:
    set MyForm_Stock = Nothing
    part is no more
    really required). You still have to take care of what now are called unmanaged resources,
    that is: if an object expose the Close and or the Dispose method, you should call them
    (the dispose as last) when you're done with it.

    By the way, you could also implement the Dispose, and make calls to the Garbage Collector
    to try to impose a finalization process when you want, but this is a complex argument and
    for the present we might postopone it.

    Let's simply note that nowaday we do not have the "set" keyword anymore:
    whe cannot code:
    Code:
    set someVar = new someClass
    but whe can code
    Code:
    somevar = New someClass
    we cannot code
    Code:
    set someVar = Nothing
    but whe can code
    Code:
    somevar = Nothing
    about this last:
    setting something to nothing in vb6 "usually" released the reference (that means: if no matter happened, the counter of the references fo that object would have reduced by 1 and if it reached zero, the heap woulkd have been cleaned)
    setting it now in net, simply make your software lose the pointer to the heap, but this does not mean the heap will really be cleaned...

    -----------------------------------------
    instances and signletons
    -----------------------------------------
    Nowaday, if you are really intentioned not only to have a single place for code, but also to have a single variable in memory for all the instances of one or more forms inside your program, you could have a look at "Shared" keyword in vb net. That should lead you to something similiar to the Module of Vb6, which is a Shared NotInheritable Class. But if you want to go a bit deeper, you should know our new way of saying:
    "Shared objects are often evil" and seniores will start looking at your right hand. Do a small search fro Singletone Pattern: it might help you survive those horrible elder people...
    -----------------------------------------
    Final note:
    -----------------------------------------
    by the way
    >ONE Module with all the possible data Connection and Recordset Opening and closing options
    It is not said this is really a good way of doing the job:
    even if it might appear logic and even consequent to a lot of books that speak of "centralization of logic and code",
    remember we have a lot of way of doing the stuff. For example, we surely should have a single place to store our connectionstring, but not the connection object per se - usually we have a base class for this.
    But we do not struggle to have really a single instance of it, as we could have derived classes which in practice open their own connection to db when instantiated. This makes sense as the way to connect , retrieve, insert, update, delete to and from a db has changed from a connected to a disconnected model, which thing also implies you should release the connection as soon as you can or you will risk to create unwanted locks on db objects
    Moreover, there are patterns where objects should take care of communications with db: instead of having a module where you go to update you "Customer" or your "Article" object, you could have the "Customer" and the "Article" object take care of their communication with db...
    Last edited by Cimperiali; March 19th, 2012 at 12:15 PM.
    ...at present time, using mainly Net 4.0, Vs 2010



    Special thanks to Lothar "the Great" Haensler, Chris Eastwood , dr_Michael, ClearCode, Iouri and
    all the other wonderful people who made and make Codeguru a great place.
    Come back soon, you Gurus.

  3. #3
    Join Date
    Aug 2003
    Location
    Sydney, Australia
    Posts
    1,900

    Re: The use of NEW and Standard Modules

    Code Guru is such a better place with you on the board Cimperiali - I have admired your dedication and patience for years, and always love to read your posts. Thank you for being there for us all !

    I have followed your advice and am exploring the story of ADO vs ADO.Net and have come across this gem of an article which may be of help to others facing the same dilemma as myself

    http://msdn.microsoft.com/en-us/magazine/cc163954.aspx

    Cheers

  4. #4
    Join Date
    Jul 2000
    Location
    Milano, Italy
    Posts
    7,726

    Re: The use of NEW and Standard Modules

    Nice article (not to speak of your kind words)

    I also found something on that subject for those who would like to read:

    http://msdn.microsoft.com/en-us/library/ms971478.aspx

    and as per using ado.net as a starter:
    http://www.codeguru.com/vb/gen/vb_da...cle.php/c15033

    http://www.vbforums.com/showthread.php?t=466658

    and as per introducing entity framework
    http://www.vbforums.com/showthread.php?t=540421

    but might be this guide to MS samples is really what many might need:
    http://blogs.msdn.com/b/jmeier/archi...ollection.aspx
    ...at present time, using mainly Net 4.0, Vs 2010



    Special thanks to Lothar "the Great" Haensler, Chris Eastwood , dr_Michael, ClearCode, Iouri and
    all the other wonderful people who made and make Codeguru a great place.
    Come back soon, you Gurus.

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

Featured