• Du befindest Dich hier:
• Community
• »
• Mitglieder
• »
• Ruben
• »
• Beiträge von Ruben

Ich könnte hier zwei Aussagen zu machen:

1. Je nach Implementierung der Klasse, in der sich die Liste befindet, konnte diese nicht erfolgreich deserialisiert werden, weil dort etwas an Code vorhanden ist, was den Mechanismus zu deserialisieren beeinflusst.

Hier muss ich dem guten "MrSparkle" zustimmen.
Ohne weitere Informationen wird niemand imstande sein eine passende Lösung vorzuschlagen oder zumindest zu helfen, den richtigen Weg zu finden.

2. Ein Alternative wäre (ohne zu Wissen was in der Klasse implemtiert ist) auch mal den DataContractSerializer auszuprobieren.
Der kann auch Objekte nach XML serialisieren und umgekehrt.
Auseinandersetzen kannst man sich damit auf dieser Seite:
DataContractSerializer-Klasse

Ich denke, ich verstehe in etwa worum es geht.

Für ein sauberes Threading muss man festlegen, wie der Thread laufen soll und wie er gestoppt werden darf.

Es ist nicht ohne Weiteres möglich (es gibt schon Methoden, aber die würde ich nicht empfehlen) einen Thread zu stoppen, wenn die Methode, die ausgeführt wird selbst nicht überprüft, ob sie ihre Arbeit abbrechen muss oder weitermachen kann.

Grundsätzlich kann der Thread in deinem Fall in der Klasse myProcessor erstellt werden und über Abort beendet werden.
Denn Abbruch über Abort zu machen, wäre jedoch nicht sehr klug, da dies ungeahnte Folgen haben kann.
Zum einen wird eine ThreadAbortException im laufenden Thread ausgelöst und zum anderen kann man nicht bestimmen wo genau der Abbruch stattfinden soll.

Dann würde das wie folgt aussehen:

Class myProcessor
{
    private BlackBoxWorker bbWork;
    private bool running;
    private Thread myThread;

    public myProcessor() {
        bbWork = new BlackBoxWorker();
    }

    public void Starting() {
        myThread = new Thread(bbWork.Work);
        myThread.Start();
        running = true;
    }

    public void Stopping() {
        if (running) {
            myThread.Abort();
        }
        running = false;
    }
}

class myProcessor
{
    private BlackBoxWorker bbWork;
    private bool running;           // Wird vom Thread festgelegt; zur Prüfung ob der Thread beendet wurde
    private bool doAgain;           // Wird vom Thread beim Start festgelegt; zur Angabe, ob die Arbeit wiederholt werden soll
    private Thread myThread;

    public myProcessor() {
        bbWork = new BlackBoxWorker();
    }

    public void Starting() {
        if(running) return;

        myThread = new Thread(this.Worker);
        myThread.Start();            
    }

    private void Worker() {
        running = true;
        doAgain = true;

        while(doAgain) {
            bbWork.Work();         // This is blocking the whole Thread for some time
            Thread.Sleep(5000);
        }

        running = false;
    }


    public void Stopping() {
        if(!running) return;

        doAgain = false;
        myThread.Join();            // (optional) wartet auf den Abschluss des Threads
    }
}

class Application
{
    static void main (args)
    {
        myProcessor mP = new myProcessor();

        // doing work here ....

        // myProcessor im background starten ....
        // aber wie ?
        mP.Starting();

        // doing work here

        // myProcessor im background stopen ....
        // aber wie ?
        mP.Stopping();

    }
}

Hallo Fr3dd1,

einen Verweis hat dN!3L (dem ich das Leben einmal ziemlich schwer gemacht habe ^^) schon auf mein Thema gemacht.

Dort findet man ganz am Ende einen Link zu dem HIER.

Das Projekt heißt zwar ExcelReader, aber schreiben bzw. erstellen von Excel-Dateien im XLS-Form geht auch.
Der Entwickler dieses Projekt hat sich die Mühe gemacht, das CDFF (Compound Document File Format) über eine eigene Bibliothek anzusteuern.

