Forum: PC-Programmierung C# Label Sicherheitsrichtlinien


von andy (Gast)


Lesenswert?

Hallo,ich habe mir mit der Microsoft express Software eine Oberfläche
erstellt die mehrere Labels enthält.Im Programm (C#) kann ich die 
hintergrundfarbe oder den Text ändern.Der Übersichthalber habe ich nun 
eine weitere Klasse erstellt,in der ich eine Methode geschrieben 
habe,die die
Hintergrundfarbe eines Labels ändern soll.Aufgerufen wird die Methode 
von der Basisklasse.Ich bekomme aber beim Compilieren immer eine 
Fehlermeldung
das der aufruf "Label1.Backcolor = Color.DarkOrange"
eine Sicherheitsrichtlinie stört.
Ich versuche nun seit 2 Tagen das Problem zu lösen.Gegoogelt habe ich 
auch,kapiere es aber einfach nicht.
Wäre jemand so nett,mir zu erklären wie man das macht.
Danke im voraus.
andy

von Christian H. (thunder2002) Benutzerseite


Lesenswert?

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

von andy (Gast)


Lesenswert?

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.

gruss

andy

von Arc N. (arc)


Lesenswert?

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

von andy (Gast)


Lesenswert?

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

von Sebastian___ (Gast)


Lesenswert?

übergebe eine refrenz der labels beim anlegen der klasse.
dann gehts.

also in etwa so:
1
public class ColorChange
2
{
3
  private label myLabel = null;
4
  
5
  public ColorChange(ref label labelform1)
6
  {
7
    myLabel = labelform1;
8
  }
9
10
}

von Peter (Gast)


Lesenswert?

andy schrieb:
> Steht diese Methode in der Form1 klappt es einwandfrei.Steht sie in der
> neuen Klasse,gibt es ärger mit den label.

kann es sein das die Klasse von dir nicht Public ist? Kannst du deine 
Methode aufrufen wenn du die sache mit dem Labels auskommentierst?

Woher kenn deine Klasse überhaupt die Labels, wann gibst du sie rein?

von Arc N. (arc)


Lesenswert?

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
    }

von andy (Gast)


Lesenswert?

Hallo danke für die antworten.

Arc net,die labels sind als private deklariert.

Sebastian,dein Vorschlag sieht soweit gut aus.
Nur wie rufe ich die Methode

 public ColorChange(ref Label labelform1)
  {
    myLabel = labelform1;
  }

auf.
Ich habe in der Basisklasse

ColorChange Change = new ColorChange();

eingefügt.

Bei 'Change ColorChange(ref label10);' erhalte ich keine 
Fehlermeldung,aber das Compilieren wird abgebrochen und auf Hilfseiten 
verwiesen.
Bei 'Change ColorChange(ref Label label10); erhalte ich 
Fehlermeldungen,das man Label nicht wie eine Variable verwenden kann.
Ich verzweifle langsam.

gruss

andy

von beyoNd (Gast)


Lesenswert?

du kannst doch einfach den wert den alten labels in einer 
zwischenspeichern und dann das alte label löschen und ein neues laben 
mit genau den selben werten, position etc erstellen.. und dne alten wert 
eintragen :)

von andy (Gast)


Lesenswert?

Hallo,da ich einige Labels habe die auch sehr oft die BackColor wechseln 
müssen,dürfte das etwas aufwendig sein.

gruss

andy

von beyoNd (Gast)


Lesenswert?

ich sehe da kein problem drin, du kannst dir doch eine funktion 
schreiben.. die die werte ausließt, label löscht, neus erstellt mit 
gewünschter farbe und altem text..

oder hab ich da einen denkfehler :D
ich hab schon lange nichts mehr mit C# gearbeitet..
also nich böse sein wenn ich falsch liege :)

lg beyoNd

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

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...

von Sebastian___ (Gast)


Lesenswert?

Ich glaube  andy sollte sih mal mit objektorientierte programmierung in 
c# auseinadersetzen.
Das was ist gepostet habe ist lediglichde der Konstruktor für die 
Beispielklasse "ColorChange", wenn du die mit "new" instanzierst, musst 
du label1 als refrernz mit übergeben und kannst damm aus der klasse die 
lokale variable myLabel ändern was ja nur ne referen auf das label 
deiner form ist.

