Das wäre natürlich auch mal eine Idee...
Ne, ist nix wildes. Es ist ein kleines Tool das Tastenkombis abfängt und dann ein paar Makros ausführt.
z.B.
Ich drücke CTRL+F1 dann soll er z.B. einen Text an ein Fenster schicken und daraufhin eine Taste drücken. Bei dem Tastendrücken hängts hier natürlich, wenn ich die CTRL weiter gedrückt halte.
gruß
Hellsgore
Wenn es unbedingt als string übertragen werden muss könnte man auch den XmlSerializer benutzen um das Array zu serialisieren und dann die XMLDatei übertragen
AcceptTcpClient() gibt dir immer ein neu verbundenes TcpClient Objekt zurück.
Die sind verschieden, nur der Name der Variable (client) ist gleich.
Du kannst die clients z.B. in einer Liste sammeln.
Du musst ja deine Clients eh irgendwie "halten".
Pseudo Code:
TcpClient client = serverSocket.AcceptTcpClient();
connectedClients.Add(client);
// ...
Simon
Die Frage ist ob warum du hier unbedingt eine eigene Klasse "Pair" machst, vielleicht kannst du auch die KeyValuePair<T,R> von .NET nutzen. aber das ist nur ein tip, ich weiß ja nicht was du vor hast.
Ein Nachtrag noch zum Auslösen von Events.
Man sollte immer prüfen, ob auch ein Event abonniert wurde, sonst ist die Event-Variable null und es gibt eine entsprechende Exception.
Also immer so aufrufen:
public event CalcFinish_EventHandler CalcFinish; // <- Events immer in CamelCase
protected void OnCalcFinish(EventArgs e)
{
if(CalcFinish != null)
CalcFinish(this, e);
}
Achtung:
um diese Abfrage auch noch für Multithread-Programme korrekt auszuführen, sollte man immer so vorgehen:
protected void OnCalcFinish(EventArgs e)
{
var ev = CalcFinish;
if(ev != null)
ev(this, e);
}
Sonst könnte zwischen dem Überprüfen (auf null) und des Ausführens das Event mittels '-=' schon wieder gelöscht worden sein (und dann knallt es: bumm -).
leyden schrieb:
Bedeutet das, dass ich auch C# Programme auf Linux Systemen laufen lassen kann,
wie schon von anderen geschrieben - theoretisch ja ... aber ... Mono basiert auf einem komplett anderem Quelltext ... d.h. Dein Programm kann an einigen Stellen ein anderes Verhalten zeigen - weil sich der Quelltext von Mono & .NET unterscheiden ... wenn ich nicht weis auf welchem BS mein Programm später läuft, verwende ich lieber Java
Athar schrieb:
hustbaer schrieb:
Naja der Murks ist, dass es überhaupt Items mit gleicher ItemID und unterschiedlichen Eigenschaften gibt. Behaupte ich mal.
Naja, es kann für einige Eigenschaften Sinn machen, diese nicht an die ItemID zu koppeln. Tausendmal denselben Gegenstand mit unterschiedlichen Farbtönen zu erstellen macht nicht so viel Sinn.
Man darf dann aber keine Funktionen erstellen, die eigentlich ein Item brauchen, aber nur eine ItemID als Parameter haben.
Ich meine bloss: wenn man schon sowas wie eine ItemID hat, dann macht es wohl Sinn, diese 1:1 auf Klassen zu mappen.
Wenn man dann irgendwas in verschiedenen Farben haben will, dann bekommt die Klasse halt zusätzlich Parameter oder so.
Und wenn das die Game-Enginge nicht kann, dann würde ich wirklich eher alles über die ItemID machen, anstatt hier zweigleisig Name vs. ItemID zu fahren.
Das statische Property ID kann nich aufgelöst werden, aber durch die "where" klausel, müsste es doch klar sein das es ein statische Property mit dem Name ID gibt??
public class STATICINFO
{
public static int ID { get { return 99; } }
}
public class TTT<T>
where T : STATICINFO
{
public TTT()
{
int ff= T.ID; //Fehler
}
}
als eigentlich sollte man ja doppeltes in Frameworks meiden
http://msdn.microsoft.com/de-de/library/system.drawing.systemcolors_members.aspx
ist komplett in
http://msdn.microsoft.com/de-de/library/system.drawing.knowncolor.aspx
enthalten, mogel
