Hallo,

Ich habe ein Hauptformular und einen als Klasse geschriebenen Controller.
Preisfrage: Wo in der Anwendung instantiiere ich den Controller ?

ism

Könnte unglückliches Design sein.
Trenne Daten (Stringliste) und optische Präsentation (Grid).

1. Liste lustig füllen, so wie es notwendig ist
2. Für das Formular mit dem Grid einen Event suchen, der beim "Hervorholen" ausgelöst wird (OnShow ???)
3. Erst beim Formularanzeigen die Daten ans Grid bilden
4. Datenbindung beim Verbergen des Formulars lösen
   Grid.datasource = null; oder so

Würde auch sinnlose Hintergrundarbeit verhindern

ism

Hallo,

eine Anfängerfrage: Ich befasse mich zur Zeit mit Fingerprintscannern, wobei es mir NICHT um eine wie auch immer geartete Anmeldung / Authentifikation an Windows geht.
Ziel ist ein Zugangskontrollsystem, bei dem registrierte Kunden "mit ihrem Finger" eintreten, bezahlen usw. können.
Mit in einer DB gespeicherten Kundendaten incl. Fingerabdrücken.
Jetzt liest man, daß das WBF quasi dazu konforme Reader ansprechen kann, und daß man damit seine eigene Anwendung stricken kann.
Geht das wirklich oder würde man doch nur bei einem Logon landen ?
Anforderungen wären in etwa:

• Aufnahme von Abdrücken und Zuordnung in einer (eigenen) Datenbank
• Verteilung von Abrücken an mehrere Scanner, wenn der Mustervergleich in den Geräten stattfindet
• oder Vergleich eines lokal gescannten Fingers mit den zantral gespeicherten Abdrücken

Und natürlich: Reicht da das API von Microsoft oder braucht man noch ein externes SDK ?
Ich weiß, hier im Forum gibt es mehrere threads zu dem Thema, die habe ich schon durch...

Gruß ism

Also ich kann auf Signaturen händeringend verzichten. Da steht oft nur pseudogeistreicher Unsinn.

Und zur Forensoftware: Never touch a running System.
Man hat sich dran gewöhnt, man ist im Forum, um zu arbeiten, man weiß, wie man wo was schnell findet, coole Features müßten schon sehr cool (sprich: nützlich) sein um die Übergangsschwierigkeiten zu rechtfertigen.
Und dann geht es ja wohl nie ganz ohne Datenverluste ab bei solchen Aktionen.

Also von mir ein klares 🙄

Gruß ism

Hallo,

die Dinge haben sich weiterentwickelt.

an Taipi88: Geht klar, deshalb mein erster Ansazu über Delegates (Nowosti() )
Ich dachte eben, Events seien genau das Mittel, das Invoke zu vermeiden.

an LaTino: Äh ja, ich bin am Verstehen. 😎

Der Artikel von Herbivore ist wirklich gut.
Man bleint dran,
ism

Nachdem ersten Versuch über eine eigene Eventklasse wurde ich von der Runtime vollgenölt, Thread A würde in Thread B (GUI) schreiben.
Fazit: Ich mußte mir eine üble Invoke-Konstruktion trotz Events besorgen.
Wo soll nun der Vorteil der Events liegen ?
Da sind Delegaten doch ein wenig einfacher zu verstehen.

Und: Zieht ein Event, der aus einem Thread etwas an der GUI drehen will, zwangsläufig ein Invoke nach sich ?

Gruß ism

Hallo,

danke, das kam mir auch schon in den Sinn.
ism

Hallo,

erstmal zwei Informationen:

1. Ich arbeite mit VS2010 unter NET4.0
2. Zu

Jede Serialportinstanz verweist dabei auf den gleichen Eventhandler DataReceived() :
Das heißt einfach nichts anderes als daß ich jedem Serialport den gleichen Datareceived-Handler zuweise. Über "sender" komme ich ja an den Absender ran.

Ist ein Datenpaket erkannt (klappt) übergebe ich die Nutzdaten in ein Hilfsobjekt und starte einen Einmal-Thread (klappt), welcher die spezifische Arbeit erledigt (klappt).