Leider gibt es von Microsoft keine Bibliotheken für das alte Format (von 97 bis Office 2003). Aber der Aufbau der verschiedenen Office-Dateien ist öffentlich bekannt. Anhand dessen hat auch OpenOffice seine Bibliotheken aufgebaut.

Schau einfach mal rein in den ExcelReader.
Unter Umständen muss man den Code noch etwas anpassen, weil ich in bestimmten Situationen Fehler erhielt - aber nur geringfügig.


Gruß
Ruben

Jetzt treffe ich allmählich an die Grenzen des OleDB-Treibers denke ich ^^.

Beim Schreiben in eine Excel-Datei erhalte ich folgenden Fehler:

Das Datenbankmodul kann '[SpaltennameDerGenau65ZeichenLangIst]' nicht finden. Stellen Sie sicher, dass es sich um einen gültigen Parameter oder Alias-Namen handelt, der keine ungültigen Zeichen oder falsche Zeichensetzung enthält und dessen Name nicht zu lang ist.

Ich vermute das Problem ist klar: 65 Zeichen sind einfach zu viel für den.
Dann wohl doch binär.

SQL: ALTER TABLE [Tabelle1$] ADD Spalte2 Text;
Error: Unzulässige Operation.
Eine Ausnahme (erste Chance) des Typs "System.Data.OleDb.OleDbException" ist in System.Data.dll aufgetreten.
SQL: ALTER TABLE [Tabelle1] ADD Spalte2 Text;
Error: Tabelle/Einschränkung kann nicht gefunden werden.:
Eine Ausnahme (erste Chance) des Typs "System.Data.OleDb.OleDbException" ist in System.Data.dll aufgetreten.
SQL: ALTER TABLE Tabelle1$ ADD Spalte2 Text;
Error: Syntaxfehler in ALTER TABLE-Anweisung.
Eine Ausnahme (erste Chance) des Typs "System.Data.OleDb.OleDbException" ist in System.Data.dll aufgetreten.
SQL: ALTER TABLE Tabelle1 ADD Spalte2 Text;
Error: Tabelle/Einschränkung kann nicht gefunden werden.

EDIT: @dN!3L
Entschuldige, dN!3L.
Ich wollte keinesfalls, dass du meine Arbeit übernimmst.
Ich habe lediglich noch nicht alle Ergebnisse meiner Testläufe gepostet.
Schließlich habe die nicht die Geduld immer zu warten bis mir jemand anwortet, sondern versuche derweil selber weiter zu kommen.

Create Table Daten
(
   SPALTENNAME varchar(255)
);

INSTERT INTO Daten
VALUES
(
     WERT1, WERT2
),
(
     WERT1, WERT2
);

INSERT INTO Daten VALUES (WERT1, WERT2);
INSERT INTO Daten VALUES (WERT1, WERT2);
...

Das Semikolon ist nur hier im Beitrag ;)

Aber ich habe deinen Rat beherzigt und alle einmal durchgetestet.
Einmal HDR=Yes und dann HDR = No

ConnectionString

String.Format("Provider=Microsoft.Jet.OLEDB.4.0;Data Source={0};Persist Security Info=False;Extended Properties=\"Excel 8.0;HDR=No\"", filepath)

HDR = Yes

ALTER TABLE [Tabelle1$] ADD Spalte2 WChar(255);
Exception.Message: Syntaxfehler in Felddefinition.

ALTER TABLE [Tabelle1$] ADD Spalte2 varchar(255);
Exception.Message: Unzulässige Operation.

ALTER TABLE [Tabelle1] ADD Spalte2 varchar(255);
Exception.Message: Tabelle/Einschränkung kann nicht gefunden werden.


HDR = No

ALTER TABLE [Tabelle1$] ADD Spalte2 varchar(255);
Exception.Message: Unzulässige Operation.

