Printable View
A basic question, but for someone who does not know the answer, it's not that basic.
Looking at Object orientated programming a function within a class can be defined as
Public Shared function Nameoffunction()
In this case the function can be called without creating an instance of it.
However, when simply creating Module containing sub routines / functions
Public function nameoffunction()
Will suffice. This can also be called in the same way,
Hence what is the difference.
I would suggest Googling Shared / Static Method vs Instance Methods.
With a module, you don't need to fully qualify a call. With a shared method you do.
Have you looked at this
http://msdn.microsoft.com/en-US/libr...=vs.90%29.aspx
Modules are quietly turned into classes with ALL Shared methods. The difference between a module and a class with all Shared methods is that you don't need to use the module name to decorate the function. The reason this was done is because this is how Modules worked in VB6, so the compiler handles them a bit differently to make them more familiar to those coming from the older language.
As Shaggy says, modules in VB.NET have been designed to work the same way as modules in VB6, i.e. any method declared in a module can be called with instantiation or qualification. C# has no VB heritage so it has no modules. In C#, a class can have 'static' methods just a class can have Shared methods in VB.NET. Those methods can be called on the class itself rather than an instance of the class. In C#, you can also have static classes. A static class is one that you cannot create an instance of even if you want to and all members must be static. VB.NET has no Shared classes. In VB.NET, modules provide the same functionality as static classes, i.e. you cannot create an instance of a module and all members are implicitly Shared. When you build your VB.NET project, modules are compiled the same way static classes are in C#.
You can prevent instantiation of a class in VB.Net by declaring all its constructors "Private".
That's not strictly true because even if all the constructors are Private then the class can still instantiate itself. A C# static class and VB.NET module simply cannot be instantiated. You would only make all constructors Private if it was your intention to create instances internally only, e.g. a singleton class. If it's your intention that a class never be instantiated in VB.NET then you should use a module rather than a class.Quote:
Originally Posted by Niya
One thing that I do find quite amusing is that, while VB.NET is considered to be a weak/dodgy language by many, including many C# developers, there is a fair proportion of VB.NET developers who frown on using modules while I've never seen one C# developer against using static classes. Modules are perceived by some as a VB6 holdover that break OO principles. They are not. They are simply the VB.NET implementation of static classes. If you want the functionality of a static class then you should use a module. I'm all for best practice, not using GoTo, etc, and I for one have no issue using modules because there is no issue using modules. Using modules is best practice in VB.NET. As an example, if you want to declare an extension method in C# then you must do so in a static class. In VB.NET, all extension methods must be declared in a module.
Hmm...I'm curious. How would C# perceive a module created by the VB.Net compiler in an assembly ? I'm guessing a static class ?
You guess correctly. Try creating a C# project and referencing the Microsoft.VisualBasic.dll assembly. You can then use stuff like MsgBox in a C# app. C# doesn't know anything about modules though, so it doesn't provide the facility to refer to a member unqualified. As a result, you would have to use 'Interaction.MsgBox', where Interaction is the module (interpreted as a class by C#) that the MsgBox method is a member of.Quote:
Originally Posted by Niya
Nice...I just tried your suggestion. Its frightening how limited the IDE behaves when C# is the language being used. Took me about a minute to figure out I had to import the Microsoft.VisualBasic namespace manually. The IDE under VB would have known this and suggested an auto-correct scenario.
It took you a minute to work out that you had to import a namespace in order to use one of its member types? I'm going to point at you and laugh now. :lol:Quote:
Originally Posted by Niya
Hope you had a good hearty laugh ;) I'm spoiled by the IDE that way.Quote:
Originally Posted by jmcilhinney
When I need to use a class, I just type it in and click the squiggly line that shows up when the IDE can't resolve it and the IDE automatically imports whatever namespace it needs to get it working so I'm not used to knowing exactly what namespace specific classes are defined in. I only know a few like System.ComponentModel for things like DefaultValueAttribute since I use it so regularly.
*cough* *coughcough*Quote:
Originally Posted by jmcilhinney
It's not the namespace import, it's the assembly reference. VB Projects default to referencing the Microsoft.VisualBasic assembly, whereas C# projects do not. Once the assembly is referenced, the IDE will suggest importing the namespace whether it's C# or VB.Quote:
Originally Posted by Niya
Actually, I had already imported the assembly. After when I referenced the class, the IDE highlighted the error and when I hovered the mouse over it, it didn't offer any suggestions. I had to go back and manually type the import in.
I imported the assembly as shown here:-
Attachment 99657
Yet:-
Attachment 99659
I hovered the mouse where the red arrow is pointing and that gray tooltip is all that pops up. If it were VB, it would give the option to automatically import the namespace.
No, you referenced the assembly.Quote:
Originally Posted by Niya
And it works for me:
Oh, right, I see. You need to either hit Ctrl+. with your cursor on the name to get the resolve menu up (what I did in my screenshot), or right click on the word and use the Resolve menu on the pop up menu. I don't really think about doing that any more. (Well, actually I did have to think about it because I normally use Resharper's Alt+Enter command to fix... well, everything.Quote:
Originally Posted by Niya
Here is what I expected:-
Attachment 99663
I attempted to use the File class without a namespace import and the IDE offers to import the relevant namespace for me.
OMG You're right. I got it work now. Also, it seems that selecting the bad reference brings up the suggestions window as well.Quote:
Originally Posted by Evil_Giraffe
[EDIT]
Correction....just clicking on the bad reference does it, not necessarily selecting it.
Ok, I think I get the hang of this. Basically if its a shared function, and no instance is created of it (called directly) and using vb, then it's best to put it in a module.
Now in one of my programms, i have a 'private sub' defined. Now if I move it into a module, I guess it has to become public as effectively it is in a different class.
When I do this, it generates an error, as there is a
If me.invokerequired then
Statement in the code, and it does not recognise me.
How do I resolve this problem so that the routine can be used in any of my code.
The code is a display routine, for the UI being called from another's thread.
What I would like to do is put all these routines into a single module, for use in any of my progs, but can't see a way round the me.invokerequired statement.
It would have to be public to be called by anything other than another method in the module.
As for the issue, the method you are talking about is explicitly making use of an instance of a form. You could pass that form in as an argument to the method, but you should ask yourself whether it really makes sense to put such a method in a module in the first place. If the function interacts with a form, then it HAS to interact with some instance of that form, so why wouldn't it be a member of the form rather than a member of the module?
Consolidating common code can have advantages, but you can also overdo it. Is there a routine so common that a whole series of forms will all be able to meaningfully make use of it? If so, then a method in a module that is passed a form instance might make sense, but that's kind of rare. Drawing tends to be form specific.
Let me try and explain, When I wrote the code, it was my understanding (which I still believe to be correct) that if you run all the code on the UI thread, when long running code is processing, the UI effectively freezes until the code has finished running (or you allow the UI to refresh).
Hence, whenever an option is selected that processes some code, I start a new thread. This then does not lock the UI.
The thread that is running can not however interact directly with the UI as they are running in different threads. I have always been told that cross thread processing is not a good idea. What you should do is check to see if its the same thread and invoke it.
As such I have written a lot of different routines to interact with the UI from different threads. A few examples are below.
It is these that I am trying to put into a module so that I can use them for all applications that I write. They all however reference me.Code:Private Delegate Sub DThread_InvalidateInvoker(ByVal ctl As Form)
Private Sub DThread_Invalidate(ByVal CTRL As Form)
If CTRL.InvokeRequired Then
CTRL.Invoke(New DThread_InvalidateInvoker(AddressOf DThread_Invalidate), CTRL)
Else
CTRL.Invalidate()
End If
End Sub
----------------
Private Delegate Sub DThread_UpdateInvoker(ByVal ctl As Form)
Private Sub DThread_Update(ByVal CTRL As Form)
If CTRL.InvokeRequired Then
CTRL.Invoke(New DThread_UpdateInvoker(AddressOf DThread_Update), CTRL)
Else
CTRL.Update()
End If
End Sub
-----------
Private Delegate Sub DThread_ToolstripMenuItemRemoveInvoker(ByVal menuItemName As ToolStripMenuItem, ByVal item As ToolStripMenuItem)
Private Sub DThread_ToolstripMenuItemRemove(ByVal menuItemName As ToolStripMenuItem, ByVal item As ToolStripMenuItem)
If Me.InvokeRequired Then
Me.Invoke(New DThread_ToolstripMenuItemRemoveInvoker(AddressOf DThread_ToolstripMenuItemRemove), menuItemName, item)
Else
menuItemName.DropDownItems.Remove(item)
End If
End Sub
-------------
Private Delegate Sub DThread_ToolstripMenuItemvisibleInvoker(ByVal menuItemName As ToolStripMenuItem, ByVal value As Boolean)
Private Sub DThread_ToolstripMenuItemVisible(ByVal menuItemName As ToolStripMenuItem, ByVal value As Boolean)
If Me.InvokeRequired Then
Me.Invoke(New DThread_ToolstripMenuItemvisibleInvoker(AddressOf DThread_ToolstripMenuItemVisible), menuItemName, value)
Else
menuItemName.Visible = value
End if
End sub
So not shared functions or indeed functions of any kind then?
You remember when Shaggy said you could overdo things? You have cross thread invokes for the visibility of a control? Seriously? What could possibly be sufficiently time consuming to warrant a separate thread of which the chief output is a change of visibility of a menu item? And more to the point how many times in coding lifetime are you going to need an invoke of that nature? This appears to be a galloping case of coding for coding's sake. Yes, you should avoid over-burdening the UI thread, but that doesn't mean avoiding it altogether. If the principal target of a routine is the UI, put it on the UI!
And now you want to generalise subs so specific that they challenge counting the number of angels on the head of a pin for pernicketiness? It just doesn't make sense at any level.
Find out how long running the process is before deciding whether to thread, then thread only as much as is needed. Generalizing invocations is probably impossible, as you shouldn't be able to say what it will be that you are invoking, unless all your forms happen to be the same.
Really? So you object to the File and Directory classes in the System.IO namespace? They are both static classes. Unlike the FileInfo and DirectoryInfo classes, File and Directory don't represent a single file or folder. They just contain file- and folder-related functionality. As such, creating an instance doesn't make sense so the classes have been defined such that doing so is impossible. I'm certainly not advocating using static classes or modules willy-nilly (and modules certainly do tend to get over-used in VB in place of good programming practice) but they have their place and their use doesn't inherently break any rules of OOP as some people claim.Quote:
Originally Posted by Evil_Giraffe
I obviously misread your original point, because I thought you meant writing static classes of my own. As far as using static classes, I would not depend on them from my main application classes, but instead wrap them up behind a higher-level abstraction, so yeah I guess I still kinda "object" (haha, was that intentional?) to them. And not just static classes - what about DateTime.Now, eh? Now that's a pain in the rear.
Or even better, write a form based super-class with that method in it and inherit from it.Quote:
Is there a routine so common that a whole series of forms will all be able to meaningfully make use of it? If so, then a method in a module that is passed a form instance might make sense, but that's kind of rare.
Absolutely agree and they also have a performance implication. If, for example, a class doesn't require state then forcing an instantiation is just wasteful. My rule of thumb is that if your writing a Module or static class you've probably got some bad design (at least in OOP terms)... but not neccessarily. It's time to stop and think about your design but not necessarily time to throw it away.Quote:
their use doesn't inherently break any rules of OOP
Ok, let me try and explain why I have written it like this and hopefully it will become more clear.
Origionaly the programme did not use more than one thread, and was all run on the UI thread. When I selected certain functions (that ran for a long time, potentially many hours processing data) the UI was not being updated as I expected. As such, and with a great deal of effort on my part, as I a) did not understand multi threading, b) did not understand why things had to be invoked, I set about converting it. The ultimate result was success, although the coding may not be great, I learnt a lot.
The separate threads primary objective was to process data, not update the screen display, although that is requirement albeit a very small part. The data processing also had pauses encoded in it of specific but small duration. Hence pausing the UI thread did not seem to be a good idea.
Routines and functions that were of a simple nature and over very quickly were left on the UI.
Shaggy Hiker seems to confirm my suspision that generalising these routines probably impossible, however I guess that that is my main query.
If this proves to be the case, then I guess what I am trying to do is impossible. Will have to revert to the old method of copy & paste.
You might want to look at the BackgroundWorker component. That might suit very well, as it raises the ReportProgress event on the UI thread. Therefore, whenever you need to update the UI, you can raise that event, and shouldn't need to do any invocation in the event handler for that event.
I strongly disagree with this. I use a quite a few static classes in my apps for things that just wouldn't make sense anywhere else. For example, I have a project that contains a wide assortment of custom controls and components and there are quite a few things they all do in common. Eg. Certain rectangular based operations like stacking rectangles or finding what Form a control belongs to even if its nested inside several nested containers on that Form. It makes sense to put them all in one place where any of my components can use them. There is no better place than in a static class/module. And don't get me started on P/Invokes ;)Quote:
Originally Posted by FunkyDexter
Static classes/modules have their place and I would strongly encourage their use when it seems best.