auxcom Posted August 9, 2004 Posted August 9, 2004 Im moving from VB to C#. What is the equivalent of a Module in C#? In VB, I declare all my global variables, constants and functions in a Module. And lastly, in the code editor, what is the shortcut key to delete a line. Thanks! Quote
sjn78 Posted August 9, 2004 Posted August 9, 2004 You don't have modules in C#. You can create a class to store variables though. Quote
PWNettle Posted August 9, 2004 Posted August 9, 2004 Typically you should always attempt to design your .Net (OOP) projects such that you maintain tight control over information flow, by passing values when and where you need them via properties and constructors. VB6 was a mix of procedural and OO coding, and somewhat allowed us to be a little sloppy with excessive global/public constructs - .Net's more pure OO orientation requires a little more design thought - if you spend more time on design you can usually get past the need for so many (logic error inducing) public/global constructs. Still, sometimes it can be handy or necessary to have some type of global data or functionality. In C# you can do this by creating static methods in a class (in VB.Net the Shared keyword is used instead of 'static' - VB.Net offers modules but they're not really an OO feature). Sometimes you also want to declare the class as Abstract too - so that the class can ONLY be used as a helper class (cannot be instantiated). Static properties and methods are utilized directly from the class itself - you don't have to instantiate an object of the class to use them. We use static stuff all the time with the .Net framework - for example, if you do something like: int nNumber = int.Parse("1"); // Using the static Parse method of the int class You are using a static method. We use them all the time. It's possible to combine static behavior with a typical class as is done with the int, string, etc objects - you can instantiate them, and they offer static functionality useful for the theme of the class. At my work (and in my personal coding) we sometimes use these types of classes to expose our commonly custom utility functions or as a wrapper for config files that expose encrypted values like connections strings and other settings. To create your own pseudo global/helper class you'd make it look something like this: using System; using System.Windows.Forms; namespace General_Testing { public [b]abstract[/b] class PseudoGlobalStuff { protected [b]static[/b] string m_sSomeStringValue = "Hello world!"; // Static property acting as a pseudo constant. public [b]static[/b] string SomeStringValue { // This one returns a value set by a static variable. get { return m_sSomeStringValue; } } // Static property acting as a pseudo constant. public static int SomeIntegerValue { // This one returns a hardcoded constant value. get { return 99; } } // Static member that does something. public static void HelloWorld() { MessageBox.Show("Hello World!"); } // Static member that returns a value. public static int AddSomething(int nNumberOne, int nNumberTwo) { return nNumberOne + nNumberTwo; } } } One thing to keep in mind is that there is no instance when you use static stuff - so you can't SET values - only use them as read-only - you need an instance to actually store values. But, you can have your static properties/members read from config files, registry, database etc such that they can provide dynamic values from other sources. You'd use the static stuff in the sample class above with something like this: // Do stuff with the pseudo global class: // Call its members. int nTotal = PseudoGlobalStuff.AddSomething(2, 4); MessageBox.Show(nTotal.ToString()); PseudoGlobalStuff.HelloWorld(); // Use its pseudo constant values: MessageBox.Show(PseudoGlobalStuff.SomeStringValue); MessageBox.Show(PseudoGlobalStuff.SomeIntegerValue.ToString()); Notice that no instance is ever created - so you can use the 'PseudoGlobalStuff' class from anywhere in the project. In fact, in this case, because of the Abstract modifier on the class declaration you get a compilation error if you try to instantiate the class. You can use a "normal" class to expose your constants and "global" functionality but then you have to instantiate it everywhere you want to tap into it. The advantage to using static properties and methods is that you don't have to worry about creating and/or maintaining instances. And lastly' date=' in the code editor, what is the shortcut key to delete a line.[/quote'] Shift + Delete (while your cursor is on the line to delete) I use the keyboard as much as possible, and use home, end, arrows, and shift to do most of my selecting and clean-up (holding show shift while using any of those other controls makes a selection - which is generally much quicker than messing with the mouse). So: Home + Home (twice to get to the leftmost edge of a line) then Shift + Down Arrow then Delete (while the cursor is on the line to delete). ...will also delete a line - the 2nd method is more keystrokes but I'm so used to it that it happens in a blur regardless. And once you get used to doing all this you can incorporate the ctrl keys for word selection...but I digress (and you might already know all of this!). Paul Quote
auxcom Posted August 9, 2004 Author Posted August 9, 2004 Wow! Thank you so much.... great explanation and examples! Thanks again. But another questions :-), in VB it have the With.. End With statements. What is its equivalent in C#? Quote
PWNettle Posted August 9, 2004 Posted August 9, 2004 There is no direct equivalent that I know of. You might check out 'using' but I don't think it provides the exact same functionality. Paul Quote
Administrators PlausiblyDamp Posted August 9, 2004 Administrators Posted August 9, 2004 There is no C# equivalent for the vb With ... End With construct :( using is a replacement for the VB.Net imports statement and also is used when dealing with classes that support IDisposable - giving a form of deterministic cleanup. e.g. using (System.Data.SqlClient.SqlConnection conn = new System.Data.SqlClient.SqlConnection()) { //use conn here } //connection will automatically be closed here also as an aside - if you want classes that contain nothing but static (shared in vb) methods and not allow the class to be instantiated then rather than making the class abstract (as people could still inherit from the class) you may want to use a protected constructor (that's how this is done in the framework e.g. MessageBox) e.g. public class Test { protected Test() { //not visible from calling code so cannot create a class } public static void Method1() { //Do something } } Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
VBAHole22 Posted August 9, 2004 Posted August 9, 2004 For global constants couldn't you just use the AppSettings from either App.config (forms) or web.config (html)? I use these quite a bit for constants like connection strings. No sense passing stuff llike that around when they don't change. Quote Wanna-Be C# Superstar
PWNettle Posted August 9, 2004 Posted August 9, 2004 if you want classes that contain nothing but static (shared in vb) methods and not allow the class to be instantiated then rather than making the class abstract (as people could still inherit from the class) you may want to use a protected constructor (that's how this is done in the framework e.g. MessageBox) I was wondering exactly how to make a class that couldn't be instantiated or inherited (since you can't mix abstract and sealed) - but I was too lazy to figure it out at the time. I tried the protected constructor and it did prevent instantiation but I was still able to do inheritence. The modified class looks like this (top only): public class PseudoGlobalStuff { protected static string m_sSomeStringValue = "Hello world!"; protected PseudoGlobalStuff() {} // protected constructor And I made a barbaric test class to see if I could inherit: using System; using System.Windows.Forms; namespace General_Testing { public class Class1 : PseudoGlobalStuff { public void Test() { MessageBox.Show("Hello World!"); } } } ...in the same project and it compiles fine and I'm able to instantiate and use Class1 just fine: Class1 oTest = new Class1(); oTest.Test(); ...so what's missing to make it both uninheritable and non-instantiable? For global constants couldn't you just use the AppSettings from either App.config (forms) or web.config (html)? I use these quite a bit for constants like connection strings. No sense passing stuff llike that around when they don't change. Yeah - but sometimes it's nice to wrap the config files so that you have an object that exposes properties. For example, at my work, where we mostly do web apps, we have a big section of encrypted values in our web config(s). We wrap the app settings of the web.config with an object so that we can decrypt those values and because it's far easier to locate the "key" you want when it pops up via intellisense than it is to remember every little value buried away in the config file. Only a few of us maintain and/or modify our config files and it's easier to just say, "use the AppSettings" object and look for "blah blah" property. Also due to the encryption we can't just add a new key/value to the config - we have a special tool we use to rewrite the entire config with encryption via the same object we use to read the values. As a side note, the way we wrap our web.config ended up being a big help. I originally created the wrapper object at the suggestion of a supervisor for convenience. Over time we'd change how we pulled from web.config as we touched projects in our main, massive web app product. Originally our settings were not encrypted - it was done for convenience. A few months ago we had to switch to using highly encrypted values in our databases and web.configs. All we had to do to make the switch to encryption was develop the encryption stuff and implement it in the wrapper object. We didn't have to modify a single project because they all already used the wrapper - the only thing that changed was the implementation within the wrapper. This ended up saving a lot of time. So, if you're a solo coder with full control over design and implementation you might not need or want to wrap your configs and/or expose them in a class - but I think for team-based and/or larger scale projects it can be a good idea. I think MS is doing more with app config in the next version of .Net and they currently provide an "application block" that completely overkills the config situation. Paul Quote
Administrators PlausiblyDamp Posted August 9, 2004 Administrators Posted August 9, 2004 Not got VS on this machine but I'm fairly sure you can mark the constructor private rather than protected and if the then also mark the class as sealed it should cover both eventualities. public sealed class Test { public static int SomeValue; private Test() { } } Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
PWNettle Posted August 10, 2004 Posted August 10, 2004 Yeah, that works - but in my test I kept my member variable as a private. I could compile with the constructor as protected but it gave a warning - it liked private better. This is how we setup our helper classes at work, but I was too lazy to look at my work codebase in the first place. :-/ Paul PS - took a while to get back to this with work and all getting in the way! :) Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.