C# Label Sicherheitsrichtlinien

Hi,

ich kann mir so leider kein Bild davon machen was deine Klassen/Methoden 
genau tuen, bitte poste doch einmal den Quelltext.

Grüße Chris

andy schrieb:
> Hallo, in der neuen Klasse ist die Fogende Methode:
>
> public  void Farbe_aendern()//get set methode probieren
>         {
>             label10.BackColor = Color.DarkOrange;
>             label9.BackColor = Color.DarkOrange;
>             label8.BackColor = Color.DarkOrange;
>             label7.BackColor = Color.DarkOrange;
>             label6.BackColor = Color.DarkOrange;
>         }
> Steht diese Methode in der Form1 klappt es einwandfrei.Steht sie in der
> neuen Klasse,gibt es ärger mit den label.Sämtliche label aufrufe
> verstossen gegen Sicherheitsrichtlinien.Die neue Klasse erbt auch alles
> von Form1.Hoffe das hilft.

Klick mal ein Label an und sieh dir dessen Eigenschaften an...
Stichwort Modifiers d.h. die Member sind normalerweise privat und damit 
auch von einer abgeleiteten Klasse nicht änderbar.


> gruss
>
> andy

andy schrieb:
> Hallo,soweit bin ich schon gewesen.Wenn ich die eigenschaft auf public
> stelle,klappt das Compilieren gar nicht,er bricht ohne Fehlermeldung ab.
> Es muss doch möglich sein,änderungen aus einer anderen Klasse
> auszuführen.
> Bei google habe ich etwas von get und set gelesen,verstehe aber nicht
> wie das funktioniert.Vielleicht kann mir das ja hier jemand erklären.
>
> gruss
>
> andy

Beispiel: Wenn Form1 eine Form ist, die im Designer erzeugt wurde (oder 
irgendeine andere Basisklasse ist), dann funktioniert folgendes auf 
jeden Fall,
wenn die Member, auf die zugegriffen werden soll, protected sind.

1

   public class Form1 : Form {

2

       ....

3

       protected Label label1;

4

   }

5

6

   public class Form2 : Form1 {

7

        public Form2() :base() {

8

             label1.BackColor = Color.Red;

9

        }

10

    }

Das Problem ist das du auf versuchst auf private Elemente zuzugreifen. 
Überlege mal warum die so heißen und was ein "Verstoß gegen 
Sicherheitsrichtlinen" in de Zusammenhang bedeuten könnte.
Das mindeste ist das du einen protected Modifier benötigst.
Warum du dieses "Setzen der Farbe" nicht gleich in der Basisklasse 
implementierst ist mir auch schleierhaft.
Außerdem ist es sicher einfacher ein Array oder eine Liste von Labels zu 
nutzen anstelle von label1, label2, label...

Sebastian___ schrieb:
> es ging doch darum aus einer anderen klasse als Form1 das Label zu
> ändern, und das hat er nicht hinbekommen.
> Sprich wie kann er aus einer belibigen Klasse zb. der LabelChange
> klasse, die Labeleigenschften unabhängig vond der Form1 ändern.

Und die Antwort in einer objektorientierten Welt kann nur lauten:
gar nicht!

Ausserhalb von Form1 geht es überhaupt niemanden irgendetwas an, dass es 
da überhaupt ein Label gibt.
Das Label realisiert meinetwegen die Implementierung einer 
Caption/Markierung oder wie auch immer man den das bezeichnen will. Die 
Form stellt daher eine Methode zur Verfügung, mit der man die Farbe 
dieser Caption/Markierung verändern kann. Das das dann innerhalb der 
Form darauf hinausläuft, dass ein Label diese Farbe bekommt, ist nur für 
die Form interessant und für sonst niemanden!

Stell dir einfach vor, das Label würde in 2 Wochen gegen eine Bitmap 
ausgetauscht, die 2 Zustände haben kann, die meinetwegen durch Farben 
symbolisiert werden. Warum soll es dann ausserhalb von Form1 
irgendjemanden interessieren, dass diese Farbe jetzt nicht mehr auf ein 
Label geht, sondern dass da eine andere Bitmap angezeigt wird. Eben! 
Niemand interessiert das und niemanden soll das auch interessieren. Die 
Form bekommt den Auftrag diese Markierung in einer anderen Farbe 
darzustellen. Wie das realisiert wird, ist Sache der Form und von 
niemandem sonst.

Das ist eine der Quintessenzen der objektorientierten Programmierung: 
Objekte (in diesem Fall die Form) kümmern sich selbst um ihre Member und 
niemand von ausserhalb hat sich an diesen Membern zu vergreifen. Bei 
abgeleiteten Klassen kann man manchmal ein Auge zudrücken aber wenn man 
objektorientierte Programmierung ernst nimmt, dann haben im Grunde auch 
abgeleitete Klassen nichts an den Membern der Basisklasse verloren.


