Preventing automatic variable changes in Multiple Child Forms

[NigeLost]

Hi,

I am new to this Forum, although I have searched it from time to time.

I am also new to VB Programming and working on what is, I suppose, a fairly ambitious project for a newbie!

As you can guess, I have hit a snag and would like some easy-to-follow assistance, please.

My program is for input of some information, storing this in a database, then using the information to build 4-point graphs in child windows when selected from a ListBox. The Row ID is gained from the ListBox Item selection, enabling identification & retrieval of the relevant data to build the graph and other data into a "template" child Window, which is then displayed.

All works great until....

A number of graphs need to be selected for display as comparisons. Clicking several items in the ListBox opens several Child Windows. They each open correctly BUT, from Graph 2 onwards, as each is opened, the previous graphs automatically change to the current item's data. As a result I end up with all graphs & info being exactly the same.

How can I ensure that, after creation, a Child Form accepts no further input?

I have not found anything that helps me through this dilemma. Can you help me find the solution?

Many thanks.

 

[jmcilhinney]

I would guess that you are using the same objects as data for each child form. As you change the data in these objects for a new form the changes are reflected in all previous forms because they are displaying the same data.

OOP is designed to mimic real life. Let's say that you have a glass containing water. You put a straw in that glass and commence drinking. You get a mouthful of water. Now someone else wants milk. They fill the glass with milk and insert a straw. They get a mouthful of milk, and so do you. You are taking your drink from the same glass so any changes made for the new drinker will also affect you. The same is true in OOP. If you two objects reference the same source, any changes made to the source by one object will also be experienced by the other.

Without your providing any information about how these child forms are created and from where they get their data the best we can do is guess. From the information you've provided this is my educated guess as to the reason.

 

[NigeLost]

Hello.

I did not realise that the "old" Forms "refreshed" when a new one was created. I thought they had ended their "life" once they had been constructed.

I managed to get some advice on this.

Apparently, to prevent the glass of water from being refilled, you have to put a plastic bag inside it first and fold the bag over so no-one can add milk to it. (You have a great analogy there!)

This means creating Private Subs in the Public Class area at the top of the Form to "Dim" local variables. eg:

Private wwsName As String
    Private wwsDate As String

Using these variables to accept the global ones:

Private Sub WordSurveyDisplay_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load


        wwsName = MAIN.wsName.ToString
        wwsDate = MAIN.wsDate.ToString
        wdoScore = Val(MAIN.doScore)

... makes them impervious to the change in global vars stored in my parent Form, called MAIN.vb.

It solved the problem.

Please do not misunderstand me - I am not trying to teach you, jmcilhinney. I am sure you know this process already. I have explained the solution in case it helps anyone else with a similar problem.

Thanks for your kind attention. It is much appreciated

 

[JohnH]

It would be better design for the provider of data (MAIN) to give it to the receiver (WordSurveyDisplay), than for the receiver to grab it from the provider as you do here in form load. Especially since you have several receivers that do the same thing and experience mixup of data. You have several options to do this; write a Sub New contructor for WordSurveyDisplay that accepts parameters, write public properties in WordSurveyDisplay, write public sub method in WordSurveyDisplay used to input data. Either of these options allow the creator of new WordSurveyDisplay forms to also give them additional data.

 

[jmcilhinney]

You don't put a plastic bag over the glass of water. You use a different glass for the milk. That's what I was trying to get across. If you want independent data then you need independent sources for that data.

What JohnH says is quite correct. The caller should be passing the required data to the callee. You should always make the callee as independent of the caller as possible. The caller is the one creating the callee so it should configure it.

 

[NigeLost]

Thanks JohnH & jmcilhinney for the additional inputs here.

.... There is so much to learn!