bb.donnay-software.com

On some of our newer dialogs, when focus is returned to the xbase++ app, the keyboard is not active. the mouse must be used to give focus to a button,toolber, sle, mle, something that will respond to a keyboard event...

I was wondering if it's possible, when a dialog gets focus, if that focus is not an xbp that will respond to a keyboard event, can we switch to a default xbp that is on the dialog which will activate keyboard access... Even a xbp that isn't visible..

i thought of this while i was semi-dreaming, so it just might be the drugs...

has anyone used this approach ???

Roger, have you written a function like this already ??

something like:

gotfocus {||dc_make-sure-keypress-is-active(getlist,oDefaultxbp)}

I think this will do it for you.

I suggest using the setDisplayFocus callback of the XbpDialog() class to set focus to the first editcontrol object.

rdonnay wrote:I think this will do it for you.

I suggest using the setDisplayFocus callback of the XbpDialog() class to set focus to the first editcontrol object.

Code: Select all

DCREAD GUI ;
  EVAL {|o|o:setDisplayFocus := {||SetAppFocus(DC_GetListObject(GetList):editControls[1])}}

This should handle the initial issue, but we're having more issues when someone switches to a different app and then back to the xbase app.

the dialog shows active, but keypresses don't respond..

that's why i was coming from a gotfocus pov..

This should handle the initial issue, but we're having more issues when someone switches to a different app and then back to the xbase app.

So it sounds like your problem is with a child dialog window.
The main window is getting the setDisplayFocus event, but the child windows will receive no events.

If they receive no events, then there is no way to give a object on a child window focus.

Maybe the best way is to capture a killDisplayFocus event first and save away the SetAppFocus().

I need to make sure that this event get fired correctly when clicking on another window.

Put this in the DCREAD GUI of your main window:

DCREAD GUI ;
EVAL {|o|o:killDisplayFocus := {||(wtf SetAppFocus())}}

This should show the object that had focus when clicking out to another application.
Let me know the result.

no matter where i out it in my eval, wtf never returns anything to the debug screen.

no matter where i out it in my eval, wtf never returns anything to the debug screen.

Are you sure this is in your Main Window?

It should call the WTF when it loses focus to another application.

I tested it and it works for me.

ahhh.. i see said the blind man...

Using the new multi-threaded dialog,
the first time the app loses focus, i get an dc_xbppushbuttonxp returned
the next time, it's a dc_xbpdialog1, and that's when there is no keypress response.
i can duplicate that at will if i click on the title bar of the multi-dialog window.. it results the the dc_xbpdialog1 when the app loses focus.

Using the same dialog, but in a stand alone mode...
i only get dc_xbppushbuttonxp returns from the codeblock
and, keypress is always active.

When i open the old lot file dialog, i also can get both pushbutton and dialog return values,
but keypresses are always active, regardless of the return value

so, it seems to be exclusively a multi-threaded dialog issue...

to refresh your memory, the multi-threaded dialog combined multiple individual file maintenance dialogs as tabs into one integrated dialog.

to refresh your memory, the multi-threaded dialog combined multiple individual file maintenance dialogs as tabs into one integrated dialog.

I think you should call me on this so we can do a Teamviewer session.
We may not be communicating well.

ok.. i'll give you a buzz tomorrow..

I want to share with other eXpress++ users how we solved your issue.