Entwickler-Ecke

C# - Die Sprache - convertierung von point in int?


mr.eddy - So 13.01.08 23:32
Titel: convertierung von point in int?
ist es möglich

C#-Quelltext 
1:
 
mylabel.Tag = new Point(x, y);

von point wieder in z.B. int zu konvertieren sodaß man diesen wert in einem 2 dimensionalen array nutzen kann?


Christian S. - So 13.01.08 23:39
In einem 2d-Array kannst Du doch einfach x und y verwenden :gruebel:


mr.eddy - So 13.01.08 23:59
ja aber wenn ich mehere labels auf einmal erstelle kann ich die koordinate ja nur im tag mitgeben und via normale variable geht da nur eine mit


Christian S. - Mo 14.01.08 00:18
Tag ist vom Typ Object, da kannst Du jeden beliebigen Datentyp drin speichern, auch einen Punkt.


Kha - Mo 14.01.08 14:52
@mr.eddy: Tag-Lösungen klingen immer nicht gerade optimal ;) . Leite doch von Label ab und füge eine neue Eigenschaft hinzu, sind nur ein paar Zeilen:

C#-Quelltext 
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
 
class MyLabel : Label
{
  public Point ArrayPosition { get; set; } // auto-implemented properties, ab C# 3.0 / VS 2008
  // sonst eben über den herkömmlichen Weg:
  // Point arrayPosition;
  // public Point ArrayPosition {
  //   get { return arrayPosition; }
  //  set { arrayPosition = value; }
  // }
}


mr.eddy - Mo 14.01.08 15:44
was bewirkt den get und set ?
sry bin noch einsteiger


Christian S. - Mo 14.01.08 15:48
user profile iconKhabarakh hat folgendes geschrieben:
@mr.eddy: Tag-Lösungen klingen immer nicht gerade optimal ;) .
"immer" ist ein großes Wort ;-) Das sollte man von Fall zu Fall entscheiden und für ein einfaches 4-gewinnt dürfte das IMHO vollkommen ausreichen.


mr.eddy - Mo 14.01.08 15:54
IMHO ? xD (k hat sich erledigt)


golgol - Mo 14.01.08 16:00
user profile iconmr.eddy hat folgendes geschrieben:
was bewirkt den get und set ?
sry bin noch einsteiger


Das kommt aus der Objektorientierten Programmierung (OOP): Variablen einer Klasse sind für gwöhnlich von aussen nicht zugreifbar (weder zum Lesen noch zum Schreiben). Du musst also für jede Klassenvariable eine Methode schreiben, die dir den Lese- (sog. getter-Methoden(get)) oder den Schreibzugriff (sog. setter-Methoden (set)) ermöglichen. Bei C# wird das normalerweise über Properies gemacht, die da vieles vereinfachen und eine echt nette Sache sind.
Du solltest dir vieleicht zunächst was über die OOP durchlesen bevor du mit C# weiter machst, sonst stößt du früher oder später auf immer mehr Begriffe die du nicht kennst, und das kann echt hinderlich sein. Schau dir z.B. das mal bei Wikipedia [http://de.wikipedia.org/wiki/Objektorientierte_Programmierung] an.



P.S.: IMHO = In my humble opinion


mr.eddy - Mo 14.01.08 16:18
ah danke mach ich


Kha - Mo 14.01.08 20:50
user profile iconChristian S. hat folgendes geschrieben:
Das sollte man von Fall zu Fall entscheiden und für ein einfaches 4-gewinnt dürfte das IMHO vollkommen ausreichen.
Das Argument, dass es für einen Anfänger vlt. leichter ist, hätte ich noch verstanden (wobei er es natürlich eher früher als später sowieso lernen muss), aber vom Verfahrens-Optimum bin ich immer noch überzeugt ;) . Ich schreibe doch wirklich lieber zwei Zeilen mehr, anstatt eine Property mit einem nichtsaussagenden Namen, der ich einfach vertraue, dass sie das Richtige enthält[meta]Ein 3rd-Party-Control, das intern Tag benutzt... DAS wäre mal etwas Lustiges *g*[/meta], ständig zu casten. Sonst kann ich ja gleich zu den untypisierten Pointern zurück ;) . Eine Definition des Optimums wäre ja das Ziel, dass eine zweite Person (z.B. der Herr Lehrer ^^ ) beim Überfliegen des Codes seinen Sinn erfassen kann, und das trifft bei solchen "kleinen Schweinereien" wie Tag keinenfalls mehr zu.


Christian S. - Mo 14.01.08 21:07
user profile iconKhabarakh hat folgendes geschrieben:
Ich schreibe doch wirklich lieber zwei Zeilen mehr, anstatt eine Property mit einem nichtsaussagenden Namen, der ich einfach vertraue, dass sie das Richtige enthält[meta]Ein 3rd-Party-Control, das intern Tag benutzt... DAS wäre mal etwas Lustiges *g*[/meta], ständig zu casten.
Es handelt sich ja nicht um ein 3rd-Parte-Control, sondern um das Standard-Label. Und ein 4gewinnt ist doch irgendwie so übersichtlich, dass man sicher sein kann, was in der Eigenschaft steht. Und wieso "ständig casten"? In diesem Fall reicht einmal. :nixweiss:

Klar, wenn das ein "richtiges" Projekt wäre, würde man das nicht über die Tag-Eigenschaft machen. Aber dann würde man sicherlich auch eine Klasse einführen, welche die ganze Spiellogik implementiert, eine Komponente, welche das Spielfeld darstellt (und damit es hübsch aussieht vielleicht gar keine Labels verwendet), etc.

Es ist aber nun mal ein "Schreib's mal eben runter"-Projekt und da benutz ich die Tag-Eigenschaft, die in diesem Fall gar nicht so schlimm ist (siehe oben).

user profile iconKhabarakh hat folgendes geschrieben:
Sonst kann ich ja gleich zu den untypisierten Pointern zurück ;) .
Wir wollen mal nicht übertreiben.


Kha - Di 15.01.08 12:18
user profile iconChristian S. hat folgendes geschrieben:
user profile iconKhabarakh hat folgendes geschrieben:
Sonst kann ich ja gleich zu den untypisierten Pointern zurück ;) .
Wir wollen mal nicht übertreiben.
Was stellt dann deiner Meinung nach TComponent.Tag dar :? ?
Naja... in einem eigenen Projekt, egal wie klein, würde ich auf jeden Fall die Property einfügen, wenn noch eine zweite Person den Quelltext zu sehen bekommt. Bevor aber selbst der Lehrer den Quelltext nicht mehr versteht, bleiben wir wohl wirklich lieber bei Tag.


Christian S. - Di 15.01.08 15:13
user profile iconKhabarakh hat folgendes geschrieben:
user profile iconChristian S. hat folgendes geschrieben:
user profile iconKhabarakh hat folgendes geschrieben:
Sonst kann ich ja gleich zu den untypisierten Pointern zurück ;) .
Wir wollen mal nicht übertreiben.
Was stellt dann deiner Meinung nach TComponent.Tag dar :? ?
Zumindest mal keine Pointer, den ich beliebig manipulieren und in einen beliebigen Speicherbereich zeigen lassen kann. Es ist immer noch managed.


Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!