Edit: Die Sache geht im Grunde noch weiter.
Diese Farbe symolisiert etwas: Ob ein Zustand gültig ist, ob er ungültig 
ist, ob ein Fehler aufgetreten ist oder dergleichen.
Die Form sollte daher gar nicht den Auftrag erhalten eine Farbe 
darzustellen, sondern den Zustand: ok, nicht ok, fehlerhaft oder was 
auch immer auftreten kann. Und die Form entscheidet, wie sie das machen 
will: Indem sie einem Label eine andere Farbe verpasst, indem sie eine 
andere Bitmap anzeigt, indem Eingabefelder gesperrt werden, indem eine 
MessageBox hochpappt oder was einem gerade einfällt bzw. sinnvoll ist.

Objektorientierte Programmierung bedeutet auch: Aufträge dorthin 
delegieren wo sie hingehören. Dazu muss man sich aber den Aufträgen 
selbst widmen und nicht der Art und Weise wie sie implementiert werden.

Ruedi schrieb:
> naja... im prinzip schon, aber für andy's problem doch schon recht weit
> ausgeholt und ich denke, andy hat wohl immer noch sein problem.

Was ist da weit hergeholt, wenn man der Form eine Memberfunktion 
verpasst: SetIrgendwasColor
und die Form wendet die dann auf das Label an.
In C# kann man das auch noch wunderschön in ein Property verpacken.


>
> finds eigentlich immer schade, wenn solche threads in irgenwelche
> diskussionen führen, die weit weg von der eingentlichen problemlösung
> sind.

Das Problem an der Sache ist, dass es hier um Prinzipien geht. Es gibt 
nicht wenige Programme da draussen, die sich zwar 'objektorientiert' 
schimpfen, bei denen die Objektorientiertheit bei der Verwendung eines 
C++ Compilers und der Verwendung des Schlüsselwortes 'class' aufhört :-)

Will man objektorientiert arbeiten, dann muss man auch seine Denkweise 
umstellen. Und dazu muss einem klar sein, was es denn mit Objekten auf 
sich hat, was das impliziert, welche Konsequenzen und Folgen das hat, 
welche klassischen Denkmuster nicht mehr angebracht sind. Nur wenn man 
diese Dinge auch beherzigt, wächst man in ein OOP Design hinein und 
bekommt als Gegenleistung gut wartbare Programme, bei denen eine Änderug 
an einer Stelle nicht das komplette System instabil macht. Und eines der 
wichtigsten Prinzipien ist es nunmal: Ein Objekt exportiert 
Funktionalität. Wie diese Funktionalität im Objekt implementiert ist, 
geht ausserhalb des Objektes niemanden etwas an und darauf bekommt auch 
niemand direkten Zugriff. Weg von der Mentalität: Ich als Programmierer 
greife zu, wo immer ich will. Hin zu: Meine Objekte sind 
Befehlsempfänger über die Funktionalität, die sie zur Verfügung stellen. 
Und sie sind stur! Was ich nicht sehen soll, krieg ich ich nicht zu 
Gesicht bzw. ich kriege es nicht zu fassen. Die Lösung letzteren 
Dilemmas liegt jetzt aber nicht darin, mit der Brechstange ins Objekt 
einzubrechen, sondern dem Objekt die neu gewünschte Funktionalität 
beizubringen.

Wer das erste mal erlebt hat, wie ein einem guten Design die Dinge 
regelrecht ineinanderfallen, wie eines zum anderen passt, wie gut sich 
gut designte Objekte benutzen lassen, ohne sich den Kopf ständig um 
irgendwelche Details zerbrechen zu müssen, der wird OOP nie mehr missen 
wollen.

Das konkrete Problem kannst du aber nur dann vernünftig lösen, wenn du 
die Prinzipien der Objektorientierten Programmierung kennst.

Ein konkretes Problem könnte sein, dass ein Gastank leckt. Eine 
vorgeschlagene Lösung könnte sein ein Heftpflaster über das Leck zu 
kleben. Solange man die Prinzipien, die Grundlagen nicht kennt, wird man 
das Heftpflaster als vernünftige Lösung ansehen. Hält doch .... 10 
Sekunden lang.

Vernünftige Lösungen erfordern immer, dass man die zugrundeliegenden 
Prinzipien kennt. Und wenn ein Frager offenbar die vernünftige Lösung 
nicht selber findet, dann muss man sich fragen, ob er die 
zugrundeliegenden Prinzipien verstanden hat, die einen zu der Lösung 
führen würden.

Dies hier ist so ein Fall. Die Lösung besteht nicht darin, möglichst 
kompliziert in die Klasse einzubrechen, sondern seine Ansicht zu 
wechseln ob diese Operation überhaupt möglich sein soll. Und nein, aus 
OOP Sicht soll diese Operation gar nicht möglich sein. Der komplette 
Ansatz ist falsch. Nur versteht man das nicht, wenn man die OOP 
Sichtweise nicht versteht.