Shorten the argument's "path" - vb.net

A short example of the problem I have:
Namespace ActivityLogger
Public Class XmlLoggerWriter
Enum XmlLoggerType
Information
Warning
Fault
End Enum
Friend Shared Sub WriteToLog(ByVal Type As XmlLoggerType)
'some code here
End Sub
End Class
End Namespace
And here is the call to the above sub:
Call WriteToLog(ActivityLogger.XmlLoggerWriter.XmlLoggerType.Information)
As you can see, the argument passed is quite lenghty, even though I have imported XML_Writer.ActivityLogger.XmlLoggerWriter.
I was hoping to get just the XmlLoggerType.Information part or even just the Information. Is there any way this can be shorten down? Because this will be used a lot throughout the code, and I like it to be simple and easily readable.

Import also XmlLoggerWriter:
Imports ActivityLogger.XmlLoggerWriter
Then this works:
WriteToLog(XmlLoggerType.Information)
If you also import
Imports ActivityLogger.XmlLoggerWriter.XmlLoggerType
you can even write
WriteToLog(Information)

Related

Prevent public module variables from being globally accessible

If I have the following code:
Public Module MyModule
Public MyVariable As Integer
End Module
VB.NET allows unqualified access to the variable (field) from anywhere in the project, which means I can write the following anywhere in the project1:
MyVariable = 5
Is there any way to disable this behavior on a specific type, such that I can only access the variable via the module name?
MyModule.MyVariable = 5
NB. I know I can use a standard class, and the Shared keyword on all the members:
Public Class MyModule
Public Shared MyVariable
End Class
1. If I use Friend instead of Public on the module, this functionality will only apply to the assembly, not the entire project.
First, those need not be Public to get the global variable behavior. Friend will also work:
The Friend keyword in the declaration statement specifies that the elements can be accessed from within the same assembly, but not from outside the assembly.
If you put your module in a different namespace, you can get the behavior you are after:
Namespace Plutonix
Friend Module GlobalVars
Friend MyVariable As Int32
End Module
End Namespace
Unfortunately, VB will prepend the project Namespace to whatever you use so your import would be something like:
Imports PrjNamespace.Plutonix
But then you get what you are after:
GlobalVars.MyVariable = 9
Personally, I think the class version or as few global variables as possible is better

Can't access methods in DLL

Using asp.net/vb.net. Created a solution with 2 projects, "MainProject" and "MyCommonStuff". The 2nd project ("MyCommonStuff") is really a common utilities class, the resulting dll I hope to use for other projects as well.
MyCommonStuff is defined very simply....
Public Class MyCommonStuff Stuff
Public Shared Function GetInfo() as string
:
:
End Function
Public Shared Sub Test
:
:
End Sub
:
End Class
In MainProject I set a reference to this MyCommonStuff project.
I want to access some of the MyCommonStuff methods in my code. But for some reason the methods are not being recognized.
For example, in a button in the MainProject I tried this....
dim m as new MyCommonStuff
x = m.GetInfo()
Intellisense doesn't pick up any of the subs/functions for m. What am I doing wrong? Thanks!
The thing is that you've made your methods static ("Shared" in VB). You need to either remove the Shared keywords:
Public Function GetInfo() As String
':
':
End Function
Public Sub Test()
':
':
End Sub
or keep the Shared keywords and use it like this:
x = MyCommonStuff.GetInfo()
Here is some information about Shared members. Most notably:
Specifies that one or more declared programming elements are
associated with a class or structure at large, and not with a specific
instance of the class or structure.
In other words, if you want to use your methods from an instance of your MyCommonStuff class, e.g. m in m.GetInfo(), you need to leave the Shared keyword off. If, on the other hand, you have a method that is common across all instances of your class or for which you don't even need an instance, you would use the Shared keyword and access the method like I said above, e.g. MyCommonStuff.GetInfo().
Make sure you're importing you common stuff's namespace.

How would I declare a global variable in Visual Basic?

