quwiltw

Use "As", the same as you did for "func". Also, since you're having this problem, you might want to turn Option Strict On, which would have caught this. Dim cmdIns As New OleDb.OleDbCommand(sql, conn) Dim parm1 As New OleDb.OleDbParameter("@UserID", OleDbType.Integer) hog, hopefully you mistyped and meant something more like this: Dim cmdIns = OleDb.OleDbCommand cmdIns = New OleDb.OleDbCommand(sql, conn) The way you've got it right now actually creates two instances, one on the first line, which immediately gets thrown away with the second line. Not good.

I'm seeing some unexpected behavior and hoping someone can explain it. I'm creating 10,000 instances each of an OleDbConnection, OleDbDataAdapter, and OleDbCommand using Dim cn As New OleDbConnection(cnStr) etc. and it takes ~820 milliseconds Then I'm creating 10,000 instances of each of those using obj = Activator.CreateInstance(GetCurrentHash.Item(interfaceName)) where GetCurrentHash... returns a cached "Type" to create. This is only taking ~680 milliseconds. I was expecting the opposite and CreateInstance to be slower, mainly because of the initial Type lookup and I'm also accepting a hashtable of properties/values to be dynamically assigned after the creation too. Can anyone explain the slower performance of "New"? It's not a big deal because I'm getting even better than what I was hoping for but I find it curious anyway.

It doesn't, which is likely why 1 in every 15 or so posts have an error message "object reference not set to an instance":) Strange they made C# so smart and not VB.

that'd likely be his next run-time error:), he probably wouldn't have trouble compiling though.

abosutely? Why? If I have a derived class it'll always have the base classes methods available, so why should I have to cast it? It should work just like an Interface in my opinion, just like C++ and Java. Is this your personal preference or have you a situation that would break that I've just not experienced yet?

We just had this discussion in my office and I think Option Strict is annoying for one reason: you can't treat a derived class the same as a base class without casting. In my opinion, you should be able to manipulate derived classes using a reference to the base class in much the same way you would an interface.

Freaky... never knew that title was a link. thanks

What's that?

Reverse lines 8 and 9. The Ada.SelectCommand doesn't exist because you don't set it til the next line.

IConvertible isn't ringing any bells immediately, could you post the relevant chunk of code?

T2 is just an alias, that statement is only based on one *real* table.

Maybe not the most efficient way, but it should get you going for now... SELECT Distinct(T1.UserID), (SELECT Min(T2.Rights) From Table1 T2 WHERE T2.UserID = T1.UserID) As Rights From Table1 T1

Are you having problems with binding to the listbox initially or the subsequent call to use the selected item as a parameter to the next query?

Since rotations occur at the lowest level necessary so should the skew resetting. No traversal of the entire tree should be necessary. It should be logically based off of what the node's skew was before the insertion, what subtree grew, and the direction of the rotation. (ie. LeftHigh, left subtree grew, right rotation=> balanced or Balanced, right subtree grew, no rotation, Right-High)

Yeah, I don't understand your numeric skews. For any given node, I think you only need to know whether that node is right-high, left-high, or balanced. I also think I'd combine the skew-setting with the rotation code. If I remember correctly, I used pretty much the same insertion code for an AVL tree as a BST and just handled the null root differently (setting a balanced skew) as well as adding a call to a to RightTreeGrew or LeftTreeGrew as appropriate to handle the skew setting and rotation. I essentially split the insertion from the subsequent rotation/skew-setting.

It's been a while, but I don't recall you having to. Since each node maintains it's current skew state (right-high, left-high, or none), as you go back up the insertion stack, you'll fix the skews as you go. If the right subtree has grown and it was left high, now it's none, if it was none, now it's right-high, etc. If you post what code you have so far, I'll take a look at it.

I'm just reading about WMI in a book I got. Here's a chunk of code I wrote just playing around with the info in the book. It's essentially non-API method. The only frustrating thing is that I don't know what all you can get information about. The only reason I knew the format of "win32_logicaldisk.deviceid" was that I saw it in the book. There's no telling what other things you can grab as I've not found a list of them anywhere. Public Sub ShowDriveInfo() Dim eDrive As New Management.ManagementObject("win32_logicaldisk.deviceid=""c:""") Dim sbProperties As New StringBuilder() eDrive.Get() Dim en As IEnumerator en = eDrive.Properties.GetEnumerator() While en.MoveNext sbProperties.Append(en.Current.Name) sbProperties.Append(" = ") sbProperties.Append(en.Current.Value) sbProperties.Append(vbCrLf) End While MessageBox.Show(sbProperties.ToString()) End Sub

Maybe I'm missing something, but wouldn't turning on Trusted Connections do the trick? Then you'd never have to worry about user/password management.

There's a real good sample of this included in the samples directory. On my system it's here: C:\Program Files\Microsoft Visual Studio .NET\Vb7\VB Samples\WinForms-SysTraySample\SysTraySample

I think he means from the "perspective of employers" rather than the linked topic which was from the other side.

I'd say if someone gets this "downside" it's a result of poor coding technique rather than AndAlso/OrElse. I think it's generally a bad idea to have functions that change stuff in your expressions.

AndAlso was introduced to provide VB developers with Short Circuit evalutation. "And" wasn't used becuase it'd confuse VB6 developers who expect both expressions to be evaluated. The documentation provides a nifty little table for both keywords to show you what is evaluated when and what the whole expression will evaluate to.

you make it sound so painful:p

At first glance it looks like there is a cell of data in the excel spreadsheet that doesn't meet the data type of the column you're trying to put it in. Just to test this hypothesis, you might create a simpler spreadsheet with only 2 or 3 rows and confirm that all the data in those 2 or 3 rows meets the constraints of the database columns. Then import this. If it works, you know I'm right and you need to fix the source.

That's backwards. The AndAlso operator is the new support for short circuit comparisons. And will evaluate both, AndAlso won't. Heiko's original response is likely accurate, but I must say I think AndAlso is much more elegant than nesting.