Warning due to conflict between Form's Shared Function and its Default Instance

[VBobCat]

My project has a "Dialog" Form.
Its purpose is to allow user to select none, some or all itens among the content of a default array.
This default array with all possible choices must be dynamically generated on runtime.
This gets done by function defined into the class of that class.
Whenever needed, a new instance of this form is explicitly instanced (i.e. "Dim MyDialogX as New DialogX : Dim DialogXresponse= DialogX.ShowDialog()"), and user's selection is stored in a new array, of same type of that default one, which contains as many items as user has selected.
All this goes ok.
Sometimes, however, I need to get that default array directly, and I would like to do this without instancing a new form, to avoid overhead froim its layout and field instancing.
To accomplish that, I made that function - which dynamically generates this array - a shared one, and refer it via its base class whenever it is needed (i.e. "Dim DefaultArray = DialogX.GetDefaultArray()")
Albeit it works, I've got since then an everlasting annoying warning, "Access of shared member, constant member, enum member or nested type through an instance; qualifying expression will not be evaluated"
Well, DialogX is not an instance, it is Class's Type itself. I understand that Forms have default instances in VB.NET and this is the cause of this confusion. I've read about it and learned that this is an issue of compatibility with VB6. However, I find disturbing that Type itself and one of its instances are ambiguously referred by the same statement.
My question is, can I disable a Form's self-generating default instance in order to get rid of this warning?
Thank you very much.

[Shaggy Hiker]

You could add a constructor that takes an argument. If you do that, then the default constructor will be removed by the constructor and no default instance can be created because there won't be a constructor that takes no arguments.

However, does your method really belong in the form to begin with? It seems likely that it doesn't HAVE to be in the form, since it's a shared member. So, the easiest solution might be to move that method to a Module.

[VBobCat]

You could add a constructor that takes an argument. If you do that, then the default constructor will be removed by the constructor and no default instance can be created because there won't be a constructor that takes no arguments.

Thanks, my class had already two constructors, and the one without parameters was quite an idle one. Removing it solved the problem. The parametrized constructor retrieves previous settings and, from now on, when there aren't any, I now send null values which are tested as they must. It works.

However, does your method really belong in the form to begin with? It seems likely that it doesn't HAVE to be in the form, since it's a shared member. So, the easiest solution might be to move that method to a Module.

You are right. It does not have not to be in the form, but since it relates to nothing else than the data which is selected through that form, it sort of made sense to me this way. And it worked from day one, and now, thanks to your suggestion, I'm free of the warning that made me feel like there was something wrong.

Thank you very much!

[Shaggy Hiker]

Default instances have caused little more than headaches since they were introduced.

I agree that you should put the thing in a place that makes organizational sense. It sounds like you have done that, so good show.