snarfblam

Sounds like you get the idea of object oriented programming. To keep it from being complex you just need to keep it clear in your head (and in the code) of how classes interact with eachother. If a class gets too complicated, break it down into multiple classes (i.e. an invoice class could be broken down into a CustomerIdentity class, a ServicesRendered class, and a PaymentMethod class).

The idea with a try/catch is that if an exception is caught in the try block, none of the remaining code in the try block is valid (i.e. is acceptable to run in this erraneous state). My advice would be to get your hands dirty with try/catch blocks so that you become familiar and comfortable with them, and learn how to use them effectively. If you are worried only about a single line or a few lines of code throwing an exception... Sub Bad() On Error Goto handler txtMyTextBox.Text = SomeObject.SomeProperty Me.Text &= " [Complete]" Return Handler: txtMyTextBox.Text = "(Nothing)" Resume Next End Sub ...you can wrap only those lines with a try/catch... Sub Better() Try txtMyTextBox.Text = SomeObject.SomeProperty Catch(Ex As NullReferenceException) txtMyTextBox.Text = Nothing End Try Me.Text &= " [Complete]" End Sub The latter only catches an error rising from a null reference. With the first, any kind of expection could be thrown, and if it isn't what you were expecting, something bad could happen. If you are worried about any one of many lines throwing an exception, all I have to say is that it is very rare that it can be a good idea to plow through a function regardless of what goes wrong. You should generally identify potential problems, reduce chances of them occuring, and handle the errors that do arise in a manner as specific and appropriate as possible. With VB6-style blanket error handling it is very easy to handle the wrong error the wrong way, which is why it is so often discouraged. But to answer your question: there is no completely analogous method to emulate ResumeNext, except perhaps wrapping each statement in a try/catch block.

I don't know if it is a good idea to double the forums. Perhaps 2.0 users will just kinda forget that the 1.1 topics are there and people won't get advice they otherwise would. I agree that this is an issue that should be addressed somehow, though. As far as someone not being aware that a feature is present in 2.0, that's someone not doing simple research (google, object browser) before they post. For the time being, perhaps the best approach would be to check someone's profile to see which version and which language they are using.

What you need to do is perform logic on a second thread, instead of running the UI on a second thread. As far as updating UI elements, this must be done on the UI's thread, but can be invoked from another thread using the Control.Invoke or Control.BeginInvoke methods.

Mnemonics seem to work for me with owner drawn context menus. It might be worth mentioning that there is an overload for DrawString which takes a StringFormat object which allows you to render text with underlined mnemonics. MyStringFormat.HotkeyPrefix = System.Drawing.Text.HotkeyPrefix.Show; MyStringFormat.HotkeyPrefix = System.Drawing.Text.HotkeyPrefix.Show

