Listview erst beim zweiten öffnen

[greenmile]

Hallo,

irgendwie stehe ich gerade auf dem Schlauch. Gegeben sind 2 Listviews in einem Multiview. Wenn man links einen Eintrag wählt, wird entsprechend rechts (zweite LV) gefüllt. Ich habe im Designer fast alles ausgeblendet und verarbeite das "UpdateObjects" Ereignis, um ein Image und einen Text hinzuzufügen. Danach wird die Liste, die sich auf/in einem Multiview befindet, angezeigt. Das Problem ist nun: Die Einträge werden erst beim zweiten Öffnen des Multiview sichtbar, beim ersten mal sind die Items einfach leer. Ich habe schon Repaint, Invalidate und co probiert. Das hat in Seattle problemlos funktioniert.

[Rollo62]

Also du testest Rx10.1 Berlin ?

Benutzt du den MultiView mit der Slide-Funktion ?
Damit hatte ich auch unter Rx10 Probleme, weil hier Füllen und Schieben sich in die Quere kommen.
Deshalb hatte ich alle MultiViews wieder rausgeschmissen, und das manuell gemacht.

Rollo

[greenmile]

Zitat von Rollo62:

Also du testest Rx10.1 Berlin ?

Benutzt du den MultiView mit der Slide-Funktion ?
Damit hatte ich auch unter Rx10 Probleme, weil hier Füllen und Schieben sich in die Quere kommen.
Deshalb hatte ich alle MultiViews wieder rausgeschmissen, und das manuell gemacht.

Rollo

Ja, unter DX10 gab es auch schon Probleme, irgendwie habe ich die durch eine ordentliche Portion Pfusch in den Griff bekommen. Bzw man sieht es jetzt nicht mehr. Unter 10.1 klappt das aber leider nicht, also der Pfusch kann den Pfusch nicht verbergen.

Wie hast Du es statt Multiview gelöst? Irgendwie muss ich die Listview rechts ja einblenden. Und, was mich viel mehr interessiert: Wieso machen 2 Multiviews eigentlich Probleme? Hätte gerade Lust mich mal wieder über die QS bei EMBT lustig zu machen, lasse es aber.

[Rollo62]

Ich habe das Sliden generell stark reduziert, das sieht zwar schön aus,
macht aber den Eindruck bei der Bedienung der App auch etwas lahm.
Ohne sliden wirkt die Bedienung flotter, und ich handle mir vor Allem keine Probleme damit ein.

Ein Slide mit Panel mache ich noch, um zusätzliche Bedienfunktionen anzuzeigen.
Das fahre ich einfach rein/raus mithilfe einer FloatAnimation (von unten rein in Position,
und wieder nach unten weg).
Das klappt ganz gut, aber womöglich nur weil ich in der Zeit nichts anderes machen muss.

Wenn z.B. der MultiView slidet, und ich parallel mit dem slidenden View noch die Datenbank aktiviere
und per LiveBindings in eine ListView schreiben lasse, dann ruckelt es.
Das scheint sich nicht so einfach entkoppeln zu lassen, die Wahl ist
- entweder alles vorherberechnen und geöffnet lassen - dann slidet es gut - braucht aber vollen Memory Footprint
(und braucht nach dem Start länger um alles vorzubereiten)
- oder das Sliden weglassen - und bei lägeren Operationen einen Animator zeigen.
(weil z.B. FormCreate eigentlich schnell genug funktioniert ist das kaum nötig)

Übrigens ruckelt der AniIndicator genauso, wohl aus dem gleichen Grund.
Deshalb lege ich bei solchen Wartezeiten noch zusätzlich einen grauen, Opaque 0.7 Panel über den ganzen View.
In dem sitzt dann der AniIndicator (der ruckeln kann).
Damit sieht dann zumindest etwas interessanter aus, wenn kurze Wartezeiten nötig sein, und das Ruckel
fällt nicht so auf.

Ich bin generell etwas vorsichtig bei den Animation geworden, weil wohl einige mit
Application.ProcessMessages funktionieren.
Threads und Tasks sind eine tolle Sache, aber schlussendlich muss es immer wieder an UI Controls übergeben
werden, und da kann es dann wieder hängen.

Hatte mal versucht möglichst alles in Backgroundthreads zu verlegen, und dann nur die UI-Zugriffe zu synchronisieren.
Das funktioniert ganz gut, aber die meisten Zugriffe sind halt die UI-Controls, ob sich ein Thread für
ein paar Hintergrundaufgaben lohnt ist mir noch nicht ganz klar.
Hängt wahrscheinlich vom jeweiligen Problem ab.
Ich möchte baer gar nichts Besonderes, sondern erstmal nur ein DataSet mit einem ListView verbinden,
ohne das es hängt.
Bei 20 Text-Einträgen geht das Alles auch, bei 2000 mit Bitmaps sieht es aber schon anders aus.

Rollo

[greenmile]

Danke für die ausführliche Antwort, ich denke ich werde es einfaden.

Das (mein) Problem bei Delphi ist doch: Jetzt entwickel ich einen Workaround. Alle 6 Monate darf ich aber wieder alle Workarounds prüfen, ob die A) noch funktionieren und/oder B) der eigentliche Fehler vielleicht inzwischen behoben wurde. Das macht mich echt noch wahnsinnig, weil es sau-aufwendig ist. Und es knallt dann an Ecken, an denen man es nicht vermutet.

Liebe Entwickler von EMBT: Lasst Euch doch lieber mehr Zeit und macht es dafür vernünftig. Schaut mal bei anderen Firmen nach wie die es lösen. So ein Chaos mit "heute funktioniert es nur mit einem Workaround", "Morgen funktioniert weder Workaround noch die eigentliche Funktion", "Übermorgen brauche ich einen anderen Workaround" gibt es echt nirgendwo. Hört auf, Funktionen und Konstanten quer durch die Unit-Welt zu verschieben oder gar umzubenennen. Hört auf mit Pfusch, der in der nächsten Version zwar auch gepfuscht ist, aber wieder anders. Oder aktualisiert endlich mal ältere Versionen damit ich nicht gezwungen bin, immer die neueste Version verwenden zu müssen, nur damit Android X und MacOS Y unterstützt wird.

[Sherlock]

Amen!

Sherlock

[greenmile]

Sorry, könnte aber gerade kotzen weil ich wieder Zeit mit pfuschen verplempern muss, die ich eigentlich kaum habe.

[Rollo62]

Diese Phase habe ich zum Glück seit Dezember hinter mir

Hoffentlich bleibt es so (auch wen ich 10.1 Berlin installiert habe).

Allerdings kommt ein bischen leichte Übelkeit hier und da immer mal mal wieder auf

Einfach was gegen Reisekrankheit einnehmen und weitermachen

Rollo