ALTER TABLE [Tabelle1$] ADD F2 varchar(255);
Exception.Message: Unzulässige Operation.

ALTER TABLE [Tabelle1] ADD F2 varchar(255);
Exception.Message: Tabelle/Einschränkung kann nicht gefunden werden.

Unterstützt der JET-Treiber mit OLEDB kein ALTER TABLE oder habe ich was im Syntax falsch?

ALTER TABLE [Tabelle1$]
	CHANGE F1 Spalte1 varchar(255);
	ADD Spalte2 varchar(255);

bool b=InvokeRequired;

bool b = this.InvokeRequired;
System.Diagnostics.Debug.Print("b ist [{0}]", b);

b ist [False]

Da es nicht geeignet ist Code-Dateien hochzuladen, muss ich wohl oder übel den Platz im Forum ausnutzen ;)

Ich habe jetzt den Code so gut wie möglich gekürzt. Ich hoffe übersichtlich.

EDIT:
Es handelt sich um eine ComboBox in der Autragsnummern angezeigt werden.
AuftragComboBoxInit steht dafür, dass das Eintragen der Werte in die ComboBox initiiert werden soll.
Hoffe, dass es nachvollziehbar ist ^^

        // --------------------------------------------------------- //
		// Diese Methode befüllt die zweite ComboBox NICHT erfolgreich.
		// Alle Post-Methoden werden in einem DRITTEN Thread ausgeführt.
		// --------------------------------------------------------- //
        private void AuftragComboBoxInit(Produkt p)
        {
			// INFO: GUI-Thread ID - [1]
			System.Diagnostics.Debug.Print("START - GUI-Thread: {0}", System.Threading.Thread.CurrentThread.ManagedThreadId);
			
			// ...
			
			// Erstellen einer AsyncOperation um die Vorgänge beim Befüllen der ComboBox zu synchronisieren
            AsyncOperation asyncOp = AsyncOperationManager.CreateOperation("auftragComboBox");
			
			// ...
			
			// INFO: eine weitere annonyme Methode wird definiert ^^
            MethodInvoker m =
                delegate()
                {
					// ...

					// INFO: Die ID ist definitiv anders als die vom aufrufenden GUI-Thread - [5]
					System.Diagnostics.Debug.Print("ANFANG - Thread: {0}", System.Threading.Thread.CurrentThread.ManagedThreadId);

					// Dieses WaitHandle dient dazu, die Post-Aufrufe zu synchronisieren,
					// sonst würde die Methode schon abgelaufen sein, bevor der erste Post vom GUI-Thread verarbeitet wird.
                    System.Threading.AutoResetEvent postWait = new System.Threading.AutoResetEvent(false);

					// ...
					
                    for (int i = 0; i < number; i++)
                    {
						// ...
						
						// Post wird aufgerufen um die Daten in die ComboBox zu bringen
                        asyncOp.Post(
                            delegate(object args)
                            {
                                try
                                {
									// INFO:
									// Wenn der Wert FALSE ist, dann brauch die Aktion nicht ausgeführt werden
									//
									// IMPORTANT:
									// Hier tretet der entscheidende Fehler auf,
									// obwohl der Aufbau derselbe ist wie im ersten Durchlauf der ersten ComboBox
                                    this.cboAuftragsnummer.Items.AddRange(datenArray);
                                }
                                catch (Exception)
                                {
									// IMPORTANT:
									// Es ist eine Exception wegen eines threadübergreifenden Vorgangs aufgetreten.
									// Die ID dieses Threads ist [4]
									// (HINWEIS: [4] ist dieselbe ID wie beim Thread in "ProduktComboBoxInit()")
									// (Werden IDs also doppelt vergeben, wenn der eine Thread nicht mehr ausgeführt wird?)
                                    System.Diagnostics.Debug.Print("ERROR - Thread: {0}", System.Threading.Thread.CurrentThread.ManagedThreadId);
                                }
								
								// Signalisiert, dass der Thread seinen Vorgang fortsetzen kann.
                                postWait.Set();
                            }, null);
							
						// Thread wartet bis der Post abgeschlossen wurde.
                        postWait.WaitOne();
						
						// Kurze Pause ;)
						System.Threading.Thread.Sleep(0);
						
						// ...
                    }

                    // ...

					// OperationComplete wird mit dem letzten Post ausgeführt
                    asyncOp.PostOperationCompleted(
                        delegate(object args)
                        {
                            try
                            {
								// INFO:
								// Wenn der Wert FALSE ist, dann brauch die Aktion nicht ausgeführt werden
								//
								// IMPORTANT:
								// Hier tretet der entscheidende Fehler auf, obwohl der Aufbau derselbe ist wie in "ProduktComboBoxInit()"
                                if (lastA != null)
                                    this.cboAuftragsnummer.Items.AddRange(datenArray);
                            }
                            catch (Exception)
                            {
								// IMPORTANT: (prinzipiell dasselbe wie oben)
								// Es ist eine Exception wegen eines threadübergreifenden Vorgangs aufgetreten.
								// Die ID dieses Threads ist [4]
								// (HINWEIS: [4] ist dieselbe ID wie beim Thread in "ProduktComboBoxInit()")
								// (Werden IDs also doppelt vergeben, wenn der eine Thread nicht mehr ausgeführt wird?)
                                System.Diagnostics.Debug.Print("ERROR - Thread: {0}", System.Threading.Thread.CurrentThread.ManagedThreadId);
                            }
							
							// Signalisiert, dass der Thread seinen Vorgang fortsetzen kann.
                            postWait.Set();
                        }, null);
						
					// Thread wartet bis PostOperationCompleted abgeschlossen wurde.
                    postWait.WaitOne();
					
					// das WaitHandle wird freigegeben
					postWait.Close();
					
					// Die ID dieses Thread ist [5]
                    System.Diagnostics.Debug.Print("ENDE - Thread: {0}", System.Threading.Thread.CurrentThread.ManagedThreadId);
                };

			// Startet den asynchronen Vorgang
			m.BeginInvoke(delegate(IAsyncResult result)
			{
				m.EndInvoke(result);                    
			}, null);
			
			// ...
        }

