Bubble

Ich bastel daran bestimmt nicht ewig, so viele Seiteneffekte sind es gar nicht. Insbesondere in diesem Anwendungsfall, denn das GUI soll während der Verarbeitungsphase scheinbar gar keine Eingaben annehmen. Da reicht ein einzelner Thread im Prinzip aus. Und auch die Verwendung mehrerer Threads befreit einen auch nicht automatisch von allen möglichen Problemen.

Die Funktion erfüllt ihren Zweck. Das eventuelle Seiteneffekte (z.B. durch Benutzer-Interaktion mit dem Form) zu berücksichten und abzufangen sind, versteht sich von selbst.

Dir Priorität des Prozesses, bzw. des ausführenden Threads muss herabgesezt werden, wenn das Programm andere (wichtigere) Programme möglichst wenig beinflussen soll. Wenn der PC aber im Moment ohnehin nichts macht, ist aber auch eine hohe CPU Auslastung unproblematisch. Die Anwendung in zwei Threads aufzuteilen ist zwar möglich, hat aber andere Schwierigkeiten, da GUI Elemente immer vom GUI Thread aus verändert werden müssen. Wenn die GUI nicht für normale Interaktionen, sondern eher als Statusanzeige, gebraucht wird, würde ich der Einfachheit halber darauf verzichten. Begründung (für diesen Anwndungsfall)?

Die Window Messages müssen verarbeitet werden. Wenn der GUI Thread lange beschäftigt ist, muss dies manuell veranlasst werden.

Den unterstützen Befehlssatz kann man auch anders herausfinden. Gute Programme überprüfen dies zusätzlich zur Laufzeit. Wer den Installer in einem Kompatibilitätsmodus ausführt, der eine andere OS-Version zurückgibt, bekommt eben eine Warnung. Wo ist das Problem? Warum verwendest Du eigentlich nicht den Windows Installer, sondern programmierst einen eigenen Installer?

Das ist einfach: Mit der Zeile System.out.println("###Kontoname: " + name[i]+" = ###Kontostand: "+betrag[i]+"euro ###Kontonummer = " + nummer[i]); werden nur die Felder mit dem Index i, der noch den bei der letzten Eingabe verwendetet Wert hat, ausgegeben. Wenn alle ausgegeben werden sollen, dann muss dies in einer Schleife passieren. Außerdem muss mitgezählt werden, wie viele Eingaben getätigt wurden. Ein anders Problem des Programmes ist, dass nach maximal 10 Eingaben nicht abgebrochen wird, danach jedoch die angelegte Feldgröße überschritten ist.

Erstmal beginnt die Nummerierung von Array-Elementen mit der 0. Folglich hat der 2. Eintrag den Index 1. Einem Array-Eintrag die NULL-Pointer-Konstante zuzuweisen, sofern der Typ der Array-Elemente dies überhaupt zulässt, bringt Dich nicht weiter. Dadurch verschwindet kein Eintrag, sondern nur der Inhalt wird verändert. Wenn häufig Elemente einer Liste mittendrin gelöscht oder hinzugefügt werden sollen, sind Arrays ohnehin keine optimale Wahl.

Warum hast Du nicht probiert, was ich geschrieben habe? Und zwar die if-Abfrage durch if((_listenerThread.ThreadState & (System.Threading.ThreadState.Unstarted | System.Threading.ThreadState.Stopped)) == 0) zu ersetzen? Ich frage mich, warum ich überhaupt versucht habe, zu helfen, wenn ich ignoriert werde.

