jmcilhinney

I'm sure you looked at the help topic for the members of the DataRowView class, so I'll assume that you just missed the bit that matters. A DataRowView is very similar to a DataRow, and it has an Item property that behaves the same way. You would thus cast the selected item as a DataRowView and then get the field item you want:DirectCast(Me.ListBox1.SelectedItem, DataRowView).Item("test")or, since Item is the default property, simply DirectCast(Me.ListBox1.SelectedItem, DataRowView)("test")

Add a System.Windows.Forms.Timer to your form, in design view, called Timer1. Add a Label to your form called Label1. Set the Timer Interval to 1000 (milliseconds) and Enabled to True. Double-click the Timer to create a handler for the default event, which is Tick. In the event handler put this line of code:Me.Label1.Text = Date.Now.ToLongTimeString()The Date type also supports ToShortTimeString and ToString with format information.

Use a System.IO.StreamReader to read the file into an ArrayList. Then set that ArrayList as the DataSource for the ComboBox. Dim myStream As New IO.StreamReader("file path") Dim fileLines As New ArrayList While myStream.Peek <> -1 fileLines.Add(myStream.ReadLine()) End While myStream.Close() Me.ComboBox1.DataSource = fileLines

JDYoder, you are forgetting that a String is a reference type. It is endowed with some behaviour that resembles a value type but it IS a reference type. Personally, I wouldn't use any reference type object that I hadn't created myself without first checking whether it "Is Nothing", and you should do this with strings as well. Try this code and see if it does what you think it should: Dim str As String MessageBox.Show((str Is Nothing).ToString()) MessageBox.Show((str = Nothing).ToString()) str = "" MessageBox.Show((str Is Nothing).ToString()) MessageBox.Show((str = Nothing).ToString()) You hit the nail on the head when you said "function what returns what I expect it to". Just because you expect something doesn't mean it is right or what the rest of us expect. Read the help description of the Substring function you mention and you'll see that the second argument is "The number of characters in the substring". So that function does exactly what you would expect from that description. If it behaved the way you want it to then anyone who wanted the current behaviour would then have to go and write their own function. MS have decided that they like the current implementation so live with it. They could have done a million other things, and may well in time, but what we have now is what we have so if you want more then go ahead and write what you need. The most important thing I think is this: Strings are reference type objects so treat them as such. They behave like value type objects in some ways, which is a convenient bonus, but they are objects on the heap, not the stack.

If you put a function into the Watch window then that function has to be executed to return a result. This means that any operations within that function are executed, like changing variables' values, etc. How else could the functions return value be obtained?

Does that SQL Server add-on work with MSDE? If so, that might be your best bet. I don't know for sure but I doubt that functionality does exist for Access.

The lateral thinker can also do things like this:str2 = str1.Substring(0, Math.Min(str1.Length, 5))Don't assume that everyone wants things to work the way you do. If you want those functions then create them but many people want to write code that deals with possible errors rather than ignoring them and making assumptions.

