[RESOLVED] With Statement (Noob question !!!)

[DubweiserTM]

Hi everybody !

Sorry if I take your time for this kind of question...

I want to know if it's good to use With / End With only for two lines ???

Something like that:

With txtUser
        .Text = vbNullString
        .Enabled = False
End With

Thanks in advance !

[killo]

if you are only using it for two lines, i think you will be typing more text to use the with statement than you will have saved
i think using it for 3 lines will be about the same if you did or didnt use the with statement and you will only start saving typing time if you use it for 4 lines or more.
so no its not good, below about 3 lines you are only making yourself type more, you only start saving when you use about 4 lines or more.

[Mr.Mac]

Personally, I have never used "With/End With" and never will.

I think it is easier to follow code when it is spelled out.

With txtUser
        .Text = vbNullString
        .Enabled = False
End With

in my opinion obscures the crystal clear

txtUser.Text = vbNullString
txtUser.Enabled = False

I wouldn't let the number of characters I have to type influence this decision. Who cares. A quick paste of "txtuser." (one ctrl-V) followed by the variable name.

Mac

[MarkT]

With End With is more efficient.

If you have

 
        txtUser.Text = vbNullString
        txtUser.Enabled = False

VB is grabbing a reference to the textbox object, setting the text property and then releasing the reference to the textbox. Then VB gets a reference to the textbox again and sets the enabled property of the textbox.


On the other hand, if you use

With txtUser
        .Text = vbNullString
        .Enabled = False
End With

VB grabs a reference to the textbox, sets both properties and then releases the reference.

[Al42]

It's also easier to read once you gain a little more experience.

[Ellis Dee]

The With...End With construct is the greatest thing since sliced bread. It speeds up your code and increases readability; what's not to love?

In addition to the execution speed that MarkT explained, it also makes typing the code easier because the intellisense dropdowns kick in.

Fair warning: Never break out of a With...End With block using a Goto or Exit statement, because VB does not release the object reference. Thus, the following code will generate the "array is locked" runtime error:

Type MyType
    Text As String
End Type
 
Sub Main()
    Dim MyArray() As MyType
    Dim i As Long
 
    ReDim MyArray(10)
    For i = LBound(MyArray) To UBound(MyArray)
        With MyArray(i)
            If Len(.Text) = 0 Then Exit For
            .Text = LCase(.Text)
        End With
    Next
    ReDim MyArray(5) ' <== Generates runtime error
    Erase MyArray ' <== So does this
End Sub

[zynder]

With two lines of same object i never mind typing it. If more than that, i use with. Readability is not much of an issue as long as it's properly indented.

[Ellis Dee]

Instead of lines of code, consider number of references. For example:

With Text1
    .SelStart = 0
    .SelLength = Len(.Text)
End With

The nice side effect is that the code becomes much more portable. If I rename the textbox, or copy the code to use for a different textbox, I only have to change the name in the code once.

[MartinLiss]

Efficiency and readability yes, but the effor involved in the one-time task of typing the code should never be the criterion used to determine what you do.

[Mr.Mac]

With End With is more efficient.

Matter of opinion, I guess, but I feel that the "efficiency" gained is so neglibible that it is not worth any consideration at all.

This button got a difference ranging around 0.03 on a 500mhz machine.

Private Sub Command1_Click()
Text1.Enabled = False
Text1.Text = ""
Text1.Visible = True
Dim i As Integer
Dim t As Single, tDif1 As Single, tDif2 As Single
Const z = 10000 ' loop size
t = Timer
For i = 1 To z
  Text1.Enabled = False
  Text1.Text = ""
  Text1.Visible = True
Next i
tDif1 = Timer - t
t = Timer
For i = 1 To z
  With Text1
    .Enabled = False
    .Text = ""
    .Visible = True
  End With
Next i
tDif2 = Timer - t
Text1.Text = Str$(tDif1 - tDif2)
End Sub

Mac

[MartinLiss]

A timer is not an accurate way of timing code. A more accurate way is described in the Time code using GetTickCount link in my signature. In any case the way you have set up your test isn't really fair since if it were real code the 2nd loop would be set up as

With Text1
    For i = 1 To z
        .Enabled = False
        .Text = ""
        .Visible = True
    Next i
End With

and not

For i = 1 To z
  With Text1
    .Enabled = False
    .Text = ""
    .Visible = True
  End With
Next i

