Genau, so ist es;) auf basis der LinkedList, sortier ich das element beim einfügen richtig ein. da die elemente zu 99% in der richtigen reihenfolge kommen, gibt es auch keine performance probleme;)
grüße;)
Hallo Leute,
ich muss mit einem gerät via tcp/ip kommunizieren, bzw. definiert telegramme mit best. semantik und aufbau austauschen. dieses geräte fungiert bei dem datenaustausch als tcp/ip server.
nun könnte ich einen tcp/ip client schreiben, welche daten bzw. telegramme mit dem gerät austauscht, was auch kein problem darstellt. Aber damit ich auf meiner seite eine "definierte" schnittstelle habe, würde das gern mit WCF machen. was mit die möglichkeit geben sollte, dass ich das mapping/formatierung zwischen den telegrammen von dem gerät und von mir zum gerät für den WCF service implementieren müsste! aber wie geht das? wie könnte ich das anstellen? oder soll ich doch lieber auf ein regulären tcp/ip client zurückgreifen!?=
grüße
Dein gezeigter Code funktioniert wohl kaum, wie du es möchtest. Der String "Lottozahl gefunden" wird auf der Stelle angezeigt, obwohl es noch nicht der Fall ist. Zudem setzt du den String immer wieder neu, obwohl es unnötig ist.
Zudem ist auch das allgemeine Design der Klasse, ganz ehrlich gesagt, nicht so optimal. Verwende mehr lokale Variablen. Gib den Klassen, Variablen und Funktionen bessere Namen und probier einheitlich zu sein. Initialisiere Variablen am Anfang und nicht am Ende. Verwende Arrays. Verwende nicht Convert.ToString , sondern direkt ToString von IFormattable und übergib allenfalls auch eine CultureInfo .
Grüssli
Entschuldigt, dass ich mich wieder melde, aber auch hier habe die Lösung gefunden. Und zwar wählt man mehrere Einträge aus, indem man einen oberen Eintrag anclickt, die Umschalttaste drückt und dann einen unteren Eintrag wählt. Nur das Ereignis SelectedIndexChanged kann man nicht abfangen, dafür aber MouseDown und die rechte Maustaste. Tschüss ...
static schrieb:
und statischer Konstruktor?
static Methoden und Felder sollten Dir von C++ her bekannt sein.
C# unterstützt außerdem Member Initialization für Felder, deren Wert zur Compilezeit bekannt ist:
class Foo
{
int bar = 3;
static int baz = 23;
}
Ansonsten werden Felder im Konstruktor initialisiert:
class Foo
{
int bar;
static int baz;
public Foo(int parameter)
{
bar = parameter;
baz = valueFromDatabase();
}
}
Das Problem dabei: Jedes neue Foo-Objekt setzt das static Feld erneut. Das ist aber eventuell garnicht gewünscht.
Dafür gibt es den statischen Konstruktor:
class Foo
{
int bar;
static int baz;
public Foo(int parameter)
{
bar = parameter;
}
static Foo()
{
baz = valueFromDatabase();
}
}
Dabei gelten folgende Besonderheiten:
Eine Klasse darf nur maximal einen statischen Konstruktor (SK) haben.
Ein SK hat keinen Modifier (public, protected, private) und kann keine Argumente annehmen.
Ein SK wird exakt einmal ausgeführt (maximal), unabhängig davon, wieviele Foo-Objekte erstellt werden.
Sobald das erste Foo-Objekt angelegt wird, oder der erste Zugriff auf ein statisches Feld oder eine statische Methode stattfindet, wird der SK ausgeführt.
Der SK wird vor jedem anderen Konstruktor ausgeführt.
Der SK ist nicht an ein Objekt gebunden und darf demnach nicht auf nicht-statischen Felder oder Methoden zugreifen.
Ich habe in 3 Jahren einmal einen SK benötigt. Insgesamt ein völlig überflüssiges Sprachmittel
zwei änderungen hab ich vergessen zu erwähnen die mainform sieht jetzt so aus:
public partial class MainForm : System.Windows.Forms.Form
{
public MainForm()
{ ....}
....
public MEINEUSERFORM MyUserForm = new MEINEUSERFORM (MyMainForm);
static MainForm MyMainForm = new MainForm(); //hier die Änderung
....
private static MainForm transDefaultFormMainForm = null;
public static MainForm TransDefaultFormMainForm
{
get
{
if (transDefaultFormMainForm == null)
{
transDefaultFormMainForm = new MainForm();
}
return transDefaultFormMainForm;
}
}
....
public void set_textbox(string x)
{
rtbMonitor.text = x;
}
}
dadurch ist MyMainForm != Null , aber es wird wieder eine instanz der Klasse erstellt
hier noch der Start des Programms:
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.Run(new MainForm());
}
}
----
Lösung:
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
mf = new MainForm();
Application.Run(mf);
}
public static MainForm mf = null;
}
und dann in der eigenenklasse einfach sowas wie
Program.mf.set_textbox("Hallo");
danke fürs Anschaun und einen schönen Abend wünsch ich noch! Grüße Ajax
GPC schrieb:
static hat durchaus seine berechtigten Anwendungszwecke.
Ja, hat es.
GPC schrieb:
Ich würde es als Methodenmodifizierer (ja, man modifiziert eig. die Speicherklasse der Methode) sogar viel öfters verwenden - nämlich immer dann, wenn auf kein normales Member einer Klasse zugegriffen wird.
Das find ich aber sehr, sehr suboptimal. Das führt einzig und allein zu unwartbarem Code. Hab ich schon zig mal erlebt. Man benutzt oft irgendwie static, weil man meint, das ist nur eine Hilfsfunktion, braucht keine Membervariablen. Und dann nach paar Jahren ist das Programm viel größer geworden, sind etliche Anforderungen dazu gekommen, und man würde gern die "Hilfsfunktion" abhängig vom Kontext austauschen (oder man will einen Proxy haben, einen Cache, oder was weiß ich was), und siehe da, es geht nicht, ohne den halben Code umzubauen. Seh ich jeden Tag in der Arbeit.
Andreas XXL schrieb:
Ich habe mit diesem Designer in Visual Studio ein Fenster mit einem "Grid" erstellt (WPF). Nun setze ich in die Grid-Felder einige Labels um später Text anzuzeigen (Ich hoffe dies ist die richtige Vorgehensweise):
Eher nicht. Schau dir lieber zuerst C# gut an und beschäftige dich mit WPF erst, wenn du C# kannst. WPF ist ein ganzes Thema für sich und gibt daher auch ganze Bücher nur über WPF (Einstiegslektüre für erfahrene C# Programmierer).
Andreas XXL schrieb:
Ist dies die richtige Vorgehensweise, damit der Garbage-Collector den Speicher wieder freigeben kann? Oder muss ich die Labels einzeln aus dem Grid entfernen?
Oder soll man ganz anders vorgehen?
Sobald etwas nicht mehr durch irgendwelche Pfade aus dem Hauptprogramm referenziert wird, gibt es der GC automatisch irgendwann frei. Es ist sinnvoll, wenn man Bereiche zum Aufräumen freigibt, welche man nicht mehr benötigt. Es ist aber schwer die Sache hier zu beurteilen, da man keinerlei Kontextinformationen hat.
Aber von mir aus gesehen verwendest du WPF hier sowieso komplett verkehrt. Wie ich oben sagte, lass zuerst mal lieber die Finger von WPF.
Grüssli
Hallo,
nein, wird in VS 2008 nicht unterstützt, siehe:
http://social.msdn.microsoft.com/forums/en-US/vswpfdesigner/thread/7c530139-1ba1-41e2-9d0f-bb8f6762a5d4
MfG,
Probe-Nutzer
Hi, danke! Mir hat das .Where gefehlt.
In vb.net sieht es dann so aus
someList.Where(Function(someClass) someClass.someValue <> 0).Min(Function(someClass) someClass.someValue)
Wobei man das besser in 2 Schritten macht, um eine evtl. leere (gefilterte) Liste abzuhandeln.
GPC schrieb:
Aus meinen Bookmarks: http://www.simple-talk.com/content/article.aspx?article=276
So in etwa hatte ich mir das vorgestellt.
@hustbaer Ich will beides machen
Hi,
ich benötige für eine Surface-Anwendung (läuft nicht auf einem Surface-Tisch, sondern auf einem Desktop-Rechner) Touch-Events. Die Informationen welche Touch-Events zu erzeugen sind erhalte ich in Form des TUIO-Protokolls. Der Hintergrund dafür ist, das die Touches von einer Kinect erkannt werden.
Zum Erzeugen der Touch-Events habe ich eine Subklasse von TouchDevice erstellt und reagiere in dieser Klasse auf die TUIO-Events in dem ich die entsprechenden Funktionen des TouchDevice für das generieren von Touch-Events aufrufe (TouchDevice.ReportDown(), TouchDevice.ReportUp(), TouchDevice.ReportMove()).
Diese Implementierung funktioniert soweit ganz gut, allerdings bekomme ich manchmal unter Umständen die ich bis jetzt nicht weiter einschränken konnte, seltsames Verhalten seitens des Touches. Dies äußert sich darin, das Elemente zwar Touch-Events erhalten (i.e. wenn ich Listener für TouchEvents auf den zu manipulierenden Elementen registiere erhalte ich in den Listenern Events) aber das Element reagiert auf die Manipulationen die durch die Touches ausgelöst werden sollen nicht (keine Bewegung, kein Scaling bei 2-Finger-Geste).
Ich habe bereits versucht mir den Zustand des TouchDevices in beiden Fällen anzuschauen um festzustellen inwiefern ein Unterschied im TouchDevice zwischen einem funktionierendem Touch mit Manipulation und einem nicht funkionieredem Touch ohne Manipulation aussieht, aber in den Logausgaben konnte ich keinen Unterschied feststellen.
Hat vielleicht hier jemand Erfahrung mit der Materie und könnte mich auf evt. Stolperfallen bei Nutzen dieses Touch-Ansatzes hinweisen? Ich vermute, das ich unbewusst irgendetwas falsch mache und deswegen das System nicht so reagiert wie ich es erwarte. Leider ist auch die Microsoft-Dokumentation an dieser Stelle recht dürftig.
Mfg
GT
Stichwort: Multithreading
Empfehlen kann ich dafür als Einstieg den Artikel Multi-Threaded Programmierung (bzw. die PDF-Datei).
Ab .NET 4 sollte man jedoch idealerweise (und der Einfachheit wegen) mit der Task Parallel Library (TPL) arbeiten.
Wie wäre es mit PrintDocument.PrinterSettings und danach PrinterSettings.PaperSizes ?
Scheint von der Beschreibung her zu passen, was du suchst. Ansonsten hat PrinterSettings noch andere Einstellungen, welche du abrufen kannst.
Grüssli
Ok Danke. Hat sich erledigt, es hat geklappt. Man muss den Verweis noch hinzufügen. Der liegt bei COM.
Der titel wird nun auch im Explorer angezeigt. Jetzt mal sehen wie das unter Win7 aussieht.