Die Konvertierung leicht gemacht: (funktioniert sehr gut - jedenfalls C# to VB)
DeveloperFusion

Den SourceCode gibt es auch. Der ist OpenSource.
SourceCode - SharpDevelop 3.2

Hallo zusammen,

Mein System:
Windows XP - SP 2
Visual Studio 2008 Team System
.Net 3.5 - Framework
etc.

Folgende Situation:
- Eine Form hat zwei ComboBoxen.
- Beide ComboBoxen werden asynchron gefüllt.
- Aufruf der asynchronen Methoden läuft über einen Handler bzw. Delegaten
und wird über BeginInvoke gestartet.
- Um das Befüllen der ComboBoxen zu synchronisieren nutze ich AsyncOperation.
- Die asynchrone Methode für die erste ComboBox wird im Load-Event gestartet.
- Im Load-Event wird zuerst ein AsyncOperation im AsynOperationManager erzeugt.
- Das AsyncOperation-Objekt wird dann an die asynchrone Methode übergeben.
- Die erste ComboBox wird über die Post-Methode erfolgreich und asynchron gefüllt.

Das Problem:
- Die zweite ComboBox wird im Leave-Event der ersten ComboBox gefüllt.
- Beim Aufrufen der Post-Methode wird der Vorgang in einem anderen Thread ausgeführt und es wird eine Exception geworfen.
(Threadübergreifender Vorgang)

Das Prinzip bei der zweiten ComboBox ist dasselbe, aber es funktioniert igendwie nicht.
Erst dachte ich, dass die Form keine Post-Aufrufe verarbeiten kann, weil ich einen Wartepunkt im Event setze - sollte ein anderer Prozess bereits laufen -, aber die Form hat nicht gewartet bzw. diesen Punkt nicht erreicht.

EDIT:
Zur Lösung springen

Meine Problemstellung ist folgende:

Ich muss Exceldateien lediglich auslesen können, auch wenn das angegebene Office nicht installiert ist. Jedenfalls ist das schneller als die COM-Interop-Schnittstelle, die ich nur zu gerne umgehen möchte.
Bevorzugen tue ich XML in jedem Fall. Ich habe mir bereits eine angepasste Bibliothek für das generieren von XML-Exceldateien geschrieben und klappt wunderbar - nur beim Auslesen ist das nicht sonderlich hilfreich.

Ein weiterer Punkt ist, dass ich ein Programm habe, welches derzeit Excel-Dateien auf XML-Basis generiert, aber wenn ein Anwender nur Office 2000 hat, dann läuft das leider nicht und ich habe deshalb bereits Anfragen bekommen, ob sich das lösen lässt. Natürlich rate ich lieber auf die bessere Office-Version zu upgraden, aber schaden kann es nicht, wenn ich auch die Möglichkeit hätte die binären Exceldateien zu generieren.


Und vielen Dank für eure bisherigen Antworten ;)

