Posts filed under 'VB6 To VB.NET'

Enlarge Combobox Dropdown Area

An early version of the dropdown comboboxIn this second part of my series revisiting functions I wrote for VB6 I decided to see how one might implement a VB.NET routine to enlarge a combobox’s dropdown area to the size of the largest string that’s loaded into it. In VB6, as you can see in my original article, Enlarge Dropdown Area, it required a few API calls to pull it off. Has this gotten any easier to do in VB.NET?

The answer is, yes, it is much easier.

The combobox now has a property called DropDownWidth that you can use to set the width of the dropdown area. It couldn’t be much easier. Just put in the width you want in the properties box at design time and you’re set.

But, what if you don’t know how long the values will be at design time? You could estimate or you could use code to get the length of the strings you add and dynamically size the combo. Let’s look at one such routine.

Private Sub AddComboItemWithWidth(ByVal comboToLoad As ComboBox, ByVal itemText As String, ByVal maxStringWidth As Integer)
    Dim MyGraphics As System.Drawing.Graphics = Me.CreateGraphics
    Dim StringSize As Integer = CInt(MyGraphics.MeasureString(itemText, comboToLoad.Font, maxStringWidth).Width) + 1
    If comboToLoad.DropDownWidth < StringSize Then
        comboToLoad.DropDownWidth = StringSize
    End If
    comboToLoad.Items.Add(itemText)
End Sub

In this routine we pass in the combobox that we want to load, the value of the string, and the maximum length we want the combobox dropdown to be in pixels (it might be a good idea to base this user screen size or other such factors). First, we create a graphics object using the current form’s method. If you wanted to have this routine outside of the confines of a single form you could pass this object in as a parameter. Next, we use the MeasureString method to get the number of pixels required by the string. If the size is greater than the maximum size the max is returned. I add one to the returned number for a little extra padding but you don’t need to do this since the method will do some padding for you. Next, the returned size is compared against the current size and, if it is greater, the combo’s DropDownWidth property is increased. Lastly, the item is added to the combo.

If you wanted to resize the combo after loading, you could do the following:

Private Sub SizeCombo(ByVal comboToSize As ComboBox, ByVal maxStringWidth As Integer)
    Dim MyGraphics As System.Drawing.Graphics = Me.CreateGraphics
    Dim StringSize As Integer
    For Each ItemValue As String In comboToSize.Items
        StringSize = CInt(MyGraphics.MeasureString(ItemValue, comboToSize.Font, maxStringWidth).Width) + 1
        If comboToSize.DropDownWidth < StringSize Then
            comboToSize.DropDownWidth = StringSize
        End If
    Next
End Sub

This routine works in the same way except that it sizes after the combo is loaded.

So, it seems that doing this is a lot easier and simpler in .NET than it was in VB6.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

1 comment June 19th, 2007

Select Text Upon Entry

Selling you on VB.NETOn my VB6 Notebook Archive Site I have several code examples that were part of my standard library of routines that I used in many places. I thought it would be an interesting exercise to revisit these functions to see how they would be implemented in VB.NET. The first one we’ll take a look at is the Select Text Upon Entry routine. In VB6 we used the SelStart and SelLength properties of the textbox in the GotFocus event to select all the text when the user enters it. How would you do this in VB.NET?

First of all, let’s take a look at how you would do this in VB6:

Private Sub Text1_GotFocus()
    Text1.SelStart = 0
    Text1.SelLength = Len(Text1.Text)
End Sub

Now, let’s see what our VB.NET/Framework 2.0 level options are.

SelStart and SelLength are still there although they are completely spelled out as SelectionStart and SelectionLength. Otherwise they function the same as their VB6 counterparts. However, there are two new .NET methods that select text, Select and SelectAll. Select allows you to select a range indicated by a start value and length while SelectAll selects all of the text in the textbox at once. So, it looks like our natural choice should be SelectAll.

The GotFocus event is still there too but there is also the new Enter event. Which should we use? Well according to MSDN the event sequence when the user, or code, enters a control is Enter then GotFocus. Microsoft recommends that programmers use the Enter/Leave events instead of the legacy GotFocus/LostFocus events. Therefore, to update the routine we should put our code in the Enter event.

So, our updated routine would look like this:

Private Sub TextBox1_Enter(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.Enter
   TextBox1.SelectAll()
End Sub

Now we can test it and see what happens. We type in some text into TextBox1 and tab to another control and tab back to TextBox1 and our text is automatically selected. But, when we mouse into the textbox it isn’t selected. What gives?!? OK, let’s move the code back to our old reliable GotFocus event. The same thing happens!

As it turns out, this is caused by the way the event structure in .NET works. When the control is selected with the mouse, the TextBox’s Enter event is fired before the MouseDown event. The MouseDown event then sets the SelectionStart property to the location where the mouse was clicked. To fix this problem, you have to have code in both the Enter and MouseDown events.

Private Sub TextBox1_MouseDown(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles TextBox1.MouseDown
    TextBox1.SelectAll()
End Sub

This means we have to have the same code in two different events due to this new behavior in .NET. One option would be to subclass the textbox control and override the behavior in code there, thus moving the same code in two places from your main application to within the control code. This might be a good option to consider if this is a feature you need throughout your application.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

1 comment June 15th, 2007

A Look at When to Rewrite Your VB6 apps in VB.NET

Has your app become this toxic?A common question is, “When should I update a working, deployed, VB6 app to VB.NET?” The answer, in part, depends on how well the VB6 app is doing its job and if it is showing warning signs that indicate that it is nearing the end of its lifecycle. In this article, I’ll cover some of these warning signs.

First of all, don’t upgrade simply for the sake of upgrading. If the app is doing its job and working well there is no need to change it until outside factors require it. For example, one doctor I went to 2001 was using a custom DOS program written in Clipper that he had commissioned in the late 1980’s! It worked for his practice and he saw no need to change until regulation changes force him to do so. But, what if your application isn’t such a smooth operation?

Many VB6 programs, over time, get what I call the Winchester House effect. In case you didn’t know, the Winchester House was built by the widow of inventor of the Winchester rifle. To avoid hauntings a medium told her about, she kept the house under construction for 38 years and this resulted in a sprawling mansion that had many features that made no sense. Like this house, many VB6 programs have been added to and added to over the years until they become monsters with 100’s of forms and modules, some of which no longer make any sense.

When a program gets in this state you’ll begin to see “fatal improvements”. That’s what happens when a small change in one part of the program causes failures in other parts of the program. If a single line of code is changed and this causes indeterminable erratic behavior by the program, you’ve got a problem with that program. If you find yourself telling other programmers to avoid making changes in troublesome modules, this is a warning sign that your application’s quality is degrading.

Another sure sign of program quality degradation happens when new developers are brought onto your team or when you have to discuss the program with people outside your team. If you have to describe a myriad of special conditions and circumstances that a newcomer must be careful about, this is a sign of impending disaster. If you find that you can’t adequately and concisely describe what the program is supposed to do in certain modules to an outsider, that’s a problem. If you find that you can’t give a tester or a code reviewer the information they need to adequately do their job, this is yet another of impending failure.

Another sign of trouble is if you can’t rollback your releases easily. If the program has become so complex that returning to a previous release is just as troublesome as deploying a new release, that’s means it’s time for a change. Even worse, if no one really knows how to get back to the previous production release, this is a very serious problem.

So, if you see the quality of your VB6 application degrading in this way, it is prime time for undertaking a redesign using VB.NET. In later articles, I’ll cover some techniques for extracting a VB6 program’s design and ways to implement a gradual update if your program isn’t already on its last legs.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 29th, 2007

Next Posts


Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives