Verhalten FlowLayoutPanel

  • VB.NET
  • .NET (FX) 4.0

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von ThePlexian.

    Verhalten FlowLayoutPanel

    Es geht um eine Explorer-Darstellung von Thumbnails auf der Basis eines FlowLayoutPanels (FLP). Die Vorgehensweise schien unter W8.1 bisher alle Erfordernisse zu erfüllen.

    Bei einer Reduzierung der Spaltenzahl auf 1 wächst die rechnerische Zeilenzahl des FLP sprunghaft. Ab einer y-Koordinate von etwa 32.000 klappt es nicht mehr mit der Generierung von Controls und deren Beschickung mit Bildern. Das letzte angezeigte Control wirkt wie abgeschnitten. Der Algorithmus arbeitet zwar ohne exception bis zum Ende weiter. Aber der untere Teil des FLP bleibt weiß. Bei einer Spaltenzahl > 1 wird diese Grenze natürlich erst bei einer größeren Zahl von Controls erreicht. Könnte mir VB oder was auch immer einen Streich spielen? Oder bin ich einfach zu dumm?

    Gibt es da eine heimliche interne Barriere (z.B. 16 Bit). Das FLP erreicht die notwendige Größe an Zeilen, wie die ScrollBar und der weiße Bereich anzeigen. Aber es scheint, als würden ab 32.000 alle Controls auf dieselbe Koordinate platziert, obwohl der Befehl

    FLP.Controls.Add(PAN)

    ein automatisches Fortschreiben der Position der Controls gewährleisten sollte.
    Danke an 'Erfinder des Rades ' für die schnelle Reaktion.

    Die Zahl 32.000 ist die relative Position im FLP, also die Top-Koordinate des einzelnen Controls. Bei der einspaltigen Anordnung der Thumbnails entspricht das im Beispiel dem Control Nr. 229. Es hängt auch nicht mit der Anzahl der Controls zusammen, denn sobald die Controls mehrspaltig (also mit weniger Zeilen) angeordnet werden, geht es ja. Es hängt auch nicht mit der Größe des FLP zusammen. Die Platzreservierung erfolgt nämlich für alle Paneele, wie der Rollbalken anzeigt. Mehrspaltig wurden Verzeichnisse mit über 1000 Dateien getestet. Die Zahl der einspaltig richtig wiedergegebenen Paneele steigt auch, wenn die Images kleiner gemacht werden. Der Fehler könnte auf ein (falsch wirkendes und nicht kommentiertes) internes Limit zurückzuführen sein. Hier ein Teilprotokoll, was während der Generierung mit FLP.Controls.Add(PAN) entstanden ist:

    .....
    Name, x, y = PAN0224, 3, 32259
    Name, x, y = PAN0225, 3, 32403
    Name, x, y = PAN0226, 3, 32547
    Name, x, y = PAN0227, 3, 32691
    Name, x, y = PAN0228, 3, 32767
    Name, x, y = PAN0229, 3, 32767
    Name, x, y = PAN0230, 3, 32767
    Name, x, y = PAN0231, 3, 32767
    .......

    Ab PAN0228 wird für alle Paneele die gleiche Top-Koordinate zurückgegeben. Optisch sieht das so aus (beachte die Stellung des Rollbalkens):

    c:\!\00 TMP\FehlerFLP.jpg

    drschef schrieb:

    Die Zahl 32.000
    ist zufälligerweise sehr genau Short.MaxValue, für einige Controls ein Maximalwert.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    die Erklärung überzeugt. Danke! Der Tip mit dem FlowLayoutPanel stammte vom 23. 6.14 von 'RodFromGermany' und schien perfekt. Gibt es eine Möglichkeit diesen Parameter zu ändern? Ich habe auf Anhieb nichts gefunden, habe aber ermittelt, dass sich das TableLayoutPanel genauso verhält. Ich erinnere mich auch an ein Feature von Corel vor vielen Jahren, dass man am rechten Rand des Entwurfs-Fensters einen Bildstreifen zum aktuellen Verzeichnis anzeigen konnte. Dieses Feature wurde zu meinem Bedauern nicht in die folgenden Versionen übernommen. War das der Grund?. Gibt es nun außer dem Windows-Explorer, der so gar nicht in mein Gesamtkonzept passt, und für meinen Zweck andere Nachteile aufweist, überhaupt noch eine Lösung außer was selbst Gebasteltes, was am Ende auch auf irgend eine Windows-Barriere trifft?

    drschef schrieb:

    diesen Parameter
    Meinst Du Short.MaxValue?
    Nein, das ist iwo im Framework fest vorgegeben.

    drschef schrieb:

    was selbst Gebasteltes
    Beschreib mal detailliert, allerdings ohne eine Lösung vorzugeben, was genau passieren soll.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Beschreib mal detailliert, allerdings ohne eine Lösung vorzugeben, was genau passieren soll.


    Fotos werden grafisch mit Textkomponenten aufgepeppt. Das Entwurfsfenster mit der Parametrisierung nimmt viel Platz weg. Ein Button öffnet ein zweites Fenster (siehe oben) für die Bild-Auswahl. Dazu gehört noch eine Vorschau mit der eingearbeiteten Textgrafik. Bei einem 1024er-Bildschirm ist der Platz knapp. Deshalb wollte ich die Bildkollektion für die Auswahl einspaltig machen. Aber irgendwann greift das Problem auch bei mehrspaltiger Anordnung.



    male mit GDI+ die 4-5 relevanten Dateien / Bilder


    Könnte vielleicht gehen. Aber es geht nicht um 4-5 Bilder sondern bei einer modernen SD-Card vielleicht um 1000 Bilder oder mehr. Wer weiß, was da wieder für ein heimliches Limit zuschlägt. Und dann muss die ganze Bildauswahl (für einen anderen Anwendungszweck auch Mehrfachauswahl) und die Scrollfunktion auch von Hand programmiert werden. Aber der Gedanke ist als Anregung erst mal angekommen. Danke.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „drschef“ ()

    drschef schrieb:

    Fotos werden grafisch mit Textkomponenten aufgepeppt.
    Willst Du das in VB machen
    oder
    nutzt Du dazu ein professionelles Programm?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich habe das in VB gemacht. Das Programm ist bereits fertig und besitzt standardmäßig eine Listenauswahl. Die Explorer-Auswahl sollte eine Zugabe sein. Die Barriere, die sich hier auftut, scheint ja kein VB-Problem, sondern ein .net Framework-Problem zu sein. Inzwischen habe ich mit dem gleichen Misserfolg mit dem einfachen Panel experimentiert. Warum sollte man auch ausgerechnet nur VB mit einem solchen Limit ausstatten, nur um es abzuwerten? Da wäre schon eher die Frage nach einer programmiertechnisch andersartigen Explorer-Darstellung, wie z.B. die bereits erwähnt GDI+-Variante.
    Das ist kein .Net-Problem, sondern ein Problem von Win32, das sich auch nicht umgehen lässt oder ähnliches, dieser Wert ist fix. Wobei "Problem" hier eig. relativ ist, weil Controls sowieso nie dafür gemacht waren, in solchen Mengen verwendet zu werden.
    GDI+ wäre hier eine Möglichkeit, aber noch besser ließe sich dein Programm hier in WPF umsetzen, sollte auch nicht allzu schwer sein.
    GDI+ wäre hier eine Möglichkeit


    Habe gerade eine Lösung in GDI+ angedacht. Vorher hatte ich noch das einfache Panel ausprobiert, dabei gleiches Problem. WPF kommt bei Misserfolg, denn damit habe ich noch keine Erfahrung.

    Neuer Stand. Lösung in GDI+ ausprobiert (globale Picturebox). Die wird bei der gleichen Koordinate blockiert. Also scheint das Limit global zu wirken. Das muss ich erst mal verdauen. Nun misstraue ich aber auch WPF.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „drschef“ ()

    drschef schrieb:

    Also scheint das Limit global zu wirken.
    Dann solltest Du die Philosophie wechseln.
    Mach die Anzeige dynamisch, imer relativ zu einem index +-n Bilder anzeigen, niemals alles im RAM halten.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    drschef schrieb:

    Nun misstraue ich aber auch WPF.
    WPF basiert auf DirectX, nicht Win32/GDI, die Elemente werden da komplett anders auf den Bildschirm gebracht. Ich kann es dir nicht 100%ig versprechen, aber du solltest da keine Probleme haben, DirectX erlaubt Koordinaten im kompletten float-Raum (also von etwa - bis +10^38).
    Anzeige dynamisch, immer relativ zu einem index +-n Bilder


    Der Gedanke kam bei mir schon mal hoch, aber ich habe die Nutzung von "fertigen Werkzeugen" vorgezogen. Wäre ja auch mit einem FlowLayoutPanel mit dynamischem Löschen und Ergänzen bei Bewegung denkbar. Nun werde ich mich als nächstes daran versuchen. Kann aber dauern. Nicht wegen der Programmierung, sondern ab Dienstag steht Urlaub an. Ich melde mich auf jeden Fall wieder.

    DirectX erlaubt Koordinaten im kompletten float-Raum


    Ich stelle die WPF-Empfehlung noch zurück, werde sie aber aufgreifen, wenn gar nichts mehr bleibt oder wenn ich Zeit für Neuland habe, was bei Rentners schon denkbar ist.

    Danke erst mal den Helfern!
    Ich hatte angekündigt, mich nach dem Urlaub und einem spürbaren Fortschritt wieder zu melden. Das geschieht hiermit. Ich habe den Vorschlag einer dynamischen Anzeige aufgegriffen und realisiert. Das bedeutet - die Anzeige erfolgt in einer starren Matrix von Controls. Die thumbnails werden beim Scrollen nur durchgeschoben. Die Selection von Gruppen mit Shift und Ctrl war ein wenig knifflig, läuft aber inzwischen auch. Damit gibt es praktisch keine Restriktionen in der Anzahl der Fotos mehr. Bei Fotos mit 3 Megapixeln verzögert sich die Aufbereitung kaum. Bei einer Auflösung von 12 Megapixeln wird die Bereitstellung (Generierung der Thumbnails im Background) natürlich langsamer.

    Danke nochmal allen Mitwirkenden
    u.U. verbessert das die Performance, wenn du es nicht schon so machst:
    msdn.microsoft.com/de-de/library/ets0sayh(v=vs.110).aspx
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais