Anmelden

View Full Version : VARPG Bildschirmaufbau Timing



caltmann
20-08-09, 15:13
Hallo zusammen!

Ich weiß nicht wie viele User sich tatsächlich noch in
der VARPG-Yahoogroup aktiv bewegen,
deshalb zur Sicherheit auch hier:

In unserer Applikation steuern wir die Längen
der darzustellenden Felder dynamisch, also je nach Inhalt.
Dadurch ändern sich auch die Positionen der angezeigten Felder.
Immer wieder kommt es hierbei vor, dass nach dem
Bildschirmaufbau unschöne Linien an alten Positionen
übrigbleiben, die erst nach einem erzwungenen
Bildschirm-Refresh (z.B.: Minimieren, Maximieren,..)
verschwinden. Es scheint sich hierbei um ein Timing-Problem
in der Darstellung zu handeln. Wenn das Fenster unsichtbar ist
und erst nach der Neuberechnung wieder dargestellt wird, treten
die Probleme nicht auf, jedoch gibt es dann natürlich ein
störendes "Flimmern" (wie auch bei Resize).
Hat vielleicht jemand damit Erfahrung, welche Abfolge an
Positions- und Größensteuerungen hier günstiger ist?
Also z.B. immer vorher die Größe anpassen, dann verschieben,
oder die Felder einzeln "verstecken" (invisible) und einzeln
aktivieren?
In den Unterlagen konnte ich keine DOs and DON'Ts dazu finden,
diese Problematik ist wohl zu speziell.

Danke für Tipps+Hinweise
lg
Chris

caltmann
24-08-09, 09:07
Im Zuge der Forschungen sind noch weitere Feinheiten
aufgetaucht.
Da sich in VARPG die Länge der einzugebenden Daten
in einem Feld ja nicht programmtechnisch steuern läßt
(wie bei manch anderen Sprachen), haben wir mit der von
VARPG generierten .ODX-Datei herumexperimentiert.
Unter Umständen könnten wir damit einige Tricks
realisieren, die sonst nicht möglich wären.
Ein am Bildschirm definiertes Feld mit 255 Stellen
kann z.B. auf 2 Stellen abgeschnitten werden.
Der Gefahren sind wir uns durchaus bewusst,
die würden wir aufgrund der erweiterten Möglichkeiten
aber je nach Fall in Kauf nehmen.
Hat sich schon jemand intensiver mit diesem Thema
auseinandergesetzt und Erfahrungen gesammelt?
Unser - bisher einziges - Problem dabei:
Wir können ein Neuladen der .ODX-Datei nicht erzwingen
(trotz CLSWIN), diese wird offensichtlich beim Start
des GUI 1x in den Speicher geladen und danach nur
von dort verwendet. Ok, war vorauszusehen und macht Sinn,
aber gibt es eventuell APIs oder einen Trick,
um das Neuladen doch irgendwie zu erzwingen?
Wir könnten dann einige performance-lastige Routinen
aus der normalen GUI-Berechnung herausnehmen.
Danke für ev. weiterführende Tipps oder Meinungen!
lg
Chris