Forms and parent/child forms guilty of incest with module variables

[twgonder]

No. two different animals.

Ding, ding, ding! Depending on what "instantiated" means to Microsoft I suppose. If I remember correctly, it was you that once said you worked with classes a lot.

Similar to "module1" in the demo I sent earlier, I have a "mod_3_Form" "standard module" that handles all kinds of "methods and properties" for the calling form (class object -- at least that's what MS calls it in the Project Explorer). I'm guessing I would like to make this module a class somehow, and be able to "call" it from the form's class object (without too many changes to all the existing code).

Further, I'm hoping that MS, in calling these form's VBA a "class object" that one instance of a form (from thread Variables corrupted when closing all instances of a form, debugger problems too (accessforums.net) ) doesn't stomp on the variables of the same form running an nth "instance".

Got a link that shows how to take a regular module and turn it into something "class"?

[twgonder]

@Minty, #10 Thanks, I'll read up. Because of my Internet situation, I go to the books I have first. Nothing is stated there, that I've seen, that a module will have it's PRIVATE variables stomped on by another call to the module. I guess I was foolish to believe that Access would operate differently from any other multi-user, multi-tasking, multi-spawning programming language.

[twgonder]

@twgonder
I found your example interesting but probably not for the reasons you intended.

With your permission, I'd like to use your example as part of a web article explaining why you should never try to use module level variables in this way.
Understanding the scope of variables is an essential part of using Access successfully.

Thanks for responding. So, what did you find interesting? At least different from what the purpose of my post was?

Does my "solution" in post #8 seem correct to you? Or is there a better way that doesn't include a class?
You're welcome to use both examples as you wish.

[Edgar]

@Edgar, #10
I tried your Form1 and Form2, same problem. Barney still thinks he is a child.[/COLOR]

It should read "a little confused (parent)", I put the private variable between parentheses. In access, variables declared before procedures in modules are available everywhere unless declared private like:
Private mWhat As String
Which would effectively become module-scoped for only that module. You declared it project-scoped, so all forms that use it are modifying it. Seeing that change in action is the purpose of the form you couldn't see for your resolution. But grabbing the variable and making it private makes it class-scoped, which is what the variable between parentheses should be showing. Does it read "a little confused (child)"?

Edit:
Dim and Private make the variable available only to that module. When the variable is declared Public before procedures, the variable is project-scoped. And I repeat, the function that changes the variable is what is public, not the variable. So all forms calling that function will change the variable, but since the function returns a public string, it is the string that the forms are accessing, not the variable.

[twgonder]

@twgonder

Consider taking your process a stage further to 3 or more generations so people can be listed as both a parent and a child.
What type of results would you expect to see?.

The use of a parent/child paradigm was just to make things easier to understand when using subforms. In reality, the real application has dozens of different forms that all call the one form supporting module to handle things like colors, enabled, locking, helps, translation, etc. For example, each form may have a subset of command buttons, that need controlling. What tipped me off to the problem of a Private variable not really being "private" in the conventional sense, is that a parent form stomped on the private variables of the subform when they both called this same supporting module.

Which brings up the bigger question, given that I understand now what MS did with the module scoped variable. If a module BY DEFINITION has procedures that are meant to be called from other procedures, why the hell would a RAD developer not make the private variable truly private between calls from different callers? Isn't that why (at least one reason why) handles and multiple workspaces were developed some 50 years ago (without classes by the way)? Incredible.

[twgonder]

It should read "a little confused (parent)", I put the private variable between parentheses. In access, variables declared before procedures in modules are available everywhere unless declared private like:
Private mWhat As String
...

Unless I've grossly misunderstood lots of different documentation on the topic, including one of the first manuals published with Access 1993, I declared the variable mWhat as module scoped and not as a global. From what I can tell, Private is just a new name for Dim, does the same thing.



Sorry about the orientation. Windows still seems to have problems despite doing a rotation.

Note: I went back and checked the original file I posted, just to be sure. I see a Dim and not Global there in Module1. Just changing the Dim to Private didn't solve the problem.

[twgonder]

Duplicate of post #20, somehow.

[kd2017]

...What tipped me off to the problem of a Private variable not really being "private" in the conventional sense, is that a parent form stomped on the private variables of the subform when they both called this same supporting module.

Which brings up the bigger question, given that I understand now what MS did with the module scoped variable. If a module BY DEFINITION has procedures that are meant to be called from other procedures, why the hell would a RAD developer not make the private variable truly private between calls from different callers? Isn't that why (at least one reason why) handles and multiple workspaces were developed some 50 years ago (without classes by the way)? Incredible.

A private variable can only by stomped on by code that's in the module, a public variable can be modified from outside the module. If you have public function written within a module, that function can modify it's own module's private variables. In other words, if your form calls a function from a module, that function modifies the variable, not the form.

Valid:
module with private variable -> function within module that uses the private variable -> form(s) call function which modifies the variable

Invalid:
module with private variable -> form(s) modify the private variable directly

Private/public doesn't have anything to with creating multiple instances, or workspaces, of the same variable. If multiple forms call the same module function which modifies it's own private variable, that function would modify the same instance of the same variable.

[Edgar]

Just changing the Dim to Private didn't solve the problem.

Now that it's private, can you access the mWhat variable from outside the module, like, from a form? Not using a function.

Edit:
Keeping it as Dim was still private.

[kd2017]

In reality, the real application has dozens of different forms that all call the one form supporting module to handle things like colors, enabled, locking, helps, translation, etc. For example, each form may have a subset of command buttons, that need controlling.

You can still do that, it's a great idea for removing code duplication. You just need to find a different way to store your variables. Why not keep your private variables with the form?

I've created an example demo based on what I gather your trying to do. Maybe it'll help... hopefully it doesn't muddy the waters.

example.accdb

I've got multiple forms calling the same 'helper' functions from a module that change the background colors of some form objects. The forms themselves store a private variable, and they're passed to the module and the module does the leg work. The forms do not stomp on each other's variables.

[twgonder]

@Moke123, post #13

I hate to bother you, but I (and I'm sure others in a similar circumstance) would love to hear what you have to say about classes before I go down that road.

1) Have you been able to move a regular module to a class module without too much rewrite?
2) If one does use a class, will it retain "module" variables to be called again, from the same calling process.
3) Will other instances of the same form (or others) tromp on the module variable in a class object?
4) Have you seen a good video/blog on starting with classes that also explains the limitations in Access?