Erstmal, um welche ThreadState Enumeration geht es hier? Es gibt zwei. Es wäre immer hilfreich, ein komplettes Beispiel zu posten und nicht nur einen kleinen Ausschnitt. Ansonsten mache ich mal die Vermutung, dass es sich um die Enumeration aus System.Threading handelt: Schreibe z.B. if(_listenerThread.ThreadState & (System.Threading.ThreadState.Unstarted | System.Threading.ThreadState.Stopped) == 0) { // ... } und probiere es erneut. Gegebenenfalls könnte man noch auf ThreadState.Aborted testen, je nachdem wie der Thread eingesetzt wird.

Ab Windows Vista ist Robocopy dabei.

Grundsätzlich kann man das schon, es hat aber bei der Verwendung mehrerer compilation units Grenzen, da später beim Zusammenfügen dieser keine Namenskollisionen auftreten dürfen. Wenn er man etwas per #include einbindet, dann ist dies nach dem Präprozessorlauf Teil der Datei. Um zukünftig anderen Problemen vorzubeugen, sollte die Funktion jedoch in eine eigene compilation unit ausgelagert werden und in anderen compilation units nur eine Deklaration der Funktion vorhanden sein. Diese Deklaration(en) kann man in eine Header-Datei schreiben und per #include einbinden. So kann man das nicht sehen, #include braucht man auch, wenn man nicht objektorientiert programmiert.

Das ist jetzt sehr allgemein. Meistens wird so etwas zusammen mit speziellen Anwendungen eingesetzt, die diese Eingabegeräte bzw. Displaygeräte unterstützen.

Die Frage ist doch, was damit gemacht werden soll. (Um welches Anwendungsgebiet es geht.)

Die Folien gehören schon dadurch zusammen, dass sie Teil des gleichen Vortrags sind. Und Texte, die von hinteren Sitzreihen aus nicht mehr lesbar sind, sollten unbedingt vermieden werden oder, wenn es ausnahmsweise nicht größer geht, bei Bedarf vorgelesen werden. (Wenn die Projektion riesig ist und alle Zuhörer auf vorderen Plätzen sitzen, erübrigt sich ein Vorlesen natürlich.)

Nun, Du hast in Beitrag #13 einem Rat aus Beitrag #9 mit sehr deutlich zugestimmt. In Beitrag #20 stand dann hingegen, dass es eine sachliche Präsentation technischer Fakten und kein Marketing-Auftritt sein soll. Informationen, wie Name des Vortragenden, Bezeichnung des Unternehmens, das Datum, usw., auf jeder Folie unterzubringen, ist redundant. Es sei denn, es ist gewollt, das sich der Zuhörer dies möglicherweise mehr als alles andere einprägt (Werbung). Diese Dinge verbrauchen Platz, der für mehr sinnvollen Inhalt oder eine größere, klarere Darstellung des Vorhandenen oft besser genutzt wäre.

Zu welchem Zweck Du das tun willst, hast Du noch nicht gesagt. Möglicherweise gibt es für das eigentliche Problem ja eine deutlich elegantere Lösung, denn Prozesse einfach zu beenden ist keine besonders gute Variante.

Wenn Du einzelne eigene Prozesse beenden möchtest, dann baue in sie einen Mechanismus ein, mit dem Du dies an sie kommunizieren kannst.

Und wie passt dazu die Empfehlung, beispielsweise aufgrund von Redundanzen überflüssige Informationen trotzdem auf jede Folie mit aufzunehmen? Das wäre doch nur dann sinnvoll, wenn sich dies aus Werbegründen beim Zuhörer möglichst einprägen soll. Hier widerspricht sich einiges.

Schon mal bei der Post selbst angefragt?

Wenn irgendeine beliebige Form ausreicht und der Ursprung innerhalb der Polygonfläche liegt, kann man natürlich so etwas machen. Ich frage mich aber, ob hinter der Frage nicht vielleicht doch eine etwas andere Problemstellung steckt, die nicht mitgeteilt wurde.

Was ist mit Polygonen, die im Inneren ein oder mehrere Einbuchtungen haben? Beispielsweise welche, die eine U-Form oder eine Schneckenform haben?

Bevor mehrere Threads bemüht werden, wäre es besser, das verwendete Sucherverfahren durch ein schneller arbeitendens auszutauschen.

Das ist auch das vom Fragesteller gewünschte Verhalten: Er will z.B. auf ALT+T reagieren und nicht auf CTRL+ALT+T.

Dieses Property kann man auch auswerten, allerdings würde, wenn man nur dieses eine Property (in dem Beispiel oben e.Alt) auf wahr prüft, auch eine Kombination von z.B. CTRL+ALT+A die if-Bedingung erfüllen. Um das zu verhindern, müsste man noch weitere Properties wie Control und Shift auswerten. In meinem Beispiel hingegen würde nur auf ALT+A reagiert werden. Was ist mit diesem Satz gemeint?

Natürlich habe ich recht. Eine Variable kann zu einem Zeitpunkt immer nur einen Wert haben. Ihr macht den Fehler, ALT wie eine Taste und nicht wie einen Modifier zu behandeln. Wenn die Form (und kein anderes Control) den Focus hat, dann kann man z.B. auf ALT+A so prüfen: private void Form2_KeyDown(object sender, KeyEventArgs e) { if (e.KeyCode == Keys.A && e.Modifiers == Keys.Alt) { System.Windows.Forms.MessageBox.Show("ALT+A (KeyDown event)"); } }