PHP User Warning: fetch_template() calls should be replaced by the vB_Template class. Template name: bbcode_highlight in ..../includes/functions.php on line 4197

PHP User Warning: fetch_template() calls should be replaced by the vB_Template class. Template name: bbcode_highlight in ..../includes/functions.php on line 4197

PHP User Warning: fetch_template() calls should be replaced by the vB_Template class. Template name: bbcode_highlight in ..../includes/functions.php on line 4197

PHP User Warning: fetch_template() calls should be replaced by the vB_Template class. Template name: bbcode_highlight in ..../includes/functions.php on line 4197

PHP User Warning: fetch_template() calls should be replaced by the vB_Template class. Template name: bbcode_highlight in ..../includes/functions.php on line 4197
The Definitive "Passing Data Between Forms"-VBForums
Page 1 of 2 12 LastLast
Results 1 to 40 of 48

Thread: The Definitive "Passing Data Between Forms"

  1. #1

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    The Definitive "Passing Data Between Forms"

    After seeing so many of these types of questions, I thought that coming up with one definitive answer was a good idea. Kleinma seemed to agree, so I started rooting around in the database looking at the patterns that this type of question took, and I came up with three general forms of the question. I don't know whether I have enough information to create an ultimate answer, so I thought I would put out what I have found so far, and ask people for comments and inputs:

    1) How do I transfer data between Form1 and Form2.

    This is actually not that common a question, which is probably because the answer is straightforward. There are three types of general answers.

    a)The first type would be to add public member variables to either Form1 or Form2. In either case, any code that sees either Form1 or Form2 can read the variables directly. I'll say no more about this answer, because it is quick, but not a good habit to get into.

    b)A better solution would be to add PRIVATE member variables to one of the forms, and make them accessible through properties:

    vb Code:
    1. Public Class Form1
    2.  
    3.    Private myInteger as integer
    4.  
    5.    Public Property myInt(value as integer) as integer
    6.      Get
    7.        Return myInteger
    8.      End Get
    9.      Set
    10.        myInteger = Value
    11.      End Set
    12.    End Property
    13. End Class

    This solution adds a bit more code than just making the variables Public, and there is no advantage to this technique in the above example. However, by using a property, you have some control over what is getting passed in, and how it is being dealt with. A form is a class, and a class should be the sole owner and gaurdian of its data. The class itself should control what data is accessible, and how. By using properties, you can make members ReadOnly, WriteOnly, or open to all. You can also make the protected, which affects inheritance. Furthermore, you can use the Set block to restrict input values, and can use the Get block to resolve requests for things that are otherwise improper (like asking for item 10 in a 9 element array).

    In general, you can put the property on Form1 and have Form2 go get it, or put the property on Form2 and have Form1 push the data to Form2. Which you choose depends entirely on what makes sense. If Form2 is created by Form1, then it makes sense for Form1 to fill Form2 simply because Form1 is "creating" Form2. If Form2 is independent of Form1, then it makes sense that Form2, when it is created, goes and gets the data it needs from Form1.

    c) An alternative, if Form2 is being created by Form1 is to overload the constructor (the Sub New for the form) to either accept arguments that have the data, or to go get the data from the properties of other classes, as needed. The advantage of this technique is that it is a very clean way to create the form, and can be used to FORCE the correct initialiaztion of the form. If you overload the constructor with arguments, you could change the default constructor to Private, such that the overloaded constructor is the ONLY way to create the form. By doing this, you enforce the requirement (even on yourself) that the form be called with the correct arguments. Since these arguments can be the data pieces needed by the form, this will enforce the correctness of the form.

    If you use the default instance of a form, then you can't use the overloaded constructor technique to move data to a new form. The reason for this is that the default instance uses a default constructor which takes no arguments. Therefore, if you are using the default instance, use properties.

    Having said all that, I should repeat that this form of the data transfer question is relatively rare. MUCH more common is this:

    2) I want to move data from Form1 to Form2, but when I do, the data isn't there, even though I can see it. What is wrong?

    This isn't actually a data transfer issue at all, but a fundamental misunderstanding about variables. I suspect that this problem is worse for people coming from VB6 to .NET, and for users of 2005 rather than 2003, because of the default instances in both VB6 and 2005.

    When a variable is declared:

    Dim myForm as Form1.

    That line instructs the compiler to set aside sufficient memory for an object of type Form1. No actual form is created, and the memory, if you could see it, would be nothing but garbage. You create the form when you write the word New:

    myForm = New Form1

    This tells the compiler to create a new instance of the object called Form1, and put this object in the memory called myForm, which was previously set to the size needed to hold a Form1. It is the New statement that fills the garbage memory with an actual, orderly, instance of Form1.

    The problem that people seem to be having when they ask this form of the question is that they are creating a new instance of Form1, and expecting that it will have the data that is already found in an existing instance. However, the Dim statement is telling the compiler to set aside a totally new chunk of memory, and the New statement is telling the compiler to create an entirely new instance of the object. Naturally, a totally new instance is not the same as any existing instance, so when you look at the properties of this totally new instance, they will not contain the data that was added to an existing instance. Worse, if you don't actually use New, you won't have an actual object, but just some garbage chunk of memory of the right size for the object, but not an actual object.

    The solution in this case is to use the existing instance and not create a new instance. I have not come up with any general means to do this, as it depends entirely on the specific design. A few options are these:

    a) If the other instance was created at some other, earlier, time, then there will be a line like oldInstance = New Form1. Thus, oldInstance is the instance that holds the data you want, so don't create a new instance like dim f1 as New Form1, but use oldInstance instead. This may not be easy, because the existing program design might well have oldInstance delared in such a way that it is inaccessible to another form (it might be a private member variable, or it might be declared with function scope rather than class scope). The only way to fix this would be through changing the design so that the oldInstance is accessible, or by a fairly hideous workaround of putting the data from oldInstance into a different class that is visible to the instance of Form2, and getting the data from that intermediate class.

    b) If Form2 is being created from Form1 (e.g. a button click event creates the instance of Form2), then just add a property to Form2, and have Form1 populate it as described for the first form of the question, rather than having Form2 try to go and get the data from Form1 once it has been created.

    3)Passing data from Parent form to Child form in an MDI environment?

    This form of the question is pretty common, but takes many forms, as people seem to have different ideas of what is the parent and what is the child. Furthermore, I don't see any particular pattern to these questions, nor the answers to them. Also, I have no experience with MDI environments. Therefore, I need somebody else's input as to whether there is some comprehensive answer to this type of the question.

    Ok, there's my first pass, with minimal editing. I'd like some edits, suggestions, and etc.
    Last edited by Shaggy Hiker; May 3rd, 2007 at 04:33 PM.
    My usual boring signature: Nothing

  2. #2
    Fanatic Member Mr.No's Avatar
    Join Date
    Sep 2002
    Location
    Mauritius
    Posts
    651

    Re: The Definitive "Passing Data Between Forms"

    Quite some interesting bits here. When I need to pass data to and from forms I usually use a class object to hold all properties I need and have the forms exchange just one object instead of lots of properties.

    Secondly if I need to have a single instance of a form then I use the Singleton pattern where i use something like Factory.CreateForm() to ensure that only one instance of the forms exists across the application.
    Using VB.NET 2003/.NET 1.1/C# 2.0
    http://del.icio.us/rajoo
    Blow your mind, smoke gunpowder
    Ashes to ashes, dust to dust
    If God won't have you, the devil will. - Author unknown
    Don't follow me, I'm lost too ...

  3. #3
    Fanatic Member
    Join Date
    Aug 2006
    Location
    Chicago, IL
    Posts
    514

    Re: The Definitive "Passing Data Between Forms"

    I prefer to use a class object, as well, where I can access any of it's information from any form, rather than having to remember the specific form the variables are part of.

    For instance, all of my projects here at work contain a common class that is called by the Application name (such as UnifiedClass). Many of them contain similar variables and properties and enums and methods that I can use over and over again in each project with almost no modification. To do the same with forms would require me to import those forms, remove the code, add that code to the new forms, and then exclude those imported forms - far more work.
    Warren Ayen
    Senior C# Developer
    DLS Software Studios (http://www.dlssoftwarestudios.com/)

    I use Microsoft Visual Studio 2005, 2008, working with Visual Basic and Visual C#
    Hey! If you like my post, or I solve your issue, please Rate Me!

  4. #4
    Fanatic Member
    Join Date
    Aug 2006
    Location
    Chicago, IL
    Posts
    514

    Re: The Definitive "Passing Data Between Forms"

    Also, for MDI environments, the child form can use the:

    vb Code:
    1. Me.Parent

    This allows the child form to access the properties, controls, methods, and events of the parent form.
    Warren Ayen
    Senior C# Developer
    DLS Software Studios (http://www.dlssoftwarestudios.com/)

    I use Microsoft Visual Studio 2005, 2008, working with Visual Basic and Visual C#
    Hey! If you like my post, or I solve your issue, please Rate Me!

  5. #5

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Both good points, though the second one is somewhat irrelevant to passing data.

    However, I was considering this morning whether or not it is ever really justified to move data from a form to a class not in the form. I do have a program where the vast majority of the data does not reside in a form, but is held in a class external to all forms. The forms simply display data from the class. Of course, this is a special case, but the class could have been implemented as a member of one of the forms, though it would have had to be implemented as a shared member.

    Therefore, it appears that in some designs, it would make some sense for forms to pass data to an intermediate class from which all forms could draw, though as far as I can see, this is NEVER necessary.
    My usual boring signature: Nothing

  6. #6

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by warrenayen
    I prefer to use a class object, as well, where I can access any of it's information from any form, rather than having to remember the specific form the variables are part of.

    For instance, all of my projects here at work contain a common class that is called by the Application name (such as UnifiedClass). Many of them contain similar variables and properties and enums and methods that I can use over and over again in each project with almost no modification. To do the same with forms would require me to import those forms, remove the code, add that code to the new forms, and then exclude those imported forms - far more work.
    Congratulations, you have realized the promise of OO design. The major reason it was created was code re-use. This often happens when you make several similar programs, especially ones dealing with the same core set of data. Great efficiencies can arise.

    Oddly, I was writing about an intermediate class as this showed up, or else I simply overlooked it the first time.
    My usual boring signature: Nothing

  7. #7
    Fanatic Member
    Join Date
    Aug 2006
    Location
    Chicago, IL
    Posts
    514

    Re: The Definitive "Passing Data Between Forms"

    It depends on the project:

    For instance, in the Inventory Control module of Unified, when you select an Item, you can, from that form, view 5 other forms that need that particular item's #. I can either put that in the UnifiedClass (and all 5 forms can just say "unified.whatever"), or I can pass it to variables on each of those forms.

    It's a matter of preference, in the end, but it feels quicker and more efficent to assign it once to the class than to store it locally on the form or to access it from a previous form...sometimes certain information is accessed by all parts of the program (such as who is logged in and what console ID, for auditing purposes).
    Warren Ayen
    Senior C# Developer
    DLS Software Studios (http://www.dlssoftwarestudios.com/)

    I use Microsoft Visual Studio 2005, 2008, working with Visual Basic and Visual C#
    Hey! If you like my post, or I solve your issue, please Rate Me!

  8. #8
    Fanatic Member
    Join Date
    Aug 2006
    Location
    Chicago, IL
    Posts
    514

    Re: The Definitive "Passing Data Between Forms"

    Yes, you're right - I was kinda overshadowing what you're referring to - simply passing a value from one form to another. I just thought if we make sure newer users move directly to OO, even for small tasks, they can quickly realize how much more efficent it is when it comes to harder stuff.
    Warren Ayen
    Senior C# Developer
    DLS Software Studios (http://www.dlssoftwarestudios.com/)

    I use Microsoft Visual Studio 2005, 2008, working with Visual Basic and Visual C#
    Hey! If you like my post, or I solve your issue, please Rate Me!

  9. #9

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by warrenayen
    Also, for MDI environments, the child form can use the:

    vb Code:
    1. Me.Parent

    This allows the child form to access the properties, controls, methods, and events of the parent form.
    I think this is why that third category seemed so nebulous. Since there is a standard way to access the parent, the questions that remain tend to arise from other misconceptions rather than simply passing data from form to form, and these misconceptions don't fall into any recognizeable category. Therefore, I think that MDI questions are distinctly different from SDI questions.
    My usual boring signature: Nothing

  10. #10
    Fanatic Member
    Join Date
    Aug 2006
    Location
    Chicago, IL
    Posts
    514

    Re: The Definitive "Passing Data Between Forms"

    Eh, it depends on the parent, too - I'm using a container parent for all forms in Unified. That way everything has a similar look and feel (unified design). Whenever I want to access a control on the main container form (which is what I prefer to call MDI parents), I simply say Me.Parent.pnHeader (the header bar), and change it however I want. Or use anything on the form

    However, this doesn't work for things like Panel controls and so on - they rely on the common set. I can't do things like "me.control.item(0).parent.checked = true" because it's not common to that object...that makes some things difficult, or I haven't figured out yet how to do it
    Warren Ayen
    Senior C# Developer
    DLS Software Studios (http://www.dlssoftwarestudios.com/)

    I use Microsoft Visual Studio 2005, 2008, working with Visual Basic and Visual C#
    Hey! If you like my post, or I solve your issue, please Rate Me!

  11. #11
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    in addition to passing data between forms via a public property exposed on the form, if a form needs data from another form and it ALWAYS Needs said data when it is to be shown, I will often overload the forms New constructor to pass the param in right when I create the form. This is nice because lots of times you will write code like

    Code:
    Dim MyForm as New Form1
    MyForm.SomeProperty = True 'BETTER NOT FORGET TO SET THIS
    MyForm.ShowDialog
    Or if you change the forms Sub New to accept a boolean, you could just do
    Code:
    Dim MyForm as New Form1(True)
    MyForm.ShowDialog
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  12. #12
    Fanatic Member bgmacaw's Avatar
    Join Date
    Mar 2007
    Location
    Atlanta, GA USA
    Posts
    524

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by kleinma
    Or if you change the forms Sub New to accept a boolean, you could just do
    Code:
    Dim MyForm as New Form1(True)
    MyForm.ShowDialog
    I think one of the most overlooked techniques in VB.NET form management is that the New method of a form can be overloaded as you've shown here. Many programmers, particularly those coming from VB6 since it didn't offer parameters on constructor methods, tend to overlook this option.

    One example of how I used this recently was with a MDI app that had a report selection sidebar (reports for a specific date or patient could be selected). The selected report criteria would be passed to the overloaded New method of a MDI child form and the form would use this information to populate itself.

  13. #13
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    I agree.

    Not only did VB6 not have overloaded constructors, it didn't have them at all.

    If you made your own class, you could declare it using the New keyword, but there was no actual New routine in the class, it was just basically a keyword that told the runtime to create a class instance.

    .NET rocks!
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  14. #14
    Frenzied Member
    Join Date
    Dec 2001
    Posts
    1,331

    Re: The Definitive "Passing Data Between Forms"

    Hello,

    Just recently I have always used a global collection of my variables in a class, and using the public properties to get and set them.
    i.e. as i have my code open.

    vb Code:
    1. Private Shared customerSoftwarePart As Integer
    2.  
    3.  'Get and set the customers's software
    4.     Public Property customerSoftwarePartID() As Integer
    5.         Get
    6.             Return customerSoftwarePart
    7.         End Get
    8.         Set(ByVal value As Integer)
    9.             customerSoftwarePart = value
    10.         End Set
    11.     End Property

    I have also used the constructor to pass data on to the form as well.

    I guess its just personal and consistency on the programmer to decide which one is best.

    Steve
    steve

  15. #15
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    why would you declare the customerSoftwarePart variable as shared, when the property exposing it is not shared?
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  16. #16

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Besides which, a module is a Public Shared class, so you might as well just use a module.
    My usual boring signature: Nothing

  17. #17
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,380

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by warrenayen
    Eh, it depends on the parent, too - I'm using a container parent for all forms in Unified. That way everything has a similar look and feel (unified design). Whenever I want to access a control on the main container form (which is what I prefer to call MDI parents), I simply say Me.Parent.pnHeader (the header bar), and change it however I want. Or use anything on the form

    However, this doesn't work for things like Panel controls and so on - they rely on the common set. I can't do things like "me.control.item(0).parent.checked = true" because it's not common to that object...that makes some things difficult, or I haven't figured out yet how to do it
    Ick... I cringe when I see that.... I prefer to expose events, raising them from the child form. Then I can let the parent form decide if it's going to deal with the event or not. I had a situation where all my child forms inherited from a main form (for consistency, gawd I love OOP) and they all raise status events for some of the actions going on. In a couple of cases, I don't care to know what a particular form is doing, so I extended the EventArgs parameter to include a key name that allows me to identify who raised the event. Then from there, the parent can decide to deal with the message, or ignore it.

    I also used this same technique to send messages from one form to another via the parent. Child 1 raises the messageQueued event, the Parent traps for it, sees that it's for another Child (Child 2)... makes sure we have an instance of Child 2, and passes the message on. If no instance of Child is found, the message is tossed.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  18. #18
    Lively Member
    Join Date
    Apr 2005
    Posts
    127

    Re: The Definitive "Passing Data Between Forms"

    one issue that was always kinda fuzzy to me but I never bothered to find out why because it just worked was:

    -I have a form, TempForm with a public member, TempDS as dataset.
    -I declare this TempForm.TempDS = AnotherForm.Dataset.

    when I make changes to TempDS in TempForm, the DataSet in AnotherForm also gets changed.

    I always thought the value of DataSet in AnotherForm was being copied to TempDS in TempForm. So when you change TempDS inTempForm, DataSet in AnotherForm will not get changed. But it seems the reference to DataSet in AnotherForm was passed instead.

    When I do the same thing with like a string or int type public member, the value gets copied, the reference doesn't get passed. Do VB.net pass reference or value differently based on what variable you use?

  19. #19

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Actually, this is the behavior for all reference types. Watch carefully, and you will find that it happens for strings as well. What is happening is that a reference type is nothing but a pointer (the address of the first byte of the object). When you copy a reference type, you copy only the address. This is called a shallow copy. For it to behave otherwise would be called a deep copy, and you have to implement that yourself for all objects that don't already have a Copy method (string does).

    The reason for this is that an object can hold pointers to other items, such as arrays of objects, other strings, etc. Simply creating a new instance of the object leaves some ambiguity: Do you make copies of all the underlying objects? And if so, how? Some objects require very specific actions to create, so would you call the constructors for them? Do you have all the data needed to call their constructors?

    C++ has something called a copy constructor that allows for a deep copy. The copy constructor doesn't actually do anything, though, all it is is a standardized method signature, you are still required to explicitly code how this copy is supposed to happen. .NET has no standardized form of a copy constructor, but you still have to code how this happens.

    If you want a deep copy, that is, you want to make a true copy of an object, you have to create a method to do so. Without that, you are just copying the address to the first byte of memory for the object, and nothing more.
    My usual boring signature: Nothing

  20. #20

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    I have now edited the original post to include a paragraph on the use of an overloaded constructor. I think I captured what could be done with that, but have a look.
    My usual boring signature: Nothing

  21. #21
    Lively Member
    Join Date
    Apr 2005
    Posts
    127

    Re: The Definitive "Passing Data Between Forms"

    Whenever I passed strings or ints, the value always gets copied over instead of reference getting passed. Does it have to do with the "new" syntax?

    In my example with the public member TempDS as dataset, it isn't declared as a "new" dataset, so the reference is passed?

    When you declare public TempString as String, a new string is created and the value of that string is equal to whatever value you give to it. So the value is passed instead of the reference?

  22. #22
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by daemonk
    Whenever I passed strings or ints, the value always gets copied over instead of reference getting passed. Does it have to do with the "new" syntax?

    In my example with the public member TempDS as dataset, it isn't declared as a "new" dataset, so the reference is passed?

    When you declare public TempString as String, a new string is created and the value of that string is equal to whatever value you give to it. So the value is passed instead of the reference?
    The difference you are noticing has to do with value and reference types. It doesn't have to do with the New syntax so much as it has to do with ByVal or ByRef when you pass a parameter. The default is ByVal, and generally this simply gets inserted in for you by the IDE while you are coding, You almost NEVER have to type it yourself. Usually if anything, its changing a ByVal to ByRef manually.

    Value types can be passed ByVal or ByRef, and will act accordingly. Passing one ByRef means the changes you make in the routine you pass it to will persist back to the one you called it from. ByVal makes the copy when it sends the value into the routine you call.

    Reference types are the opposite, because passing a reference type ByVal or ByRef is actually just passing the pointer in memory ByVal or ByRef to the calling routine. The pointer itself will still be pointing to the same place in memory, so the value(s) of the object passed can be manipulated in a called routine, and they will persist back to the main routine when the called one finishes.
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  23. #23

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    A string was a reference type in 2003, and did not act like an integer. I haven't looked in 2005, but I assumed it was the same thing.

    The behavior you are seeing for strings is not what should be happening. Strings should act the same as the dataset, not the same as an integer. Are you sure you have actually seen this for strings? You would have to do a bit of testing, but this should not be happening.

    In pretty nearly all languages, a string is nothing but the address of the first character in the string (this isn't quite true, but it is true enough, so don't lets have those technical folks jump on me for being a bit casual). The string starts at that byte, and continues on until it reaches a termination character. Thus the size of the string variable is the size of a four byte memory address, regardless of the length of the actual string. If what you are saying were true, then when you assigned one string to another:

    string1 = string2

    Then the equal sign would have to dereference string2, figure out the length of string2, allocate sufficient memory to hold a string of that length, copy each byte of string2 into that new memory, and put the address of the first byte of that new memory in string1. To put it simply: It ain't very likely!!

    What it is actually doing is just copying the four byte memory address that is held in string2 into string1, and that's all (except for incrementing a reference in the smart pointer, but we'll ignore that). This means that string1 and string2 both hold an address to the exact same chunk of memory. When you change string2, you change string1, and vice versa, because they are the exact same thing. Only if you use the String.Copy method will you get a second chunk of memory, with distinct addresses being held in each.

    For .NET to work in any other way would require the = operator to act differently for strings than it does for any other object in the entire language. That woudl be perverse.
    My usual boring signature: Nothing

  24. #24
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by Shaggy Hiker
    A string was a reference type in 2003, and did not act like an integer. I haven't looked in 2005, but I assumed it was the same thing.

    The behavior you are seeing for strings is not what should be happening. Strings should act the same as the dataset, not the same as an integer. Are you sure you have actually seen this for strings? You would have to do a bit of testing, but this should not be happening.

    In pretty nearly all languages, a string is nothing but the address of the first character in the string (this isn't quite true, but it is true enough, so don't lets have those technical folks jump on me for being a bit casual). The string starts at that byte, and continues on until it reaches a termination character. Thus the size of the string variable is the size of a four byte memory address, regardless of the length of the actual string. If what you are saying were true, then when you assigned one string to another:

    string1 = string2

    Then the equal sign would have to dereference string2, figure out the length of string2, allocate sufficient memory to hold a string of that length, copy each byte of string2 into that new memory, and put the address of the first byte of that new memory in string1. To put it simply: It ain't very likely!!

    What it is actually doing is just copying the four byte memory address that is held in string2 into string1, and that's all (except for incrementing a reference in the smart pointer, but we'll ignore that). This means that string1 and string2 both hold an address to the exact same chunk of memory. When you change string2, you change string1, and vice versa, because they are the exact same thing. Only if you use the String.Copy method will you get a second chunk of memory, with distinct addresses being held in each.

    For .NET to work in any other way would require the = operator to act differently for strings than it does for any other object in the entire language. That woudl be perverse.
    Yes strings are still reference types in 2005. You will modify its contents in a calling routine regardless of the fact of being passed ByRef or ByVal
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  25. #25

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Well, that has strayed a bit. Are there any other Form to Form issues I should cover in the initial post?
    My usual boring signature: Nothing

  26. #26
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    Perhaps you might want to just brush on default instances? I think you mentioned you are using VB 7.1, and they didn't come back until VB8, so let me know if you want me to write a blurb about them.
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  27. #27

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Yes, know very little about default instances, but my impression of them is that it makes things a bit too easy for folks, while masking some of their understanding. I certainly don't know enough about them to say anything rational about them. In fact, I am only vaguely aware that they exist.
    My usual boring signature: Nothing

  28. #28
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    Well most people say they were added back in to help VB6 people move to .NET (that may or may not be true, I haven't seen MS actually say that anywhere)

    Basically a default instance of a form is the same as creating your own instance of a form. The only difference is that you don't use a variable to hold the reference, you use the forms actual name.

    So lets say you start a new project. By default it will add in a Form1 for you.

    So in VB 2005 you have the option to either do

    Dim MyForm as New Form1
    MyForm.ShowDialog

    or you can do

    Form1.ShowDialog

    what happens is the runtime says "Is the default instance of Form1 nothing? if it is create a new instance, if not use the existing instance"

    Situations that it is good for, are situations like a login form, an options form, etc...

    GENERALLY you are never going to show 2 login forms at the same time in an app are you? So the default instance can be handy here because you can simply just call the show method of the login form. If you always call the login form using its name, you will always access the default instance.

    You can also assign the default instance of a variable of the forms type, since its all reference types, if you wanted to for any reason...

    So as long as you understand what default instances are, they are actually pretty nice and useful in certain situations. If you don't understand, then you will run into situations where you get unexpected results.

    I think the reason people don't like them is because they think it is against standard OO practices. VB is known for making things easier on the developer though, and for being IMO the best RAD tool out there, so the more they can do to make it easy the better.

    Hell most of the methods in the My namespace (also new to 2005) are available via other standard framework classes. Does that mean you shouldn't use the My namespace? depends on if it makes your life as a developer easier or not
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  29. #29
    Lively Member
    Join Date
    Apr 2005
    Posts
    127

    Re: The Definitive "Passing Data Between Forms"

    well I'll do a quick test on the string reference stuff when I get home I guess. I did a test on that before and I thought the string value was copied. Maybe I screwed something up. What I did to test it last time was:

    -Add public member AString and BString into AForm and BForm respectively.
    -Then I added this to the main form:

    dim AFo as new AForm
    Afo.Astring = "String A"
    messagebox.show(AFo.AString) 'should show String A in a messagebox

    dim BFo as new BForm
    BFo.BString = Afo.Astring
    messagebox.show(BFo.BString) 'should show String A in a messagebox

    Afo.Astring = "Changed String A"

    messagebox.show(AFo.AString) 'shows Changed String A in a messagebox
    messagebox.show(BFo.BString) 'shows Cahnged String A in a messagebox

  30. #30

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Uhhhhh, isn't that exactly what you were saying didn't happen? In your example, changing one instance changed them both, which is what should happen for a reference type.

    Kleinma: After reading that, I can sum up my feelings about default instance with one word: Ugh!

    Ok, it is what I thought it was, and works the way I thought it worked. I also think that it was added back in as a convenience. When I used that in VB6, I used it without understanding it. That is a convenience, and perhaps it will remain a harmless convenience, but I feel that it will cause confusion for anybody who tries to do anything that gets beyond the default instance. If people become trained to think that Form1 is the name of the form, rather than the name of the class, then they will become confused when they need to make multiple instances of the class.

    I haven't used My yet, either.

    As far as passing data from Form to Form, it appears that using the default form, you probably can't use an overloaded constructor, as the default constructor must take no arguments. Perhaps that could be altered by removing the default constructor.

    What this means is that the default instance has to transfer data using properties, as far as I can see.
    My usual boring signature: Nothing

  31. #31
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    I like to think of it as an implied shared instance. Think of it as just a feature of the form class.... the ability for it to create an instance of itself via a shared method.. it just happens that the shared method can be any public method of the form to instantiate the instance.

    Yes, since you don't use a constructor with a default instance, you would use properties for data exchange. You could call that a limitation, but again, default instances should really only be used in isolated instances, if at all.
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  32. #32

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Ok, I edited the first post to include a little bit about how the default instance requires you to move data via properties.

    At this time, I think that first post covers all of the key points about transfering data between forms.
    My usual boring signature: Nothing

  33. #33
    Frenzied Member
    Join Date
    Jul 2006
    Location
    MI
    Posts
    1,848

    Re: The Definitive "Passing Data Between Forms"

    Kleinma ... this is from your post #11:

    Quote Originally Posted by kleinma
    Code:
    Dim MyForm as New Form1
    MyForm.SomeProperty = True 'BETTER NOT FORGET TO SET THIS
    MyForm.ShowDialog

    Can you please explain this method a little better? In particular, what is .SomeProperty? Is it an existing property of a form or is it a new property that you create? If it's a new property, how do you create it?


    If I want to use this method:

    Code:
    Dim MyForm as New Form1(True)
    MyForm.ShowDialog
    In this example, Form1 is passing a value of "True" to Form2. But how do I retrieve that value once Form2 is displayed? Also, can I pass any data type using this method (string, integer, etc.)?

    Thanks...
    Last edited by nbrege; May 18th, 2007 at 08:58 AM.

  34. #34
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    It is some property you create USUALLY, but it could be an existing property of the form if you wanted it. Since the constructor (new sub) you create can take whatever params you tell it to, you can set whatever properties you want in the constructor. So here is an example setting an existing AND custom property of a form

    So lets say in the form you make the custom constructor for you have this code:

    Code:
        Private _CustomProperty As String = String.Empty
    
        Public Property CustomProperty() As String
            Get
                Return _CustomProperty
            End Get
            Set(ByVal value As String)
                _CustomProperty = value
            End Set
        End Property
    
        Public Sub New(ByVal CustomPropValue As String, ByVal FormBackColor As Color)
    
            InitializeComponent()
    
            Me.CustomProperty = CustomPropValue
            Me.BackColor = FormBackColor
    
        End Sub
    then in the form you call this form from, you have this code.

    Code:
        Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
            Dim F As New Form2("HELLO WORLD", Color.Red)
            F.ShowDialog(Me)
            F.Dispose()
        End Sub
    as you can see, I pass 2 values, and I assign them in the forms New sub to the correct properties.
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  35. #35

    Thread Starter
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,927

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by nbrege
    Kleinma ... this is from your post #11:




    Can you please explain this method a little better? In particular, what is .SomeProperty? Is it an existing property of a form or is it a new property that you create? If it's a new property, how do you create it?


    If I want to use this method:

    Code:
    Dim MyForm as New Form1(True)
    MyForm.ShowDialog
    In this example, Form1 is passing a value of "True" to Form2. But how do I retrieve that value once Form2 is displayed? Also, can I pass any data type using this method (string, integer, etc.)?

    Thanks...
    The point Kleinma was making with the first part of that post was that using properties to pass data is sometimes not such a good idea, because you might forget that you need to pass the data. By overloading the constructor, you can pass the data directly to the form as you would with any argument to any sub or function. If you then make the default version of the constructor private, you can make it impossible to create the form without passing the data.
    My usual boring signature: Nothing

  36. #36
    Addicted Member
    Join Date
    Oct 2007
    Posts
    133

    Re: The Definitive "Passing Data Between Forms"

    First great site! I have found some of the responses here invaluable, thanks to all who make this forum such a valuable resource.

    Little history on me, i stopped VB programming around the time VB6 was dropped by MS and back then I only programmed very little C, lots of VB 5 and 6 then my wife starting running this baby making program which pretty much sucked all my time and resources dry - lol. The programming bug struck again this summer as I found I have a little more time now that the kids are a little more independent so i thought i would take a boo at VB 2005.

    Yikes. So much has changed and initially could not understand why there wasn't this or that, as an example control arrays. I promptly bought a few books and am getting my head around things and sites like this have helped tremendously. I have written many, many little programs in VB 2005 and decided to write something that i could actually use, meaning a little more complex.

    OK to the point. :-)

    I have a main form, I call a second form to set some variables which will be used for the duration of that programs session within the main form. The easiest thing would have been to use global variables in a module, but often I read that is not he way to do things and of no challenge to do so, yes i mainly just like the challenges of programming.

    Above i read about class object (seems popular), is the code example above basically a class object but in a forms class? Currently i am setting labels on the main form and setting them with a new instance of form 2, then setting main forms variables with those filled in labels. I want to use a class object, is there any sample program i can check that anyone knows of?
    Last edited by sytto; Nov 6th, 2007 at 12:31 PM.

  37. #37
    Super Moderator Hack's Avatar
    Join Date
    Aug 2001
    Location
    Searching for mendhak
    Posts
    58,335

    Re: The Definitive "Passing Data Between Forms"

    I think it is about time this got moved to the CodeBank (if for no other reason than an easy point of reference )

    Moved
    Last edited by Hack; Apr 17th, 2009 at 11:55 AM.
    Please use [Code]your code goes in here[/Code] tags when posting code.
    When you have received an answer to your question, please mark it as resolved using the Thread Tools menu.
    Before posting your question, did you look here?
    Got a question on Linux? Visit our Linux sister site.
    I dont answer coding questions via PM or EMail. Please post a thread in the appropriate forum section.

    Creating A Wizard In VB.NET
    Paging A Recordset
    What is wrong with using On Error Resume Next
    Good Article: Language Enhancements In Visual Basic 2010
    Upgrading VB6 Code To VB.NET
    Microsoft MVP 2005/2006/2007/2008/2009/2010/2011/2012/Defrocked

  38. #38
    Moderator.NET kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: The Definitive "Passing Data Between Forms"

    yeah.. the question only gets asked 100 times a day
    Using VS.NET 2013/.NET 2.0 through 4.5 * Please mark you thread resolved using the Thread Tools above
    PLEASE INDICATE WHAT VERSION OF VB YOU USE!!!!!!!!!!!
    * If you found a post useful then please Rate it! * DO NOT PM ME WITH LINKS TO YOUR THREADS FOR ANSWERS PLEASE!

    Code Bank:Manipulate HTML Page content in the Web Browser Control from VB - Drag Drop from Windows into Win Form - Launch new default browser instance to open URL - Display Internet Image in Picturebox - Download Files From Web With Progress Bar - IP Textbox User Control - Installing .NET Framework with INNO Setup
    ZerosAndTheOne.com
    -=Matt=-

  39. #39
    Super Moderator Hack's Avatar
    Join Date
    Aug 2001
    Location
    Searching for mendhak
    Posts
    58,335

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by kleinma View Post
    yeah.. the question only gets asked 100 times a day
    That is how I found the thread...there is a question on this in the .NET section at this very moment.
    Please use [Code]your code goes in here[/Code] tags when posting code.
    When you have received an answer to your question, please mark it as resolved using the Thread Tools menu.
    Before posting your question, did you look here?
    Got a question on Linux? Visit our Linux sister site.
    I dont answer coding questions via PM or EMail. Please post a thread in the appropriate forum section.

    Creating A Wizard In VB.NET
    Paging A Recordset
    What is wrong with using On Error Resume Next
    Good Article: Language Enhancements In Visual Basic 2010
    Upgrading VB6 Code To VB.NET
    Microsoft MVP 2005/2006/2007/2008/2009/2010/2011/2012/Defrocked

  40. #40
    VB Addict Pradeep1210's Avatar
    Join Date
    Apr 2004
    Location
    Inside the CPU...
    Posts
    6,612

    Re: The Definitive "Passing Data Between Forms"

    Quote Originally Posted by kleinma View Post
    Yes strings are still reference types in 2005. You will modify its contents in a calling routine regardless of the fact of being passed ByRef or ByVal
    Ummm...
    It doesn't seem to be modifying the contents of the passed string.
    vb.net Code:
    1. Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    2.         Dim myString As String = "Some String"
    3.         MsgBox("My Original value is: " & myString)
    4.         LetsTestString(myString)
    5.         MsgBox("After LetsTestString, my value is: " & myString)
    6.     End Sub
    7.  
    8.     Private Sub LetsTestString(ByVal theString As String)
    9.         theString = "LetsTestString modified me"
    10.         MsgBox("In LetsTestString: " & theString)
    11.     End Sub
    When we run the above code, it shows that LetsTestString did not change the value original string value that was passed. i.e. it made the changes in a different memory location.

    Though strings are reference types in .NET, they don't quite behave as such.
    Instead they behave more like value types rather than reference types. They are mutable. One string can't change the contents of another string even if they are pointing to the same memory location. As soon as you try to do that, .NET will create a new memory location and make it point there.
    Pradeep, Microsoft MVP (Visual Basic)
    Please appreciate posts that have helped you by clicking icon on the left of the post.
    "A problem well stated is a problem half solved." Charles F. Kettering

    Read articles on My Blog 101 LINQ Samples JSON Validator XML Schema Validator "How Do I" videos on MSDN VB.NET and C# Comparison Good Coding Practices VBForums Reputation Saver String Enum Super Simple Tetris Game


    (2010-2013)
    NB: I do not answer coding questions via PM. If you want my help, then make a post and PM me it's link. If I can help, trust me I will...

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width