Hallo erstamal,

also möglich ist diese Sache schon, aber ich wollte nur wissen, ob jemand schonmal irgendwo eine Bibliothek dafür gesehen hat.

Das würde mich sehr interessieren.
Hier gibt es die Dokumentation von Microsoft zu dem binären Aufbau der Excel-Dateien.

Oder wäre das eher eine Idee für ein Community-Projekt?

Im Internet bin ich bislang nur auf anderssprachige und kostenpflichtige Teile gestoßen. Bei OpenOffice schau ich noch. Da sollte es sowas eigentlich geben.

EDIT:
Mir geht es dabei um Dateien von 2003 und älter.

Genau dasselbe habe ich vor kurzem gemacht.

Unter der Verwendung des Com-Wrapper von Rainbird habe ich ein Word-Dokument geöffnet und alle Formularfelder (oder auch Mergefields) ausgelesen und ausgewertet.

Dank des Com-Wrapper läuft es sogar auf Office 2007 (habe es auf einen PC mit Office 2003 entwickelt).

Mein Vorgehen
Jedoch bin ich ohne Enumeration dadurch gegangen.
Ich habe die Document.Fields als ComObject ausgelesen.
Dann eine For-Schleife gebaut.
Als Hochwert habe ich den Wert aus Fields über den Com-Wrapper von Count genommen.
Anschließend habe ich nur die Aufrufe über Fields.Item(int index) oder Fields.get_Item(int index) gemacht. Ich würde beim Com-Wrapper beides mal probieren.

Lohnt sich nicht, habe das Problem gelöst.

Ich habe einmal vergleicht, wo der Unterschied zwischen dem Trennen der Verbindung vom Client zum Server mit dem Trennen der Verbindung vom Server zum Client liegt und habe dabei folgendes festgestellt:
Ich habe die Tickzahl jeweils für das Senden von Disconnect und das Schließen des NetworkStream genommen.
Beim Client-Disconnect gab es eine Differenz von gut 10000+ Ticks und beim Server 0 Ticks. Der Unterschied beim Client war, dass ich das Senden der Disconnect-Nachricht asynchron ausgeführt habe.

Beim Server habe ich das dann so gelöst:
Ich habe einen anonymen Delegaten als System.Threading.ThreadStart deklariert (weil ThreadStart ein einfacher Delegat ohne Parameter und ohne Rückgabewert ist) und das Senden des Disconnect über BeginInvoke (also asynchron) ausgeführt. Im eigentlichen Thread habe ich noch einen Wartepunkt benutzt und dann erst den Stream geschlossen. Und es funktioniert.

Soll ich am besten noch einen Thread als gelöst öffenen? ^^

Nur zur Ergänzung: (korrigiert mich gerne ;)