Aber jetzt kommt eine Stelle, bei der ich mich unwohl fühle:
Wie bekommt die GUI eine Rückmeldung vom Thread, sprich seinem Hilfsobjekt ?
Das Hilfsobjekt steckt in einer separat deklarierten Quelldatei und soll vom Hauptformular nichts wissen, ich will das Zeugs je vielleicht weiterverwenden.

Dazu habe ich im Hauptformular einen Delegaten und eine konkrete Instanz definiert:

        public delegate void Nowosti( string nobui);
        public void konkNowosti(string nowui)
            {
            // stelle die Nachricht irgendwo dar
            }

Weiterhin bekommt die Helferklasse den gleichen Delegaten und einen Verweis für ein Besitzer-Objekt:

        public delegate void nowo(String nachri);
        public nowo Nowohandler = null; 
        public object Elter = null;    // das wird das Hauptformular

Im Hauptthread, wo das Hilfsobjekt erstellt wird, weise ich Besitzer (Elter) und Delegat zu:

  // Ka heißt mein Hilfsobjekt
  Ka.Nowohandler = konkNowosti;
  Ka.Elter = this;

... und zum guten Schluß rufe ich im Arbeitsthread den Delegaten auf:

   Nachr = "Es hat geklappt";
   ((Form) this.Elter).Invoke(new nowo(Nowohandler),Nachr);

So, Code zur Kritik freigegeben. Der Compiler hat Ja gesagt, das Programm läuft...

Gruß ism

Hallo,

danke erstmal an alle.
Genug Stoff zum Rumprobieren.

Bis zum Punkt 4 bin ich jetzt gekommen:

public class Einheit : SerialPort
        {
        public Paket P=null;
        public string Bez="";
        public Einheit(string cname, int Baud, Parity party, int Bits, int Plength,   
                            string   _bez)
            : base (cname,Baud,party,Bits)
            {
            this.Bez = _bez;
            this.P = new Paket(Plength);
            }

        }

Diese "Einheit" besitzt ein "Paket", und im Ereignishandler kann ich das über Casting ansprechen:

 private void OnDataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
            {
            Einheit iP= ( (Einheit) sender);
            while (iP.BytesToRead > 0)
                {
                iP.P.Push(  iP.ReadByte()  );
                // Push(int) schiebt das nächste Byte in die 
                // Warteschlange des Paketes
                // hier dann Paketerkennung usw.
                }
       
            }

Bis dahin scheint es mir relativ sauberer Stil zu sein.
Die Weiterverarbeitung (bei erkanntem Paket) würde ich gerne nach dem Motto
"fire and forget" abhandeln, dazu werde ich mir aber wohl noch userdefinierte Events ansehen müssen...
ism

Hallo,

ich stecke bei folgendem Problem fest:

1. Ich möchte N Serialports erzeugen, initialisieren und starten (geht schon);
   Jede Serialportinstanz verweist dabei auf den gleichen Eventhandler DataReceived()

2. Die Daten kommen "unvorhersehbar" rein und sind byte - Werte

3. Jedem Serialport wird eine Datenstruktur mit Namen "Paket" zugeordnet; dieses "Paket" schiebt sequenziell Bytes rein (Schieberegister) und prüft nach jedem neuen Byte, ob ein Paket erkannt wurde (Anfengssequenz, Checksumme). Auch das geht.

4. Das Problem: Wie gelangen die Bytes aus dem jeweiligen Eventhandler
   KORREKT in ihr zugeordnetes Paket ?
   Ich habe so ein Programm schonmal in Delphi geschrieben und möchte nun Designsünden von vornherein vermeiden.
   Natürlich könnte ich im Tag des Serialports einen Verweis auf das zugeordnete Paket unterbringen, das kommt mir aber sehr dreckig vor...

5. Wenn 4. erledigt ist: Wie stößt ein erkanntes Paket korrekt die Weiterverarbeitung seiner selbst an ?

Ich will keinen Code sondern eher Strategien, um den Paradigmenwechsel zu NET hinzubekommen.

ism.

EDIT:

Habe gerade festgestellt, daß Serialport gar keinen tag hat.
Also entfällt auch dieser Schleichpfad...
(4.)