von Ruedi (Gast)


Lesenswert?

>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.

Das bedeutet, du hast eine Klasse die von Forms abgeleitet wird ?

Also sowas

MyClass:Form1
{

...
}

und wo instanziertst du dein Klasse ?

Würdest wohl am besten mal deinen Code hier posten... als zip.

von Sebastian___ (Gast)


Lesenswert?

du schreibst eine neue klasse:
1
public class LabelChange
2
  {
3
    private Label m_label = null;
4
5
    public LabelChange(ref Label myLabel)
6
    {
7
      m_label = myLabel;
8
    }
9
10
    public void ChangeColor(System.Drawing.Color c)
11
    {
12
      m_label.ForeColor = c;
13
    }
14
  }

benutung in zb. Form1: in einem Button
1
private void btnClear_Click(object sender, EventArgs e)
2
    {
3
      LabelChange myObj = new LabelChange(ref labelIndex);
4
      myObj.ChangeColor(System.Drawing.Color.Red);
5
    }

du solltest wirklich mal die GRUNDLAGEN von C# lernen, sonst wird das 
alles gar nix und es kommen Programme raus die weder gut funktionieren 
noch auf lange zeit pflegbar sind

von Ruedi (Gast)


Lesenswert?

Ich verstehe nun aber nicht ganz, warum er für einen ChangeColor eine 
eigene Klasse schreiben und instanzieren soll. Und dann noch via ref ?

Ist eher etwas zuviel.... Da hat man nette Properties und man baut ne 
Klasse um diese zu ändern.

Da wäre wohl ne Extension angebrachter, aber das ist ja auch schon zu 
viel.

>private void btnClear_Click(object sender, EventArgs e)
>    {
>      LabelChange myObj = new LabelChange(ref labelIndex);
>      myObj.ChangeColor(System.Drawing.Color.Red);
>    }

oder

private void btnClear_Click(object sender, EventArgs e)
    {
      labelIndex.ForeColor = System.Drawing.Color.Red;
    }

sieht etwas einfacher aus.


Ausserdem kann es sein, dass er grad dran ist C# zu lernen.....

von Sebastian___ (Gast)


Lesenswert?

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.

von Sebastian___ (Gast)


Lesenswert?

man könnte das ganze natürlich auch elegant via Data Binding lösen.

von Karl H. (kbuchegg)


Lesenswert?

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.

von Ruedi (Gast)


Lesenswert?

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.

finds eigentlich immer schade, wenn solche threads in irgenwelche 
diskussionen führen, die weit weg von der eingentlichen problemlösung 
sind. wobei ich mit rügen auch bei mir anfangen darf.


cheers

von Karl H. (kbuchegg)


Lesenswert?

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.

von andy (Gast)


Lesenswert?

Hallo und danke für die zahlreichen antworten.Also es stimmt,ich bin 
grad dabei mir C# beizubringen.
Ich habe mir gedacht,das ich zum Lernen mir einen Geldspielautomaten(so 
wie sie in Kneipen hängen)programmiere.Die anzeige der 5 
Gewinnzahlen,das Geldeinzahlen,das starten des Spiels mit auswertung ob 
gewonnen wurde oder nicht klappt schon.
Ich wollte nur die Farbänderung der Labels (ich meine damit die 
aufleuchtenden Gewinnmöglichkeit, die man hochdrücken kann)
in eine andere Klasse legen,um die Form1 Klasse übersichtlich zu lassen.
Den da fällt ja einiges an,verschiedene Lauflichter wenn keiner 
spielt,Lauflicht bei Gewinn,beim hochdrücken usw.
Habs aber jetzt begriffen,das man das,was zu der Form gehört,auch in 
ihrer Klasse behandeln soll.
Nochmals danke.
gruss
andy

von Ruedi (Gast)


Lesenswert?

Nein, es geht nicht um Prinzipien, es ging um ein konkretes Problem, dem 
Problem von andy.

von Karl H. (kbuchegg)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.