Wenn ich ein selbst definierten Timout nutzen möchte,
dazu nur kleine Datenmengen (ca. 1 - 1024 Bytes) möglichst ohne Verzögerung schicken möchte
und Verbindungsabbrüche schnell erkennen will...

...dann ist die Verwendung von Socket (gerne den von TCPClient) sinvoll.

Richtig?

Hallo Franklin,

mir fallen da folgende Möglichkeiten ein:

1. Form1 an Form2 übergeben - geringer Aufwand
Einfach einen 2. Konstruktor schreiben, der die entsprechende Form annehmen kann.
Der Konstruktor sollte so aussehen:

     public class Form2
     {
          // Standardkonsturktor nicht verändern, dient dem Designer
          public Form2()
          {
               InitializeComponent();
          }

          // Das ist der neue Konstruktor
          public Form2(Form1 form)
               : this() // damit wir der obere Konstruktor mit aufgerufen
          {
               this.form1 = form;
          }

          private Form1 form1;

          // ...
     }

     interface IForm1
     {
          string TextBox1_Text { get; set; }
          object ListBox1_DataSource { get; set; }
     }

     pubic class Form1 : IForm1
     {
          public Form1()
          {
               InitializeComponent();
          }

          // ...

          string IForm1.TextBox1_Text
          {
               get { return this.textBox1.Text; }
               set { this.textBox1.Text = value; }
          }

          object IForm1.ListBox1_DataSource
          {
               get { return this.ListBox1.DataSource; }
               set { this.ListBox1.DataSource = value; }
          }
     }

Hallo Tsuyo,

ich weiß zwar nicht, ob ich da den richtigen Ansatz habe, aber auf jeden Fall kann es helfen, wenn man sowas vermeidet:

     // nicht so
     while(nothingToDo)
          continue;

     // besser so
     while(nothingToDo)
          System.Threading.Thread.Sleep(0);

Werde ich, machen kleines_eichhoernchen. Mit Multithreading bin ich ja nicht so bewandert wie man sieht, aber ein interessantes Thema, finde ich.

Aber um auf etwas anderes zurück zu kommen...
Mit SynchronizationContext und AsyncOperation sind die Abläufe immer noch in verschiedenen Threads. Habe da etwas rumprobiert.
Bei einer Konsolenanwendung kann das durchaus egal sein. (z.B. wenn ein anderer Thread auf die Konsole schreiben will).

Aber jetzt ein Beispiel:
Ich habe eine Klasse in der über eine Methode ein Thread gestartet wird und über eine andere (sauber) beendet. Der gestartet Thread macht irgendwas (Berechnungen, Prüfungen, etc.) und wirft immer mal wieder ein Event. Das Ergebnis soll dann ausgegeben werden.
Bei einer Konsolenanwendung brauch ich nur die Klasse instanzieren und die Ergebnisse in den Event-Methoden auf der Konsole ausgeben.
In einer Formanwendung müsste ich aber jedes Event prüfen und dann über BeginInvoke oder Invoke im GUI-Thread ausführen.

Meine Frage daher:
Wie kann man eine Klasse so programmieren, dass man nie prüfen muss (wenn man die Klasse benutzt), ob das Event im richtigen Thread ausgeführt wird?
Beim BackgroundWorker kann man ein Event (ProgressChanged) auch ohne Prüfung abfangen.
Wie kann man das in einer Klasse implementieren, sodass es nicht relevant ist, ob man die Klasse in einer Konsole oder einer GUI-Anwendung nutzt?

Am besten wäre ein Codeausschnitt wie man einen Eventaufruf, in der Klasse durchführen kann, dass die angemeldeten Handler im richtigen Thread ausgeführt werden (zumindest bei GUI-Anwendungen).

das Ding heißt vielleicht so:
Visual Studio Team System 2008 Team Explorer

kann sein dass es auch anders heißt, jedenfalls irgendwas mit TeamExplorer.
Nutzen wir bei uns in der Firma auch.