Instead of playing 350 textboxes onto each tab, you might want to consider using a grid-based control (DataGrid maybe? I've never used one. Excel sheets are another option.) on each tab page to cut way down on the number of contols. Another very useful memory saving technique would be to re-use controls. Instead of loading 350 textboxes or one datagrid/spreadsheet/whatever per tab, load 350 textboxes or one datagrid/spreadsheet/whatever PERIOD (if you are using textboxes you might want to put them all in a panel within the tabpage). Then, when the user selects a different tab, load the relevant data for that tab into the existing controls and move the controls (or the panel containing the controls) to the selected tab. This way you save yourself a great deal of duplication. Hopefully someone else who works with data more can give you some specific advice about appropriate controls.

Yes, GDI+ gives you many ways do define a curve, but those ways do not include defining a curve by points it does not contain. Microsoft isn't that nice.

C# and VB both contain short-circuited and non-short-circuited logical operators: AndAlso 'Short-circuited And 'Not short-circuited && // Short-curcuited & // Many people don't realize that in addition to // being a boolean operator, & doubles as a non- // short-circuited logical operator. There are reasons for using non-short-circuited logical operators, specifically side-effects. Though you see side effects alot more in C++, there are a couple of places they can be seen in VB (and C#). If the two operands of your logical operator are functions that perform certain tasks, you may want to make sure that both tasks are performed, regardless of whether the first one returns a true value. Take a look at the following code: Dim Number As Integer = 0 Const NumLimit As Integer = 9 Dim Character As Char = "A"c Const CharacterLimit As Char = "Z"c Public Sub ExperienceSideEffects() While (AdvanceNumber() And AdvanceChar()) 'This loop will cause both Number and Character to 'advance until they both reach their limits End While While (AdvanceNumber() AndAlso AdvanceChar()) 'This loop will advance Number until it reaches 'its limit, and only then will it begin to advance 'Character. The loop will terminate when Character 'reaches its limit. End While End Sub ' Increments 'Number' and returns true if it reaches its limit Private Function AdvanceNumber() As Boolean Number += 1 If Number > NumLimit Then Number = NumLimit 'Number shouldn't go past limit Return (Number = NumLimit) End Function ' Increments 'Character' and returns true if it reaches its limit Private Function AdvanceChar() As Boolean Character = ChrW(AscW(Character) + 1) If Character > CharacterLimit Then Character = CharacterLimit Return (Character = CharacterLimit) End Function The side-effect in the first loop is causing certain values to be incremented, which would not happen with short-circuiting. Using the two different operators will have signifigantly different results. Although the I personally wouldn't write a loop like the first one, and it can be constructed less ambiguously, the first loop will execute in a manner closer to what one would expect than the second loop.

I never really appreciated the Is operator in the first place. I understand that it is there to avoid confusion between equal references and equal values, but people seem to get the right idea when using C#. I actually started writing code like this when I switched over to C#: // Before it occured to me to use the != operator for reference types if(!(MyObject == e.Sender)) { // Do things and junk }

DLLs will all be loaded into memory and must all be distributed. Generally, all you will be doing is not only increasing the number of files to distribute, but actually increasing data size by creating several assemblies instead of one. As mentioned by Mister E, DLLs are generally used when a certain common functionality is required by multiple assemblies. I also agree that three thousand textboxes on a single form represents some poor design concept. Something really ought to be broken down more or browsed in a different manner. I would say that the most important thing you can do at this point is review, revise, and optimize your design, though this may be easier said than done.

In VB8 Express, they are not listed in the solution explorer, but there is nothing keeping your from browsing to them in Explorer and opening them from there. In other words, they are inaccessible from the IDE. Hmm... magic codeless forms and default instances... kinda reeks of VB6. I moved to C# because the direction VB is taking strikes me as regressive (keep in mind that that's just my opinion).

kurf, you don't seem to understand the point of these forums. They aren't here so that you can complain about them (or did you just discover the "Suggestions, Bugs, and Comments forum"). If you have a question about programming (that satisfies the posting guidelines) we will all be glad to help. I can't see anyone writing new message board software for these forums when there is already so much out there. Should we re-invent the wheel because you are particularly fond of ASP.NET? Regardless of your opinion, PHP and vBulletin seem to be getting the job done for everyone else. If it bugs you that much, feel free to write your own ASP.NET based programming forums.

Yes If someone posts VB code (maybe C# too) without breaking up long lines it will cause that, since VB code boxes aren't scrollable like normal code boxes. That is inconvinient, but not really messed up. Any other problems like that could either be a bad forum skin or your browser, but I don't have the said problem.

Excuse my bluntness, but you have quite a way of saying thank you. I simply can't imagine what kind of answer you were expecting. And no one is missing anything. We provided examples of how to simplify something potentially complex. Extracting functions and using abbreviated syntax would be senseless in a relatively simple situation. It is when it becomes complex that you should consider our tips. My point was that there is a programming construct designed for a situation where only one of many possibilities may occur. The more complex the situation becomes, the more "else if"s and equality operators and returns you can replace with simple "case"s. As for multiple keys performing the same function: you can have multiple cases execute a single block of code: switch(whatever) { case 0: function0(); break; case 1: function1(); break; case 2: // Perform the same function for cases 2, 3, and 4 case 3: case 4: function2(); break; case 5: function3(); break; } If a case has only a line or two of code, don't extract a function. If it is longer, do extract a function. There is no rule stating that either all cases call a function or all cases execute local code. If you are worried about having too many functions, then ask your self whether you want one hundred clearly named functions that perform one hundred clearly defined operations or one single function which has one hundred unnamed operations embedded in a switch, or worse yet mixed in a tangled web of elseifs. And if you create a function for each operation you can use the same function elsewhere, for example, in response to a menu selection or a button click.

I know it might sound crazy, but... // More appropriate program control flow structure if(e.Control) { switch (e.KeyValue) { case 83: SaveToFile(); break; case 79: LoadFile(); break; case 69: DoStuff(); break; default: Whatever(); break; } } Switches suit this type of situation very well. Not only do they give your program more structure but I think that they are more readable. And if readability is importatnt, constants would be a very nice finishing touch. using System.Windows.Forms; // ... const int KeyS = 83; const int KeyO = 79; const int KeyE = 69; // ... if(e.Control) { switch(e.KeyValue) { case KeyS: SaveToFile(); break; case KeyO: LoadFile(); break; case KeyE: DoStuff(); break; } }

Another possibility would be to do processing on another thread so that the GUI thread doesn't get tied up (search MSDN for info about the Thread class).

Take a look at the stack trace. The exception is not being thrown by the garbage collector, but it is being thrown by an object being garbage collected, specifically, an object which is finalizing. Finilization code is regular, plain old IL, just like any other .Net code, and subject to bugs and errors just like any other .Net code. Again, look at the stack trace. The exception is being thrown by System.Drawing.Dll, meaning that it isn't user code throwing the exception (can't set a breakpoint) and you can't step into the code during debugging unless you pull up the disassembly. And, again, this is during garbage collection (implicit call to System.Drawing.Image.Finalize) so there isn't even a way to step through to where the non-user code is called.

Maybe I'm just being old fasioned, but is a binary file out of the question?

Actually, I have something similar, but this code actually does something more than confirm it's existence. if(this.Exists()) { // Load settings if they exist. Load(); } else { // Default values _ProfRender = false; _DBPath = System.IO.Path.Combine( Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), DataFolder); } This is the code used to initialize a settings manager class I wrote. The exists method returns whether or not the serialized settings exist.

While translating some of my old VB to C#, I found this amusing line of code in a class I wrote a while ago. If [u][b][i]Not Me Is Nothing[/i][/b][/u] Then Save(Medium.GetKey) End If I couldn't help but share this stunningly witty piece of code. It brings Descartes' famous quote to mind, "I think, therefore I am." Perhaps this is why I don't program for a living. Anyone else?

Why not post the code where the event is declared (find the definition in the object browser or the code "generated from metadata") and the code where you attempt to attatch the handler.

I have a MenuStrip component on my form and I have noticed undesirable behavior as far as rendering goes. There is no issue when the RenderMode is set to professional, but only when the RenderMode is set to System (my preferred rendering). When a ToolStripMenuItem's submenu is displayed and then the mouse cursor is moved over a different ToolStrupMenuItem (not contained in the submenu) both the expanded MenuItem and the MenuItem under the cursor are highlighted, resulting in two highlighted menu items in each menu, which can look pretty ugly. [see the attached image] Is this some kind of bug or is this the expected behavior? The reason I ask is because it is inconsistent with both the old MainMenu component and the "Professional" rendered MenuStrip component.