jmcilhinney

Generally speaking, the only expense associated with these "legacy" functions is actually making the one extra function call, which will create no perceptible difference in performance in the vast majority of cases. I do agree that there is no point making the extra function call if it serves no useful purpose, e.g. MsgBox and MessageBox.Show, but there are also cases where the Runtime function call provides additional functionality. All the VB Runtime functions are implemented using VB.NET, so there is no reason you couldn't provide this functionality yourself, but why reinvent the wheel. As always, use the best solution for the problem, which may well be a VB Runtime function in some cases.

Had you read the article, you would know that Microsoft.VisualBasic does not get "included in your assembly". It is part of the .NET Framework, so it is there regardless, and using it is no more or less expensive than using any other .NET Framework library. One of the most common reasons I've seen quoted for not using methods from the VB Runtime is they are not available to C#, et al. Think again! Microsoft.VisualBasic.dll is a .NET assembly like any other, so you can reference it in a C# project and use the methods it provides. If you don't believe me then try it for yourself. I'm not necessarily saying that C# developers should start doing this. What I am saying is that, while it may seem strange to reference the VB Runtime in C#, it is no more or less legitimate than referencing any other library written in VB.NET. One of the main aims and advantages of .NET is interoperability between assemblies written in different languages. It's more often done the other way around, i.e. referencing an assembly that was written in C# in a VB.NET project, but by the time your code is compiled to IL, noone cares what language it was written in anyway.

The reason that you can't use a TimeSpan to get anything greater than a number of days is because the TimeSpan knows nothing about when it started or when it finished. It only knows how long it is. Given that different months have different numbers of days and some years are leap years, the same period of time could give you different numbers depending on the start time and end time. If you wanted to implement your own DateDiff function, you would do it using the System.Globalization.Calendar class. My guess is that this is exactly how the Microsoft.VisualBasic.DateAndTime.DateDiff function is implemented.

Read up on the Locked property. It is design-time only and prevents a control being moved or resized by drag-and-drop in the designer. Private checkAllowed As Boolean = False Private Sub CheckedListBox1_ItemCheck(ByVal sender As Object, ByVal e As System.Windows.Forms.ItemCheckEventArgs) Handles CheckedListBox1.ItemCheck If Not Me.checkAllowed Then e.NewValue = e.CurrentValue End If End SubWhenever you want to check or uncheck an item programmatically, you have to set the checkAllowed variable to True first, and then back to False afterwards.

Read the file in using a StreamReader. You can read the whole file in one go using ReadToEnd, or line by line using ReadLine. Once you have a String variable or array, you can simply replace the appropriate line using whatever type of string manipulation seems most appropriate. Finally, write the file back out again using a StreamWriter.

I have read a good portion of that article you mentioned, JDYoder, and it does make for interesting reading. I do stand by my previous post, but I may be less vehement in my condemnation of methods from Microsoft.VisualBasic in the future. I apologise if any of my previous comments have appeared harsh. In fact, I apologise even if they didn't appear so, because I guess they were intended to be at least a little bit harsh. :o

For Joe Mamma This is taken from this article on MSDN, which I personally found quite informative and eye-opening. It dispelled some assumptions that I'd made about VB.NET. While many of the things you say about classes over modules is correct, the use of modules should not, in any way, be considered improper, assuming the situation is suitable.

I agree with Iceplug and would also like to add that, no matter what Microsoft may say, there is no guarantee that support for these VB6-style functions will continue into the future. I don't think many people would disagree that Microsoft would like VB6 to disappear altogether. They realise that this is not going to happen immediately, though, so they have provided the support for now. I've no doubt that additonal functionality will appear in the System namespaces in future and, at some point, much of the functionality in Microsoft.VisualBasic will be phased out. Microsoft want the world to use C# and there's nothing like those old VB6 functions in C#, so I believe that Microsoft don't really want people to use them in the long run.

If you require user input as a date, time or both then you should be using a DateTimePicker rather than a TextBox. You can format the Text of your DTP however you want, but the Value property is always a Date object. As a point of interest for those who aren't aware, the Date and DateTime types are exactly the same thing. The in-built Date data type is implemented using the System.DateTime structure. All in-built data types (String, Integer, Boolean, etc.) are implemented using a class or structure from the System namespace. As for VB6 Collections, I've never used one myself. From what little you've said, though, I'd say that the HashTable is the closest thing as it has key/value pairs. The SortedList is the same, except the collection is always sorted by key. You should check out all the collections available in .NET, however, and use the the most appropriate one for each occassion.

