Place curosr at end of combo box 1

[1DMF]

Hi,

I seem unable to place the cursor(caret) at the end of a combo box selection once a choice has been made?

I have in the changed event

        Me.Controls(sCont).SelStart = Len(Me.Controls(sCont).Text)

But it doesn't work and the entire contents of the dropdown selection remains selected?

I was using

sendkeys{"F2"}

which works fine apart from suffering from that age old bug and is messing with the user's numlock and capslock settings.

Any ideas?

Thanks,
1DMF

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Free Dance Music Downloads

 

[1DMF]

OK worked it out, didn't notice the after_update event which was causing the problem!

Still funny how after all this time MS still haven't fixed the sendkeys bug

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Free Dance Music Downloads

 

[strongm]

The problem is that the MSForms developers have once more tried to be clever. The Change event occurs before control returns to the textbox part of the Combobox, which remembers its previous Sel settings. Nothing you do with Selection settings in the Change event will have any effect on the cursor position.

The trick is to move the Sel stuff into an event that triggers once control has returned, e.g.:

[blue]Private JustChanged As Boolean

Private Sub ComboBox1_Change()
    JustChanged = True
End Sub

Private Sub ComboBox1_DropButtonClick()
    If JustChanged Then
        JustChanged = False
        MoveSelCursor ComboBox1
    End If
End Sub

Private Sub MoveSelCursor(myControl As MSForms.Control)
    myControl.SelStart = 65532
End Sub[/blue]

 

[1DMF]

Well I missed that the code was in the after_update event, I moved it to the change event and it works?

Private Sub Type_Change()
    Call upd_Tab("Type")
End Sub

Private Sub upd_Tab(sCont As String)

    Me.Refresh
    iRec = Me.CurrentRecord
    Forms!contacts![Fin_Pro subform1].[Form].Requery
    [Forms]![contacts]![Fin_Pro subform].SetFocus
    DoCmd.GoToRecord , , acGoTo, iRec
    Me.Controls(sCont).SetFocus
    Me.Controls(sCont).SelStart = Nz(Len(Me.Controls(sCont).Text), 0)
    
End Sub

The same code works fine for textboxes in the after_update event but it appears not comboboxes and must be the change event?



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Free Dance Music Downloads

 

[strongm]

Sorry, I'd assumed that you were using a UserForm rather than an Access form. The Access Form combobox does not suffer the problem you described for the Change Event, as you have discovered, whilst the UserForm combobox does

 

[1DMF]

nope , though it does for the after_update event!

Hey ho, all working fine now, it was rather a bizzarre one intially as I had to find out what was driving the users crazy having their caps lock / num lock messed with, even to the point that although the light was off the caps were still on, pressing it again turned the caps lock light on the keyboard on, but lowercase chars came out when you typed!

It seemes Access messes with it at an OS level screwing up the state of the caps lock / num lock and all because I was simulating the depression of the F2 key?

I guess sendkeys really is screwed and why there is so much on the net about avoiding it like the plague!

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Free Dance Music Downloads

 

[strongm]

>sendkeys really is screwed

It isn't so much that SendKeys is screwed, but that SendKeys is simply a wrapper around the keybd_event API (the generally better SendInput API not existing when VBA's SendKeys was coded), and synthesizes WM_KEYDOWN and WM_KEYUP messages which are sent to whatever window/control currently has the keyboard focus at the time the message is sent.

In a pre-emptive multitasking system we can't always guarantee which window/control may have the keyboard focus*, nor can we guarantee the current state of the keyboard - so it is possible that what is generally expected to be a WM_KEYDOWN/WM_KEYUP pair ends up being a WM_KEYDOWN to one window and a WM_KEYUP to another window with sometimes interesting consequences.



*For example, imagine a SendKeys that is supposed to pull down a menu and then select something from that menu. It may well be, due to timing issues, that the menu does not get keyboard focus before the next key (or keys) are sent.

 

[lionelhill]

... off-topic comment to strongm: this is why I still yearn for the days before multitasking happened.

Everyone knows what happens: you click on a button. Nothing happens. You click again. Then up pops a window (created by the first click or some random event that's nothing to do with you at all) saying "Delete everything and close universe". The nice new window has an "OK" button exactly where your mouse was when you clicked for the 2nd time, and the universe ends. I can't count the number of times this has happened to me.

 

[Andrzejek]

and the universe ends

You’re welcome to come and join me in my Universe. Mine is going strong, no end in sight

Have fun.

---- Andy