JD, I have to say that the reason you think that it is correct to be able to get away with these bad practices is because VB6 has allowed you to and taught you that it is OK. As an example:Dim str1 As String = "ABC" Dim str2 As String = str1.Substring(0, 5)This is ambiguous. If it just returns the three-character substring, then what happens to the program that demands a five-character string? It should throw an exception in that case. Also, you should be initialising all your variables, be they String, Integer or otherwise. You should not just use an uninitialised Integer as zero (even though you can as it's a value type) because someone looking at your code is not to know whether you intended it to be zero or it was a mistake. That someone might be you coming back to old code years later. VB.NET attempts to force you to take into account all the possible results and make sure you have coded correctly for each one. The fact that VB6 allowed you to make lazy assumptions is one of the main reasons VB has been regarded as a "toy" language for so long. I think that VB.NET is a really good language that retains the good features of previous VB versions while replacing the features that, while being convenient, are considered to encourage "bad" practice by the rest of the development community.

I second that motion. Redimming an array is best avoided if at all possible. The ArrayList was created specifically to act as a dynamic array. It is more flexible than an Array object and can be converted by calling ToArray if a method requires an array argument.

I'm not going to go into the details of your post, but you should note that whenever you make a DataTable the DataSource of a DataGrid, the grid is actually bound to a DataView, specifically the DefaultView of the DataTable.

I would recommend using ADO.NET to retrieve your Excel data just like any other database. If you are using advanced Excel functions then automation is required, but for simple data retrieval ADO.NET is much quicker. Lookup "ADO.NET Excel" (without quotes) on MSDN for info and examples.

The closest thing you could do would be to use a HashTable or SortedList. Then you can create keys "simon1", "simon2", etc. and assign the corresponding values. You would then access the value corresponding to the key "simon1" using myHashTable("simon1").

Lookup the ControlStyles Enumeration in the help. Particularly the SupportsTransparentBackColor value. I've never actually used this myself, mind you.

A concurrency violation occurs when the original version of the data in the DataTables does not, or cannot be determined to, match the data in the database. It is assumed that someone else has updated the database since so you are working with stale data. There are ways to remove concurrency checking on updates but it is better to fix the issue than ignore it and use brute force. I have received these errors before but I can't remember the specifics or how I fixed them. I'd definitely recommend a help search for "concurrency" to at least help you understand what it means and how violations can occur.

This option works for XP and I think 2000 as well. Other Windows versions possibly not. There is a utility in the system32 folder called "shutdown.exe" that can be called using Process.Start. Check the Windows help for all the options, which are fairly extensive. For an option that is a litle more involved but will work on Windows back to 95, search MSDN for the ExitWindowsEx API.

The SQL standard (which should mean any SQL compliant database) uses "%" and "_" wildcards as equivalent to the Windows standard of "*" and "?".

Instead of all that messing around, why not just use a data adapter that has all commands assigned. Then a call to the Update method of data adapter will pick the correct command automatically AND set the RowState of your row. If you want to stick to your current method, a quick look at the members of the DataRow class would have revealed the AcceptChanges method.

Several things to note. The type of the Text property of a TextBox is ALWAYS going to be String. In your SQL you need to single quotes around the values of text fields and not number fields. You need to specify which ones are numbers and which ones are text yourself and treat them accordingly. If you are determined to use the name of the TextBox, perhaps add something to the name to identify what type that field is. You could also use a NumericUpDown, although this is not suitable in all cases. It certainly would be for integers though. If you want to find the TextBoxes, it would be neater to use If TypeOf ctl Is TextBox ThenIt would also be neater to use If ctl.Text.Trim() <> String.Empty Thenthan CompareTo if you don't intend to use the other possible results of CompareTo. CompareTo is really to establish relative ordering rather than possible equality. It's possibly pedantic but I suggest losing the VB6-style Mid() calls and use String.Substring() instead. I don't frown on any use of the Microsoft.VisualBasic namespace as some do but if the .NET Framework provides an alternative then I consider that preferable.

I could be wrong, but from the little you've said I would guess that you want a modal dialogue, i.e. a dialogue that prevents access to its opener until you dismiss it, like a MessageBox. If I am correct, you should display your form by calling ShowDialog instead of Show. ShowDialog does not return until the new window is closed, at which point it returns the value of the form's DialogResult property, which is supposed to indicate what button was used to dismiss the form, once again like a MessageBox.

I tested some code and found a bit of an anomoly. If you change the resolution of a monitor, the change is reflected in the WorkingArea of the screen. If you change the area of the taskbar, however, the change is not reflected. If you then restart the app and check again, the change is reflected. That seems like a potential bug to me. You may want to do some reading on the Screen class to make sure that this is not by design for some obscure reason.

PrimaryScreen is a Shared/static member of the Screen class. You could therefore call Screen.PrimaryScreen.WorkingArea to get the current working area of the primary screen. As marble_eater says, though, there are no events for you to handle so you would have to check on demand. You could set a timer to check intermittently, if necessary.

My apologies. Every reference I have previously read has been related to collections. I guess I should do some reading myself before posting "definitive" definitions :o