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
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
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
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
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
ü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 | }
|
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?
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 | }
|
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
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 :)
Hallo,da ich einige Labels habe die auch sehr oft die BackColor wechseln müssen,dürfte das etwas aufwendig sein. gruss andy
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
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...
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.
>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.
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
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.....
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.
man könnte das ganze natürlich auch elegant via Data Binding lösen.
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.
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
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.
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
Nein, es geht nicht um Prinzipien, es ging um ein konkretes Problem, dem Problem von andy.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.