Form1 Values in Other Modules

[Vladamir]

I'm a little confused on something. I have a Windows Form Application with some text boxes that get filled in by the users. In another module in this project I have some code like this:

  If Form1.DwgNo.Text & ".dwg" = vAcadApp.ActiveDocument.Name Then
       If Form1.rbtn11N.Checked = False Then
           vAcadApp.ActiveDocument.SendCommand("(load ""//a_long_path/VLISP/" & SaveType & ".lsp"" ""The load failed"") " & SaveType & vbCr)
      End If
  End If

Recently I asked a question about this and was informed that another module will not know anything about the values for textboxes in Form1. Well, here's the deal. When I step through this the program behaves as expected, based on the value in the text box. But when I insert a watch on that value the watch window reports "Reference to a non-shared member requires an object reference. "

Like I said, the code works and it seems to understand that the condition is true but I can't see the value of this textbox in a watch window.

[Shaggy Hiker]

I've seen that before and would say that it is probably just a quirk, or even a bug, in the IDE itself. In the line, you have Form1.DwgNo.Text. That will make use of the default instance of Form1. If that's the instance of the form that you are displaying, then it will work fine, if it is not the instance of the form that you are displaying, then that line will create a new instance of the form, which the user won't see and won't be able to interact with, and make use of it. Since the code is working for you, then you must be displaying the default instance.

What the default instance is is effectively that the compiler has quietly added a line like this in a public module:

Public Form1 As New Form1

In other words, it is creating an instance of a form class and giving it the name of the class itself. That's not exactly what it is doing, though, because that would be inefficient. What it is actually doing is only creating the instance as needed. Default instances were not introduced until VS2005, and then were only added to make the language appear a little more like VB6. Watch windows, and the technology behind them, were added from much further back. I would say that what is happening is that whatever is running behind the watch window doesn't know anything about default instances, and therefore sees Form1 as being nothing more than a type when it is actually BOTH a type, as well as a specific instance of that type. Whether this is a bug, where MS forgot to change watch windows so that they were aware of the default instances, or whether this is just a quirk that makes it such that a watch window can't use default instances, I couldn't say, but that's the issue.

[SJWhiteley]

Default instances; yeah, it's a problem. I have seen issues with the watch window and default instances, as SH concludes.

Usually, whenever you see the reference Form1, and are having issues, then it's likely a default instance issue. Usually, my 'rule' is never, ever, refer to the name of the form. If the form is called MainForm, then there should never be a direct reference - by name - to MainForm.

[Shaggy Hiker]

I like that rule, too....right up until I found a situation where I didn't, but there are exceptions to every rule. An error regarding Form1 is almost always a default instance problem, though. I was tempted to write that default instances were introduced in 2005 because the language was getting too good and MS wanted to confuse people a little more, but that isn't really the case.

[Vladamir]

Thanks. I gathered something like that must be happening because the IntelliSense was letting me type in the Form1.xxxxx stuf with no problem. And the values were resolving in the Boolean equations.