µ schrieb:
TobiBob schrieb:
Ich habe jetzt alle Invoke()-Aufrufe durch BeginInvoke() ersetzt.
Das ist eine Lösung. Mit den Konsequenzen die hustbaer angesprochen hat.
Nämlich dass nach der Beendigung des Abbruchcodes und nach Threadende doch noch Aufträge in der GUI ausgeführt werden können.
Und noch eine andere eher ungünstige Konsequenz, wie ich gerade festgestellt habe: (eine eher seehr ungünstige)
Wenn die Übergaben an die GUI zu viele werden, kommt sie nicht mehr hinterher und man bringt den GUI-Thread auf herrliche Weise zum Abstürzen. Das Programm läuft zwar weiter, lässt sich aber dann nur noch über den Tastmanager beenden...!
Ich muss also ne andere Lösung finden. (... s.u.)
µ schrieb:
(...) Nur falls Du im aufrufenden Thread die Ergebnisse synchron erhalten willst, ist EndInvoke gefragt. Kleine Anmerkung: Mit den Methoden BeginInvoke und EndInvoke von Delegaten, kann jede Methode asynchron ausgeführt werden.
(...)
Du kannst in einem anderen Thread einer GUI kein Control hinzufügen.
Ok. Gut zu wissen.
µ schrieb:
Bei hoher Updatefrequenz von berechneten Daten sollte man sich nach dem menschlichen Benutzer richten. (...)
Dann währe es vielleicht eine bessere Lösung, die Daten gar nicht aus dem Workthread heraus anzuzeigen, sondern über einen Timer, der alle 1 oder 1/2 Sekunde die Daten aus dem Objekt ließt und anzeigt? Ich kann bei meiner kleinen Simulation die Geschwindigkeit anpassen. Wenn man also die Daten mitverfolgen will, kann man es langsam laufen lassen. Aber wenn es zu schnell läuft, bringt eine Datenanzeige im 1ms-Takt natürlich auch nix.
@hustbaer: ja, ich weiß, was Du meinst. Könnte auch so aussehen, und das tut den Augen weh:
public partial class Form1 : Form
{
private Thread t;
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
t = new Thread(new ThreadStart(Start));
t.Start();
this.Close();
}
private void Start()
{
Thread.Sleep(100);
try
{
this.button1.BeginInvoke((MethodInvoker)delegate
{
this.button1.Text = "Bam!";
});
}
catch { } // Uuaaahh!
}
}
T_G schrieb:
Ist wahrscheinlich grundsätzlich auch besserer Stil?!
Ja. Weil man dadurch
a) "gezwungen" wird darüber nachzudenken welchen Wert die Variable haben sollte wenn der folgende Code sie nicht überschreibt und
b) man beim Lesen auch gleich sieht welchen Wert die Variable haben wird wenn sie nicht später überschrieben wird.
Vielleicht kannst du deine Loesung hier praesentieren, das nachfolgende Personen mit diesem Problem auch die Loesung bekommen. Ausserdem interessiert mich es auch
WIA scheint zum Teil sehr langsam zu sein. Kannst im Inet mal suchen gehen nach "WIA slow" und du findest einige Threads aber ohne Lösungen. Mir ist zumindest noch nie eine Lösung vor die Augen gekommen, nicht mal eine mögliche Erklärung.
Du könntest statt WIA allerdings DirectShow einsetzen. Wie man DirectShow für sowas verwendet oder wenn du gleich eine fertige Implementierung willst, dann schau dir mal Aforge.Net an.
Aforge.Net dürfte womöglich sowieso interessant sein, wenn du danach das Bild in irgendeiner Weise bearbeiten möchtest.
Grüssli
Ok, ich werd die frage zum webservice dann nochmal unter webzeugs posten.
Falls es noch probleme mit den Eventhandlern gibt, melde ich mich hier nochmal.
Hallo Jens,
das geht mit beiden GUIs (WinForms und WPF).
Bei WinForms einfach den Form.WindowState auf Maximized setzen.
Und damit sich auch die Controls entsprechend vergrößern, schau dir die Eigenschaften 'Dock' und 'Anchor' an.
Unix-Tom schrieb:
Und als Hinweis.
Nimm nicht Access (mdb) sonderen SQL Compact.
Find ich auch eine bessere Idee.
Vor allem mit dem Entity Framework [Code First] sehr angenehm.
micha7 schrieb:
Hallo,
Hellsgore schrieb:
In dem du beim SendMessage / eher PostMessage (damit deine Anwendungs nicht wartet bis dein Tastendruck wirklich gesendet wird) beim HWND das Fensterhandle des Empfangsfensters mitgibst.
Stimmt. Meine Frage bezog sich nur auf SendInput, da wird nämlich kein HWND übergeben. Hat sich aber inzwischen erledigt, siehe unten.
Ne, das geht bei SendInput und keyb_event nicht. Dort musst du tatsächlich das Fenster in den Vordergrund setzen.
Der Rest sieht doch gut aus. Sollte so funktionieren.
Gruß
Hellsgore
Ja, das gilt für alle Anwendungen. Es kann dann sein, daß sich keine Menüs mehr öffnen, falsch gezeichnet wird, etc.
Ich mußte deswegen mal eine meiner Anwendungen umschreiben, da ich eine komplexe GUI mit verschachtelten TabPages hatte und es dann bei vielen TabPages zu diesen Effekten kam -> die untergeordneten Controls habe ich dann dynamisch bei einem TabPage-Change jeweils neu erzeugt (und mir nur die Inhalte im Speicher gemerkt).
Hmmm, ich glaube ich habe das Problem gelöst... Ich habe fälschlicherweise den Event BeginEdit verwendet und der tritt auch auf, wenn der Benutzer schon nur auf das leere letzte Feld klickt.
Grüsse
Jasper
Ok. Ein Tipp:
foreach (string guid in GroupIDs)
{
ctrl.Enabled = myGroups.Contains(guid);
}
Warum wird ctrl.Enabled hier mehrfach gesetzt?
Also EIN- und DASSELBE ctrl.Enabled.
Schau mal hier hast du einen Link zum Thema Lambda-Ausdruecke, das ist das was ich dort Verwende: http://msdn.microsoft.com/de-de/library/bb397687.aspx
Wenn du deine alte Liste unveraendert lassen willst dann kannst du OrderBy benutzen. Ansonsten benutzt du Sort der Klasse List<T>
hans234 schrieb:
GPC schrieb:
Hat man nur normale statische Methoden und instanziert die Klasse nie, dann mach sie static. Ist semantisch wertvoll
Naja alle (member/methoden) sind nicht statisch.
--> Also erschließt sich in folge: wann mache ich members/methoden statisch
(dann darf ich auch die Klasse statisch machen ...)
Na ja, bei Variablen/Properties ist die Sache klar: Soll es eine Variable pro Klasse nur 1x geben und nicht einzeln für jede Instanz, dann static.
Bei Methoden ist es ein bisschen Geschmacksfrage. Gruuuuundsätzlich kann man eine Methode static machen, wenn Sie keine Instanz-Methoden/Variablen der Klasse nutzt. Allerdings sehe ich in C# von dieser Regel ab, denn auf static-Methoden kann man nur über den Typnamen zugreifen und nicht auch über einen Instanznamen, so wie in C++. Das sieht dann meistens unschön aus, wenn man einen wilden Mix aus Instanz und Typaufrufen hat.
Ich mache das nach Gefühl, wenn es static sein kann, aber nicht unbedingt muss. Like a pro :p
Achtung Edit: schon gelöst (siehe unten)
Hallo zusammen,
ich versuche gerade eine GUI für eine Schachspiel mit Windows Forms zu erstellen.
Ich bin ein ziemlicher Neuling bei bezüglich WIndows Forms.
Ich habe dann im Designer einen TableLayoutPanel auf die Form gezogen und Dock auf FIll gestellt, damit der Panel immer die ganze Form ausfüllt.
Ich habe dann 8 Zeilen und Spalten eingestellt und die Größe jeweils auf 12,5% gestellt.
Ich füge dann in jede Zelle eine PictureBox hinzu:
for(int i = 0; i < 8; ++i)
{
for(int j = 0; j < 8; ++j)
{
PictureBox pb = new PictureBox();
picturesBoxes[i, j] = pb;
pb.SizeMode = PictureBoxSizeMode.Zoom;
pb.Image = bKingImg;
Size test = pb.MaximumSize;
chessBoardLayout.Controls.Add(pb, i, j);
}
}
Das ganze funktioniert zwar, aber wenn ich die Form etwas größer mache, sind zwischen den Bildern SEHR große Abstände sichtbar.
So sieht das dann aus:
http://s7.directupload.net/images/120223/obvyodvy.png
Ich habe auch schon versucht bei der PictureBox Margin auf 0 zu setzen und auch mit verschiedenen SizeModes der PicturesBoxes rumgespielt, aber das hat auch nicht geholfen.
Wisst ihr, was da lost ist? Was kann ich da machen?
Vielen Dank schonmal für eure Hilfe!
Edit: Habs rausgefunden.
pb.Dock = DockStyle.Fill; hats behoben