I want to create a variable that can be used across multiple forms.
It's going to be a temporary storage place for integers.
There are a couple of ways to do this in VB: a VB-specific way and a non-VB specific way (i.e. one that could also be implemented in C#.
The VB-specific way is to create a module and place the variable in the module:
Public Module GlobalVariables
Public MyGlobalString As String
End Module
The non-VB-specific way is to create a class with shared properties:
Public Class GlobalVariables
Public Shared Property MyGlobalString As String
End Class
The primary difference between the two approaches is how you access the global variables.
Assuming you are using the same namespace throughout, the VB-specific way allows you to access the variable without a class qualifier:
MyGlobalString = "Test"
For the non-VB-specific way, you must prefix the global variable with the class:
GlobalVariables.MyGlobalString = "Test"
Although it is more verbose, I strongly recommend the non-VB-specific way because if you ever want to transition your code or skillset to C#, the VB-specific way is not portable.
IN VB6 just declare on top code
public GlobalVariable as string
then you can use GlobalVariable in any form as you like.
like
GlobalVariable = "house"
then you can use /call in other form
text1 = GlobalVariable
will show value "house"
You can just add it as PUBLIC to ANY Module
Example:
Module Module1
'Global variables
Public glbtxtTemplateName As String 'GLOBAL VARIABLE FOR TEMPLATE
VB loads the Modals first as a class and all PUBLIC items therein are shared directly. Think about it this way.
Lets say we have a MODULE called "MY_PROCESSES"
When you declare a SUB or a FUNCTION in "MY_PROCESSES" if you want it to be used OUTSIDE of "MY_PROCESSES" you declare as PUBLIC like this
PUBLIC SUB LOAD_TEMPLATE()
....
To get to LOAD_TEMPLATE you just call it in your code from anywhere:
LOAD_TEMPLATE
So if I need to set or use the global variable that I made public in my module I just refer to it by name:
glbtxtTemplateName="TEMPLATE_NAME"
IF glbtxtTemplateName="" then LoadTemplate
I do like building the class as above because you can reference it faster without remembering the variable but if you only need 1 or 2 global variables you can name them like we used to with Hungarian Notation style name.
This method is really quite simple and elegant. Old is new and New is Old.

How to implement an interface in VB.Net when two methods have the same name but different parameters

I am a C# programmer but I have to work with some VB.Net code and I came across a situation where I have two methods on an interface with the same name but different method parameters. When I attempt to implement this interface in a class, VB.Net requires explicitly declaring "Implements MethodName" after the method signature. Since both method names are identical, this is confusing the compiler. Is there a way to get around this sort of problem? I suspect this must be a common occurrence. Any thoughts?
N.B. This was more a case of the programmer not verifying that the interface in question had not changed from underneath him.
How is this confusing the compiler?
The compiler expects to find an implementation for every method signature, and distinguishes the implementations by their signatures.
If the signatures are identical/undistinguishable (in most cases it means that the arguments are of the same types in the same order) you'll get a design-time error related to the interface, saying that the two methods cannot overload eachother as they have the same signature.
So, in any case, the compiler should not be confused.
Should you need further assistance, please attach a code sample - these things are relatively easy to resolve.
Tip: When writing the implementation, as soon as you write down "implements MyInterface" and hit Enter - Visual Studio will create a "skeleton" code of the implementation, which saves you writing the method signatures and correlating them to the interface.
Example code of having two methods with the same name and everythign working well:
Interface MyInterface
Sub MySub(ByVal arg0 As DateTime)
Sub MySub(ByVal arg0 As ULong)
End Interface
Class MyImplementation
Implements MyInterface
Public Sub MySub(ByVal arg0 As Date) Implements MyInterface.MySub
...
End Sub
Public Sub MySub(ByVal arg0 As ULong) Implements MyInterface.MySub
...
End Sub
End Class
You can make the method private and give it another name.
Like:
Private Sub SaveImpl(ByVal someEntity As IEntity) Implements IRepository.Save
this will look to the outside like: someRepository.Save

Implementing "partial void" in VB

I'm following along with an excellent Scott Guthrie article (MVC form posting scenarios) and trying to convert it to VB along the way. I've got everything working except one piece. At one point in the article he's adding his own business rules to a LINQ to SQL entity like this:
public partial class Product
{
partial void OnValidate(ChangeAction action)
{
...
}
}
In converting it to VB, I'm not sure how to translate the "partial" part of OnValidate. If I do this:
Partial Public Class Product
Private Sub OnValidate(ByVal action As ChangeAction)
...
End Sub
End Class
then the business rules I put in OnValidate work, but it doesn't throw any exceptions for bad data (i.e. character in a decimal field), which makes sense, since I'm basically overriding Product's validation.
What's the syntax to make sure the underlying class's OnValidate executes in addition to my version?
Edit: Note that making OnValidate "Partial Private Sub" produces the following errors:
Partial methods must have empty method bodies.
Method 'OnValidate' cannot be declared 'Partial' because only one method 'OnValidate' can be marked 'Partial'.
Partial Private Sub OnValidate(ByVal action As ChangeAction)
...
End Sub
As usually happens, the problem lied elsewhere in the code. I had switched from "UpdateModel" to "TryUpdateModel" somewhere along the way, which means simple assignment errors were no longer being thrown. Going back to "UpdateModel" and using "Private Sub OnValidate" as above now works as it should.
OnValidate is already marked as "Partial" in the data context because it is meant to be overridden - I wasn't clobbering the underlying code after all.
marking it as private does the implemetation
'designer'
Partial Class Product
' Definition of the partial method signature.'
Partial Private Sub OnValidate(ByVal action As ChangeAction)
End Sub
End Class
'your implmentation'
Partial Class Product
' Definition of the partial method signature.'
Private Sub OnValidate(ByVal action As ChangeAction)
'do things'
End Sub
End Class
see this http://msdn.microsoft.com/en-us/library/bb531431.aspx