Unklares Verhalten von SetAppFocus

[DelUser01]

Hallo!

Zusammengefasst: SetAppFocus( oFirstPushButton ) setzt Focus auf den PushButton oder auch nicht.
Grob sieht das so aus:

Code: Alles auswählen

oDlg:=XbpDialog():New()...:Create()
oPB:=XbpPushButton():New...:Create()
SetAppFocus( oFirstPushButton )    ( : Default und : preSelect sind auch gesetzt)
AppEvent(...)
oXbo:HandleEvent(...)

Nun sollte im AppEvent das Programm stehen bleiben mit dem Focus auf den ersten Button.
Das funktioniert aber meist nicht oder nicht immer.
ABER so geht es immer:

Code: Alles auswählen

Sleep( 15 )
SetAppFocus( oFirstPushButton )

Wenn ich also vor das SetAppFocus() ein Sleep() setze geht das mit dem Focus!!!
Bei Wert kleiner 15 fängt es schon wieder an instabil zu werden, ab 20 merkt der User schon die "Bremse".

??? Hat das schon Mal jemand selbst gehabt bzw. jemand eine Idee woran das liegen kann??

Zusatzinfos:
Vor dem XbpDialog wird jedes Mal ein GET-Objekt verlassen (Hybrid-Modus). Nur dort passiert es.
Wenn der ganze Ablauf nach einem SLE kommt ist der Fehler noch nie aufgetreten.

Ich habe schon einiges versucht herauszubekommen woran das liegt...keine Ahnung wo ich noch suchen soll.

MfG
Roland

[brandelh]

READ und GUI (wie sieht die Eventloop aus ?) das kann sich schon stören - die Emulation von GET in XbpCRT() ist deutlich langsamer als ein normales Control.

Ich setze bei mir die SetAppFocus() erst nach dem :show() des Fensters und dabei auch immer 2 Befehle hintereinander (es kann sein, dass das heute nicht mehr nötig ist).
Zumindest früher fehlte sonst bei dem Fenster mit Eingabefocus der Blaue Balken oben.

Code: Alles auswählen

in oWin:create() ... oder danach
oWin:show()
SetAppFocus(oWin) // zunächst auf das Fenster
SetAppFocus(oWin:MeinControl) // dann auf  das Control.

Stimmt die Parent() / Owner() Einstellung - oder sind die Teile gleichberechtigt nebeneinander ?

[DelUser01]

Hallo Hubert

ich versuche Mal Deine Frage zu beantworten:
beim XbpDialog( oParent , oOwner , ...
oParent = AppDesktop()
oOwner = SetAppWindow()

Bei Read verwende ich das modifizierte getsysx.
Die EventLoop ist im Verhältnis zum Read sehr kurz.

Ich vermute auch, dass es mit der "Langsamkeit" des GET-Objekts zu tun hat bzw.mit irgendwelchen langsamen (nachlaufenden) Events aus dem GET.

Auf das "seltsamen Verhalten" kann ich noch eins draufsetzen:
Es gibt in meinem Programm zwei Varianten die in das problematische Modul führen. Beide in Folge einer Eingabe im GET-Object.
Wird das GET-Objekt mit der Variante 1 verlassen ( oGet:exitState := GE_ENTER ) wird der Focus immer richtig gesetzt - also keine Probleme.
Wird das GET-Objekt mit der Variante 2 verlassen ( PostAppEvent( xbeK_RETURN ) kommt der beschriebene problematische Focus-Effekt zustande.
Das soll einer begreifen...

Gruß
Roland

[brandelh]

Code: Alles auswählen

 PostAppEvent( xbeK_RETURN )

simmuliert einen Druck auf RETURN, die Ausführung ist asyncron, wenn du nun einen SetAppFocus() machst, könnte es sein, dass der Event gar nicht mehr an das GET Objekt gesandt wird sondern schon an dein dann auf den nun aktiven. Man sollte immer den gewünschten ZIEL-Parameter mit angeben, dann wäre das sicherer.

[DelUser01]

Hallo Hubert,

mit dem Angeben des Ziel-Objekts hast Du natürlich recht.
Aber das xbeK_RETURN kommt ja richtig an, damit wird ja wie gewünscht das GET verlassen.
Dann clear gets, noch einige andere Operationen und dann kommt der XbpDialog.

Was mir noch aufgefallen ist:
Manchmal wenn der Focus nicht richtig gesetzt wird kommt vor dem AppEvent Wartestatus noch ein xbeP_Draw genau für das XbpPushButton-Objekt das den Fokus haben sollte.

MfG
Roland

[AUGE_OHR]

Bei Read verwende ich das modifizierte getsysx.
Die EventLoop ist im Verhältnis zum Read sehr kurz.

du kannst als 4th Parameter von AppEvent bis 0.02 runtergehen ... aber ohne "Code" in der Event-Loop !
AppEvent bekommt ja ständig irgendwelche Events und "reicht die nicht weiter" wenn du nicht zum oXbp:handleEvent( nEvent, mp1, mp2 ) kommst sondern deinen Code in der Event-Loop ab-arbeitest.

Der Weg den du mit der Hybrid Lösung gewählt hast ist IMHO ein "Umweg" zu Full-GUI.
dein CRT-Fenster darf ja keine "Ausgabe" machen wenn es nicht den Focus hat und macht ein "Timeout" im GET nicht gerade einfach.

bei einem Cl*pper GET hatten wir ja einen "WaitState" wo auf eine User Eingabe "gewartet" wird.
unter GUI sollte man "Waitstate" wie

Code: Alles auswählen

DO WHILE !lExit
*INKEY(0)
->
INKEY(0.1)
...
ENDDO

auf ein Minimum beschränken damit alle Events "durchkommen".

p.s. eine 3-PP Lib wäre vermutlich der "leichtere" Weg zu Full-GUI.

[brandelh]

Hi,

nur zur Klarstellung, ein INKEY(0) in Clipper hat ein Windows NT ff. zu 100% ausgelastet (bei mehreren Kernen nur einen davon).
In Xbase++ ist dies nicht der Fall, aber solange man nur einen Thread hat, kann in so einem Wartezustand das jeweilige Programm keine Events verarbeiten.

[DelUser01]

Hallo Auge_Ohr

in meinen Programmen verwende ich nur noch AppEvent und HandleEvent, kein InKey mehr.
Die HauptLoop arbeitet mit einem TimeOut von 25.

Es ist schon häufig ein Problem die Events der CRT-Schleife und die der bereits realisierten GUI-Objekte auseinander zu halten um keine doppelten Funktionsausführungen zu bekommen. Im Moment suche ich wieder so einen Fehler bei dem zwei verschiedene Events ausgelöst werden aber nur einer verarbeitet werden darf.

Gruß
Roland