Dieter hat geschrieben:ich sehe in deinem Code gar kein SetAppFocus(oTab2). Das SetAppFocus(oBrowse) reicht alleine nicht aus!
Das Browse hat aber danach den Focus.
Wenn der Focus der Tabpage sich zwischenzeitlich nicht geändert hat, dann könnte man auf SetAppFocus(oTab2) verzichten. Aber ich gehe hier immer auf die sichere Seite. Ein Focusverlust ist in Windows nie auszuschließen! Man denke nur an externe Programme, die deiner ganzen Applikation den Focus wegnehmen können.
Codeblock: Du hast Recht, eigentlich dürfte das nicht gehen, tut es aber, werde es aber trotzdem ändern. Vermutlich werden meine Funktionen erst abgearbeitet und danach erst wieder die Ereignis-Schleife, deshalb "funktioniert" es.
ich gehe davon aus, dass wenn Du vor dem oBrowse:forcestable() ein oBrowse:configure() einfügst, es dann wie gewünscht funktioniert.
Es ist zwar absurd, ich selbst verwende es an einigen Stellen, die ich anders nicht löschen konnte.
Wieso machst Du es unterschiedlich, abhängig von XPPVER > 1900355?
ein unnötiges configure() kann aber auch schaden ...
forceStable() hätte laut Doku schon immer einen stabilen Zustand erzeugen sollen, allerdings kam es häufiger vor, dass .f. zurückgegeben wurde.
Er hat wohl die Erfahrung gemacht, dass dies mit 1.90.355 nicht mehr der Fall ist.
Allerdings hat die Schleife keine Nachteile, die eine unnötige Abfrage merkt man nicht.
Hallo,
ich verwende das oBrowse:configure() immer dann, wenn sich die Datenbasis (z. B. ein Datenarray für den Browse mit neuer Zeilenanzahl) ändert. Habe dann noch niemals Probleme gehabt, beziehungsweise es würde ohne :configure() gar nicht funktionieren. Ich habe Werner das obrowse:configure() deshalb schon früher empfohlen. Ich glaube, er hat es schon ohne Erfolg ausprobiert. Er arbeitet dann wohl über einem Datalink direkt mit einer DBF-Datenquelle und manipuliert nachträglich auch keine Instanzvariablen des Browsers.
Configure() ist zu verwenden, wenn sich Eigenschaften eines Browses ändern, etwa Präsentationsparameter, Parent-Owner-Relationen und ähnliches. Wenn sich die "Anzahl der Zeilen" in einem simplen Arraybrowse ändert, sollte in aller Regel ein einfaches RefreshAll() ausreichen, es sei denn, man weist dem Array eine andere Datenquelle zu. Configure() dürfte in dieser Situation schlicht überhaupt keine Auswirkungen haben. Es ist überflüssig und nutzlos.
Dieter hat geschrieben:Ich habe Werner das obrowse:configure() deshalb schon früher empfohlen. Ich glaube, er hat es schon ohne Erfolg ausprobiert. Er arbeitet dann wohl über einem Datalink direkt mit einer DBF-Datenquelle und manipuliert nachträglich auch keine Instanzvariablen des Browsers.
Korrekt!
Muss jetzt erst mal abwarten, wie sich o. g. auswirkt, dann melde ich mich wieder.
brandelh hat geschrieben:ein unnötiges configure() kann aber auch schaden ...
forceStable() hätte laut Doku schon immer einen stabilen Zustand erzeugen sollen, allerdings kam es häufiger vor, dass .f. zurückgegeben wurde.
Er hat wohl die Erfahrung gemacht, dass dies mit 1.90.355 nicht mehr der Fall ist.
Allerdings hat die Schleife keine Nachteile, die eine unnötige Abfrage merkt man nicht.
Kann ich nur unterschreiben.
Ja, das forcestable gibt unter 2.0 kein .t. oder .f. zurück, sondern self.
Ich habe mir die Stellen in meinen Programmen angeschaut, die mir Kopfzerbrechen bereitet haben.
Unter anderem im Zusammenhang mit :resize().
Einige - nicht erklärbare - Merkwürdigkeiten habe ich behoben, indem ich ein :invalidateRect() ausgeführt habe.
In Deinem Fall geht es, eben auch um das "Zeichnen" des Browser...
Vielleicht hilft dann auch bei Dir ein oBrowse:invalidateRect() um das Neuzeichnen zu erzwingen.
(auch wenn es "eigentlich" nicht notwendig ist)
danke, ich warte jetzt ab, ob die anderen Tipps was bringen, ansonsten bau ich das invalidateRect ein.
Es wird aber nichts helfen bei der anderen Konstellation:
Das passiert auch, wenn ein Fenster im Hintergrund ist, das Vordergrundfenster gehided wird. Dann wird manchmal das Hintergrundfenster, das dann ja sichtbar wird, nicht neu gezeichnet / komplett dargestellt.