As another possibility, I use arrays a lot for homogenous data, and those are easy to pass back to the calling form VBA class object from the support module.
However, there are a lot of other individual variables that are heterogenous, so using array references (i.e. MyData(2,18)) becomes somewhat obtuse.
In my old system I had two features that were quite valuable when dealing with using these kinds of arrays.
1) There was a way to give single column array element a pseudo name, i.e. EQU LOCKSET TO PASSDATA(19). Then one just used Lockset throughout the code.
2) There was a command to include other code into a program as an INCLUDE. I would put all these pseudo statements into an included module, which then all procedures (for forms) could use without having to have all that code duplicated and possibly different between modules.

Are there commands in VBA to accomplish these two ideas? I haven't seen them yet in any documentation and I'm not even sure what VBA would call them (I just know them as EQU and INCLUDE from an old BASIC).

[twgonder]

@Edgar, post# 24
I can test that, but if I can use mWhat from outside the module that has it (Module1) as a DIM or PRIVATE, then that would be a serious problem.
If I understand your question properly, creating another module and then just adding a procedure that does debug.print mWhat should do the trick for testing. On the other hand, changing DIM or PRIVATE to GLOBAL should work okay.

[twgonder]

@kd2017, Post #25 It sounds like you may be doing what I did in post #8. But I'll check to be sure.
What hasn't been answered is if multiple instances of a form will also stomp on the module variables. It might be best to test that with the .accdb in thread #87614.

If your example is basically the same as mine in #8, then what I asked in post# 26 is very relevant.

[kd2017]

@kd2017, Post #25 It sounds like you may be doing what I did in post #8. But I'll check to be sure.
What hasn't been answered is if multiple instances of a form will also stomp on the module variables. It might be best to test that with the .accdb in thread #87614.

If your example is basically the same as mine in #8, then what I asked in post# 26 is very relevant.

No, multiple instances of a form will not stomp on *private* module variables... a module will stomp on it's own variables. If multiple instances of forms are calling the same module, and the module is modifying its own variables, then that's where your problem is.

I've not needed to create multiple instances of the same form object so I can't help, but review this http://allenbrowne.com/ser-35.html

If you take something of a 'functional programming' approach or mindset to this, and pass your variables to the functions defined within the module, rather than try to get your module to manage variables, you'd be good to go.

[edit]
I took a quick glance at your db from post #8. Out of principle I wouldn't go to the trouble to create a private variable in the form only to let a module modify it directly. I would rewrite sFrmLoad like so:

Public Function sFrmLoad(ByVal aW As String) As String
  If aW = "P" Then 
    sFrmLoad = "padre"
  Else
    sFrmLoad = "hijo"
  End if
End Function

And use it from the form like this:

Private mWhat As String

Private Sub Form_Load()
  mWhat = sFrmLoad("P")
End Sub

[twgonder]

@kd2017, post #29 I think that's the solution that worked in post#8, with the caveat of instances, which I have yet to test, but hot on the trail.