@Ressourcen: ich verweise mal auf den thread
http://www.delphipraxis.net/internal...ct.php?t=54673 , wo sich jemand über meine ressourcenfressenden 128 RBProgressbars beschwert hatte:
Zitat von
Velgreyer:
Nur so als Tipp: Benutz Canvas und zeichne eine komplette Oberfläche mit der Auswertung, und nicht 127 Progressbars. Ich seh ja immer wie sich das ganze aufbaut wenn ich das Fenster in den Vordergrund nehme
Und das hier wollte ich eben als lösung des ganzen ausprobieren.
@Hansa: Du meinst also, wenn ich schon (Deiner meinung nach) absoluter Noob bin, darf man mir nicht wohlmeinend ein beispiel zeigen?
(Mir fällt auch sonst öfters auf, dass zu, sagen wir mal, ziemlich extreme Meinungen äusserst. vielleicht solltest du dir überlegen, ob du deinen ton nicht manchmal etwas mäßigen willst. Denn ein noob wie ich wird von so etwas wie "das behaupten einige andere auch und scheitern erbärmlich." eher abgeschreckt als wermutigtm, sich richtig reinzuhängen.)
Und ausserdem, wenn ich mich schon nicht von der meinung "wenn ich eine property mit read und write zugriff habe, kann der
OI immer darauf zugreifen" abbringen lasse, hilft doch eigentlich nur noh quelltext, der das gegenteil beweist. Fakten fakten fakten!
jetz schau ich mir aber erstmal den anhang von xaromz an.
EDIT: ich sehe, das ist jetzt von TGraphicControl abgeleitet. muss das denn sein? und auf welches canvas zeichnet es denn jetzt?