As PlausiblyDamp said, look at the System.Collections namespace. It contains a variety of collections including ArrayList, Stack, Queue, HashTable, SortedList and base classes to be used to create your own custom collections. .NET 2.0 introduces Generics as well, which, amongst other things, provide for strongly typed collections without creating a custom collection for each type. Arrays still exist in .NET but have been improved upon, in that all arrays are now instances of the Array class. As such, arrays have properties and methods of their own, so they don't have to rely on module functions for copying and the like.

Never used it myself. The word is a link in my post, which you can follow to download several remoting samples.

You misunderstand the MultiColumn property of the ListBox class. It works similarly to WordWrap in a TextBox. There is still only one list of items in the ListBox. When the items fill the space vertically, the next item is displayed in the next column. It is done automatically and you have no control over it. If you alter the size of the ListBox then the list items will reflow so that a vertical scrollbar is not required. That is the sole purpose of MultiColumn, which you would know if you had read the appropriate help topic. Try adding several items to a MultiColumn ListBox in the designer and resize it and see what happens. If you want a genuinely multicolumn list, you need to use a DataGrid or a ListView. I believe I once saw a user-posted control that was derived from the ListBox at the Code Project. You might like to take a look there.

It depends what you mean by "easy"? You can use the SendMessage API function or you can use remoting.

I suggest you go to http://www.skybound.ca and download VisualStyles, which is a free component that overcomes pretty much all of the limitations of Visual Studio when it come to visual styles. There is no need for manifests, no need to change the FlatStyle or anything. It all just works with virtually no effort. Add the component to each form and your done.

Did you try another # symbol. Often doubling up a special character serves to escape it.

Sorry, VB6 was an evolution of a language that was designed for 16-bit operating systems. That's why the standard number type, i.e. Integer, is a 16-bit number.

I'm not 100% sure whether this is your issue, but there is no need to create a new DataView. Simply bind your ComboBox to the DataTable itself. When you do this, the ComboBox is actually bound to the DataTable's DefaultView property, which is a DataView. You then apply any filtering or sorting to Startup.DB.t_TVA.DataTable.DefaultView and you should find that all is well with the world.

Which line actually throws the exception? You should step through your code until you get to the actual line that throws the exception and then mouse-over or use the Watch window to test everything on that line to determine what is the null reference. Also, VB6 was designed for 16-bit operating systems. If a variable was declared as Long in VB6 then it should be Integer in VB.NET. Likewise, a VB6 Integer is a VB.NET Short.

If we were using C# then I would agree with you, but given that we are using VB.NET, why complicate matters when a module provides essentially the same functionality without the complexity? Edit: You may be thinking "what complexity", but believe me, many people don't fully understand what static/shared means, and private constructors will defintiely confuse some people.

That is exactly how I tested. Notice that once you have the window to the edge of the screen, the only way to have it stay there is to press the ENTER key. Once you've done that, you can still access the window from sliver of border that it leaves at the edge. If the window was allowed to move off-screen and had ShowInTaskbar set to False then it would be inaccessible. I'd guess that if they were to implement MDI without scrollbars, it would be done the same way for the same reason.

Quite correctly, Machaira has pointed out that using Dim to declare a class- or module-level variable has the effect of making it private. Good programming practice dictates that you ONLY use Dim to declare LOCAL variables, i.e. within a procedure or function. You should always use Public, Private, Friend, etc. when declaring class- or module-level variables.

So it is. My apologies.

I was under the impression that the user could select Move from the system menu and move the window off screen as well, but I just tried it and it seems that you cannot move it off screen that way. It is true that if you programatically move it to a location off screen, which is unlikely but possible, the user would then have no way to access the window.

When you make a form an MDI container, it actually places an MdiClient control on your form. This means that setting the form's BackColor has no effect because it is hidden behind the MdiClient. There is no member variable for the MdiClient, however, as it is not intended to be used directly. You can change its properties, though, using code like the following: Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load For Each ctl As Control In Me.Controls If TypeOf ctl Is MdiClient Then ctl.BackColor = SystemColors.Control Exit For End If Next End SubAs for scrollbars, I'd say that you're stuck with them. How else would you get a window back that was moved out of view?