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

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?

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.

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.

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.

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