However, given the .Enabled etc tasks you set up the difference in speed is negligible.

[Mr.Mac]

isn't really fair

Well, I disagree with your logic. As we are timing the difference between constructions, my second test is, in fact, fair.

But many thanks for your timing API info. I ran the code below and got around 20 milliseconds. Namely the same as timer. But I can see that for very accurate needs, the GetTickCount is nicer.

As you probably agree, the big picture is that no real difference on a 500mhz machine even with 10,000 times. The average program has far fewer instances that could be coded either way. Hence, as I said, efficiency is not a factor. Coding style and clarity can be argued subjectively but there is no objective difference.

Mac

Option Explicit
Private Declare Function GetTickCount Lib "kernel32" () As Long
Private Sub Command1_Click()
Text1.Enabled = False
Text1.Text = "Start Test"
Text1.Visible = True
Dim i As Integer
Dim t As Long, tDif1 As Single, tDif2 As Single
Const z = 10000 ' loop size
DoEvents
t = GetTickCount
For i = 1 To z
  Text1.Enabled = False
  Text1.Text = ""
  Text1.Visible = True
Next i
tDif1 = GetTickCount - t
t = GetTickCount
For i = 1 To z
  With Text1
    .Enabled = False
    .Text = ""
    .Visible = True
  End With
Next i
tDif2 = GetTickCount - t
Text1.Text = Str$(tDif1 - tDif2)
End Sub

[si_the_geek]

Actually it would only be fair comparison if you were using a control array, and accessing different items depending on the loop counter.

Even tho your loop size is far too small to see any accuracy (so is not valid for comparison!), as you said the speed in that situation is not a factor.

The efficiency of With can certainly be a factor tho, depending on the situation. Assuming you have code like this:

For x = 1 to 1000
  objExcelApplication.Workbooks("Book1").Sheets("Sheet1").Range("A" & x).Font.Bold = True
  objExcelApplication.Workbooks("Book1").Sheets("Sheet1").Range("A" & x).Font.Underline = True
  objExcelApplication.Workbooks("Book1").Sheets("Sheet1").Range("A" & x).Font.Italic = True
Next X

..it will become noticeably faster (and in most peoples opinion, easier to read) if you change it to this:

For x = 1 to 1000
  With objExcelApplication.Workbooks("Book1").Sheets("Sheet1").Range("A" & x).Font
    .Bold = True
    .Underline = True
    .Italic = True
  End With
Next X

..and faster still if it is converted to this:

With objExcelApplication.Workbooks("Book1").Sheets("Sheet1")
  For x = 1 to 1000
    With .Range("A" & x).Font
      .Bold = True
      .Underline = True
      .Italic = True
    End With
  Next X
End With

The reason for this is that each dot is a reference to a sub-object, and it takes time to find the sub-objects (such as .Font). This is even more true in the case of items like Workbooks("Book1"), as a collection needs to be searched each time.

If this example was simplified to use an object variable for the WorkBook (thus eliminating one child object, and one collection search) the difference would still be noticeable.

[Mr.Mac]

LOL - No doubt.

If you go back to the top of this thread and follow a bit, you will see we are talking about "ordinary" simple use.

I'm sure in the case you showed there is great improvement. As there is no way I would ever be doing anything like that, I will forget what you said and someday be coming back here whining "How can I make my application run faster?". At that time, you can have the satisfaction of pointing me to this thread. ROFL.

So far, my most complicated application runs immediately and I have never experienced other than instant performance on any button click.

Well, see you in a few years!

Mac

[Al42]

If you go back to the top of this thread and follow a bit, you will see we are talking about "ordinary" simple use.

Since there's no penalty with even 2 lines, it's a good habit to get into. It also makes it easier if you add more items later (say a grid, and later you want to add formatting for some columns while you're loading it).

[Ellis Dee]

A timer is not an accurate way of timing code. A more accurate way is described in the Time code using GetTickCount link in my signature.

This is apparently not true. To get precision finer than 15.625 milliseconds, use QueryPerformance API.

[MartinLiss]

This is apparently not true. To get precision finer than 15.625 milliseconds, use QueryPerformance API.

GetTickCount is more accurate than a timer which is only accurate to +/50 ms on older operating systems. You are right though in pointing out that it is not the most accurate way. I didn't say that it was and I was aware of the others but chose not to mention them since for most things GetTickCount is sufficient.