[RESOLVED] Trying to SetFocus on a ListView

[AccadaccA]

Hi, whenever using the SetFocus on an object I get the error:
"Run-time error '5'.
Invalid procedure call or argument."

The thing is the SetFocus sometimes works for so long then suddenly it becomes a problem.
MSDN is a waste of space!!!

My form and listview object are always visible and enabled. My listview list item is selected via another object on the form, which works well, however it's greyed out and not the usual blue highlight as it is when clicked on.

I have had the SetFocus problem in the past with other objects. The way I have gotten around this in the past was to write it as an "If/Then" procedure but that isn't working this time.
Any help would be appreciated. Thank you.

[Navion]

Yes... SetFocus can be prompt to generate errors. To be fair, no error is without a cause, but those causes make your program unreliable when you have not encountered them before and planned for them.

I don't let SetFocus jeopardize my programs anymore and always use a generic wrapper routine to call it.

Sub safeFocus(crtl As Control)
   
    On Error Resume Next
    ctrl.SetFocus

End Sub

safeFocus myListView 'can not trigger an error anymore

[DataMiser]

I don't recall ever having problems with set focus unless of course the object was not able to receive focus for some reason.

How about showing some code where this problem occurs.

[Krool]

Why not using the SetFocus API function. This works better somehow.

[SamOscarBrown]

Another suggestion (there's always ANOTHER one---but I guess all help in some way)...you can call this function eliminating two reasons a control can't accept focus:
May not be THE solution for you, but a good practice:

Public Sub SafeSetFocus(ByVal ctlFocus As Control)

If ctlFocus.Visible 
And ctlFocus.Enabled Then
   ctlFocus.SetFocus
End If

End Sub

[DataMiser]

Another possible reason a setfocus would fail with that error would be if another form is being shown as modal at the time which will prevent focus from being possible.
Form 1

Option Explicit

Private Sub Command1_Click()
Form2.Show vbModal
End Sub

form2

Option Explicit

Private Sub Command1_Click()
Form1.Text1.SetFocus

End Sub

Results in RTE 5 when clicking the button on form 2

If the form is shown normally or if a line is added to hide the form before the setfocus is issued then no error occurs.

More info and some code would be helpful to determine the issue here.

[Navion]

IMO, it does not matter much what the problem is (although it's nice to know). The SetFocus error is far too common to be dealt with on a per case basis, a global approach works better.

[DataMiser]

IMO, it does not matter much what the problem is (although it's nice to know). The SetFocus error is far too common to be dealt with on a per case basis, a global approach works better.

I've been coding in VB since the mid 90s and never had a problem with it that could not be traced back to a mistake in my code and that happens so rarely I can't remember the last time it happened.

[Navion]

I've been coding in VB since the mid 90s and never had a problem with it that could not be traced back to a mistake in my code and that happens so rarely I can't remember the last time it happened.

It's not as much a matter of mistake as it is a matter of overlook and extra work.

I have this engineering program that shows rotating mechanical parts in real time 3d. It uses half a dozen toolbars in separate forms, each with a dozen or more command buttons or entry fields. After each valid entry in those satellite forms, focus has to be shifted back to the main form, and more specifically to a particular control that will handle keyboard input, because chances are... 99.5 % of the times a toolbar button has been clicked, the next action will be a keystroke from the user and the main form has to respond. SetFocus is invoked. No problem so far but for the fact, once in a while, for some reason, the user will have minimized the main form. In that case program will crash. I know the cause and I know how to remedy. As a developer I have two options, use a global strategy that requires two lines of code and be done with the problem FOR LIFE. The other option of course it to put mode code in the program every step of the way, not sleep well at night asking myself if I overlooked some cases where a form was minimized, and prepare in advance a litany of excuses for the angry engineer who calls me at night to tell me my stupid %%&^&*#$#$% program quits on him for no good reason.

It's a question of design, about which VB6 could have been implemented to be more environment aware and avoid these kind of disagreements, much like when you use an api call as a sub, assuming it did succeed, but not creating havoc if it did not, or use it as a function and write more code if the function failed, based on return value.

[DataMiser]

Well imo using something like the OERN is not a good idea as it only prevents the program from crashing with an unhandled error. You still would not have focus on the desired field so there would still be additional work to do. Assuming that the field actually needs to get focus then you have to code it so that it does indeed get focus and does not just ignore the failure.

If it works for you that is fine, I personally would not use OERN for something like this and if I thought the user might minimize the form that I am trying to send focus to then I would check the windowstate before trying to set focus which would insure that the error not occur and the focus actually go where it is wanted.

That said using OERN will surely prevent the error but does not solve the problem of getting focus where it is wanted.

Edit: btw I did a quick test with a minimized form and did not receive any error when I used setfocus to a control on the minimized form. The setfocus of course did not set focus to the control but no error.

Option Explicit

Private Sub Command1_Click()
Form2.Show
Form1.WindowState = vbMinimized

End Sub

Option Explicit

Private Sub Command1_Click()
Form1.Text1.SetFocus
End Sub

If I add a line to test the windowstate then it works as expected

Option Explicit

Private Sub Command1_Click()
If Form1.WindowState = vbMinimized Then Form1.WindowState = vbNormal
Form1.Text1.SetFocus
End Sub

[Navion]

Nahh, I disagree. If for some reason, the user minimizes the screen, it is his own choice, focus does not matter, he will restore the main and focus at his own convenience. The technique is sound, the program safe and the user never inconvenienced. It's a win win situation.

I have been using the technique for a long time in many such programs, I have ONE global routine in addition to the one posted above. It's called setBackFocus where the program main control is hard referenced. I can use that line anywhere anytime. Even if I would change the form name, there would be no error.

See it any way you please, I call it peace of mind ;

[AccadaccA]

Thank you all for your input. Much appreciated.

I will mark this as "RESOLVED" merely because there has to be an answer or ten in there somewhere. lol Cheers

BTW, just for argument sake, the project is only one form at this stage so no others are interfering and it's not minimized.
I have simply added the following

Private Sub lblGameIndex_Change()
Dim X
        X = Val(lblGameIndex) + 1
        lvGames.ListItems.Item(X).Selected = True
        'lvGames.SetFocus
        'If lvGames.ListItems.Count >= 1 Then lvGames.SetFocus
        'If lvGames.Visible = True Then lvGames.SetFocus
        'If lvGames.Enabled = True Then lvGames.SetFocus
End Sub

As you can see I tried a few things to no avail and had to stop them '
It selects the listview item but not in the usual blue highlight.

Navion: Sorry I'm not up to speed. How do I call your suggested SafeFocus?
I copied the sub to my form and called it like this:.

Call SafeFocus(lvGames)

It doesn't permit the error but it still doesn't highlight the listview in the default blue.

[SamOscarBrown]

I don't see how Navion's solution would work....simply ignoring the exception (error) wouldn't, in my mind, allow you to setFocus to a control that can't accept it....thrown exception or not. It would just ignore the error, but still wouldn't set focus.

[Navion]

I don't see how Navion's solution would work....simply ignoring the exception (error) wouldn't, in my mind, allow you to setFocus to a control that can't accept it....thrown exception or not. It would just ignore the error, but still wouldn't set focus.

You are correct. My suggestion is not about setting the Focus, system is telling us it can't, but at least prevent the program from crashing.