@Filippo
Konntest Du das Speicherproblem eigentlich mittlerweile beheben bzw. finden? Wenn er nach dem Beenden der IDE den Speicher nichtmal freigibt, dann ist das aber irgendwie merkwürdig. Da würde ich dann Erel mal fragen.
Nochmal generell:
Wenn man die ListItems updated sollte man auf jeden Fall aufpassen, dass man das Image aus dem Item holt, und dieses dann wieder verändert bzw. mit ImageLibEx Funktionen bearbeitet (Andrew hat in den aktuellsten Versionen der ImageLibEx einen Mechanismus eingebaut, dass alte Images immer Disposed werden, wenn ein neues zurückgegeben wird).
BitMaps in .NET sind je nachdem, wie sie erstellt wurden "unmanaged" Speicherbereiche, d.h. sie werden vom Garbage Collector nicht mehr freigegeben, wenn alle Referenzen zu einem Image weg sind. D.h. man muss sehr genau aufpassen, dass man Images/BitMaps die nicht mehr benötigt werden schön mit Dispose entsorgt.
Will man meine Methode mit den Images für eine BList verwenden, sollte man aufpassen, dass die Liste nicht zu groß wird. Abgesehen davon, dass eine lange Liste im BList Objekt nicht mehr vernünftig zu bedienen ist (man scrollt sich dumm und dämlich) verbraucht sie halt eine Menge Speicher. Wenn man dennoch so eine lange Liste benötigt, sollte man sich vielleicht überlegen, nur die Items mit richtigem Inhalt zu füllen, die um den sichtbaren Bereich herum liegen und alle anderen mit einem (immer dem selben) Dummy Image. Wenn dann gescrollt wird, müsste man halt wieder Items, die "zu weit weg" sind mit dem Dummy-Image belegen und andere Items korrekt rendern. So ungefähr macht das PocketTwit z.B. auch in seiner Liste. Damit könnte man das Speicherproblem etwas eingrenzen. Erhöht natürlich den Programmieraufwand.
Gruß,