How do I programatically assign focus to a control

[hug]

When a Panel has focus, and the user depresses the TAB key, the next control in the tab order list is highlighted.

I want to do this via program control.

How can I?

What is the correct ATTRIBUTE ?

I tried Getting and Setting ATTR_CTRL_TAB_POSITION, but that does not do what I want.

The control already has its tab position assigned to it. I dont want to change it.

What I am looking for would be saomething like SET_TAB_POSITION, NEXT.

Has anyone done this, can anyone  help?

Thanks.

[mvr]

Will SetActiveCtrl() do what you  are looking for?

[vahid]

I'm having a similar problem where SetActiveCtrl() doesnt seem to work right. I have a serial number box the user fills. This box has EVENT_COMMIT code that validates the serial number. If its valid it moves to the next entry box, if not it is supposed to highlight the serial number box again so they can type over it. The problem is that it works fine if the user pushes the enter or return key, but pushing TAB causes it to go to the next box regardless. The event commit still happens and gives an invalid serial number alert, but the focus goes to the next box instead of the current one. I step through the code and I can see the box becomming active after that line but it still jumps to the next box after hitting GO. I know it sounds like a problem with my code, but I made up a sample project illustrating the problem (attached). Try typing just a few chars in the serial number box 1 and push enter. It displays the error and highlights the correct box. Try the same thing using the tab key. It now highlights the wrong box. Im using CVI 8.0.1.

[RobertoBozzolo]

vahid, the problem you are seeing depends on the KEYPRESS event for the tab key still pending after you issue the MessagePopup and try to restore the active control: what is happening is that after you process the commit event, the keypress event is completed and the next control gains the focus. The simplest way to modify this behavior is to insert a deferred callback after the MessagePopup that restore the active control after the tab key event has been processed: I am attaching a modified version of your project that uses this deferred callback to maintain the active focus on the original control. I designed the deferred callback in a general way so that can be used in callbacks for more controls.

[vahid]

I had actually considered that the TAB action was happening after my code. I tried to eliminate this by calling ProcessSystemEvents(), but I see that doesn't work. It would be nice if there was a function ProcessKeypressEvents() so I could flush them. Your deferred call solution certainly gets the job done. Thank you. 

[OVR_CZ]

Hi,
    Check the "Swallowing Events" method.

    (From CVI help) 

     User callbacks must always return 0 unless they intend to swallow the event to which they are responding.
     To swallow the event, the callback should return 1.

     Only user input (mouse click and keypress events) and commit events can be swallowed.
     If swallowed, no more callbacks are called for that event. If a user input event is swallowed,
     the user’s mouse click or keypress is ignored. If a commit event is swallowed, it is not placed into the GetuserEvent queue

    ovrabek/CZ
   

[RobertoBozzolo]

Unfortunately things are not so easy as the documentation makes them feel...

Your solution does not prevent the TAB key from switch to the next control, the reason being the order events are sent to the control callback. If you select the Operate tool in the UIR editor (the button with the small hand pressing buttons) and operate on the control, in the upper right corner of the editor you can see listed the events that are fired by your actions: you may notice that EVENT_KEYPRESS while pressing the TAB key is fired before EVENT_COMMIT. But in the callback you are handling the commit event and try to swallow it: this does not swallow the tab key event because this has already been fired, so the focus switches to the next control.

A different approach could be to avoid handling the commit event and operate only on KEYPRESS events but you need to intercept exactly all keys that switch focus to another control (tab, ctrl+tab and all shortcut keys that are assigned to other controls quite a long list may be!).

But it is true that also my solution has some problem: when the user clicks on another control, the warning popup fires and then the UIR is somewhat freezed (the caret is in the new control while the focus is still on the old one, no response to keyboard actions... only a new click anywhere on the panel unblocks the program!)

[OVR_CZ]

Hi Roberto,
 I apologize for my unclean post.
 The only idea whats i mean is use "Events Swallowing" instead of deferred callback.

 sorry for my poor english

[RobertoBozzolo]

ovrabek, there's no need to apologize: there was nothing wrong with your posts! I am sorry if I let you feel uncomfortable or so.

Swallowing events is a powerful technique and was the first I myself attempted to solve vahid problem... unfortunately in this case the sum of events queued to the callback vanified its power.