How to call a module

[VBNET_Beginnner]

Hi, I would like to know how to call a module in vb.net?

I received this warning : TypeInitializeException was unhandled. The type initializer for 'SAPWVA.basDetail' threw an exception.

Below is my code.... Can anyone pls tell me whats wrong with my code?

Many thanks.

frmDetail :
Private Sub InitializeScreen()
With Me
gScrMode.Value = "INI"
.fraKey.Enabled = True
.lblStatus.Text = ""
.txtCustCode.Text = ""
...
..
.
Call basDetail.MenuControl(Me, 0, 0, 0, 0, 0, 0) ---warning shown at this line
.fraDetail.Enabled = True
.fraDetail.Visible = False
System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default
End With
End Sub
-------------------------------------------------------
basDetail :
Module basDetail
Dim GetDate As String
Dim StdRate As Decimal
Dim ctlMonth As Short
...
..
.
Dim vHexMth As New VB6.FixedLengthString("{0,-12}", "123456789ABC") 'YYH
'YYH -Amendment on Doc Ref, eg 0210 = 02A
Sub MenuControl(ByRef objForm As Object, ByRef V1 As Boolean, ByRef V2 As Boolean, ByRef V3 As Boolean, ByRef V4 As Boolean, ByRef V5 As Boolean, ByRef V6 As Boolean)
With objForm
.mnuCreate.Visible = V1
.mnuChange.Visible = V2
.mnuDelete.Visible = V3
.mnuSave.Visible = V4
.mnuCancel.Visible = V5
.mnuPrint.Visible = V6
End With
End Sub

 

[JuggaloBrotha]

here's what I see:

you're calling the method like this:
basDetail.MenuControl(Me, 0, 0, 0, 0, 0, 0)

and the method accepts this:
Sub MenuControl(ByRef objForm As Object, ByRef V1 As Boolean, ByRef V2 As Boolean, ByRef V3 As Boolean, ByRef V4 As Boolean, ByRef V5 As Boolean, ByRef V6 As Boolean)

so you need to call it like this:
basDetail.MenuControl(Me, True, True, True, True, True, True)

 

[VBNET_Beginnner]

Hi, thanks for the reply...but that did not solve the problem.

There's one guy telling me this :
A module isn't a class. If you change the Sub MenuControl(...) statement to include the Public keyword:

Public Sub MenuControl(...)

That should expose that subroutine to your project. You won't need to reference the module name, just the function name.
----------------------------------------------------------
But that also did not help...the warning is still shown at the same line.
What else could be the problem?...please help.

Many thanks.

 

[JuggaloBrotha]

so what does the warning tell you?

 

[VBNET_Beginnner]

The warning is the same as the previous one, which is :
TypeInitializeException was unhandled. The type initializer for 'SAPWVA.basDetail' threw an exception.

Ive also tried changing ByRef to ByVal in the Sub MenuControl...but the warning is still the same.

Please help.
Many thanks.

 

[cjard]

That should expose that subroutine to your project. You won't need to reference the module name, just the function name.

Whomever told you that advice, was not correct. Subs and Functions lacking a Public accessibility statement default to a Friend accessibility, whereby all items in the same project namespace can access this member. Whether you write Public or not, you must still qualify the use of the method by using the object name whereupon it is found, e.g. Module1.MySub

This will not change, because individual classes cannot be imported.

But that also did not help...the warning is still shown at the same line.
What else could be the problem?...please help.

Many thanks.

Why do you pass your form as an object?

Ive also tried changing ByRef to ByVal in the Sub MenuControl...but the warning is still the same.

That wont make the slightest bit of difference in this case; please dont use ByRef until you know what it does

 

[VBNET_Beginnner]

Hi, ive tried passing my objForm as frmDetail/
System.Windows.Forms.Form....but the result is still the same.

I really cannot figure out what's wrong with my code.

Please help.
Mant thanks.

 

[cjard]

Your code is bad Object Orientation, i'm afraid. Do not write code that messes with other objects, like your Sub MenuControl does. Instead, create a Form derivative that has this method. All your forms in your app should then descend from this.

The inheritance hierarchy becomes:

Form
+-MenuControllingForm
  +-Form1
  +-Form2
  +-Form3

etc


Never write code that takes an object X, and messes with it. That object X itself should be responsible for messing with its own data. Do not write any class to mess with X, put the code in X. If the code has to do a similar action for many different objects then the objects have a common element and can be the same family, they must descend from X

-

Dont call your variables V1, V2, V3 - all variables should start with a lowercase letter (distinguish them from properties and classes) and they should be proper words that make them identifiable. Why? Because in the intellisense you will see a tooltip that looks like:

[V1, V2, V3, V4 ...]

And you think "Hmm.. i want to switch off the file menu.. umm. which V# was that?"

now if it said:

[fileMenuVisible, printMenuVisible, helpMenuVisible ...]

It would be much more usable.

-

Do not use the word "Call" - it's no longer needed

Avoid hungarian prefixing - call variables proper names that infers their purpose, not their type. One exception is with form controls, where the type follows the purpose: userNameTextBox, okButton, topPanel, birthdayDateTimePicker

Avoid use of With, especially for long code sections

In System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default the System.Windows.Forms namespace should already be imported, you do not need to requalify it

Do not use ByRef until you can explain what it does.. That it is used entirely incorrectly in this situation suggests that you cannot

VB6.FixedLengthString is moot; in .NET, all strings are of a fixed length because they are immutable

 

[j00sh]

why avoid using With?

I always thought it was nice because pressing . brings up a nice list of your different controls

and no hungarian prefixes?

 

[StillLearning]

Thank you, thank you, thank you...

This stuff may seem like common sense to most people, but it's not knowledge you are born with... Thank you.
---------

Your code is bad Object Orientation, i'm afraid. Do not write code that messes with other objects, like your Sub MenuControl does. Instead, create a Form derivative that has this method. All your forms in your app should then descend from this.

The inheritance hierarchy becomes:

Form
+-MenuControllingForm
  +-Form1
  +-Form2
  +-Form3

etc


Never write code that takes an object X, and messes with it. That object X itself should be responsible for messing with its own data. Do not write any class to mess with X, put the code in X. If the code has to do a similar action for many different objects then the objects have a common element and can be the same family, they must descend from X

-

Dont call your variables V1, V2, V3 - all variables should start with a lowercase letter (distinguish them from properties and classes) and they should be proper words that make them identifiable. Why? Because in the intellisense you will see a tooltip that looks like:

[V1, V2, V3, V4 ...]

And you think "Hmm.. i want to switch off the file menu.. umm. which V# was that?"

now if it said:

[fileMenuVisible, printMenuVisible, helpMenuVisible ...]

It would be much more usable.

-

Do not use the word "Call" - it's no longer needed

Avoid hungarian prefixing - call variables proper names that infers their purpose, not their type. One exception is with form controls, where the type follows the purpose: userNameTextBox, okButton, topPanel, birthdayDateTimePicker

Avoid use of With, especially for long code sections

In System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default the System.Windows.Forms namespace should already be imported, you do not need to requalify it

Do not use ByRef until you can explain what it does.. That it is used entirely incorrectly in this situation suggests that you cannot

VB6.FixedLengthString is moot; in .NET, all strings are of a fixed length because they are immutable