Laden...

TcpClient bringt WindowsForm zum Absturz

Erstellt von JDizzle vor 18 Jahren Letzter Beitrag vor 18 Jahren 1.699 Views
J
JDizzle Themenstarter:in
15 Beiträge seit 2005
vor 18 Jahren
TcpClient bringt WindowsForm zum Absturz

Hi,

folgendes Problem. Ich hab möchte eine Tcp-Verbindung zwischen einem Server und einem mobilen Client herstellen.

Gut, Remoting fällt beim mobilen Client leider weg. (Es sei denn irgendwer hat mittlerweile eine Lösung gefunden, wie man Remoting mit dem CompactFramework realisieren kann^^).
Jetzt wollte ich das entweder über TcpClient realisieren (wäre mir persönlich lieber, weil einfacher) oder über Sockets.

Wenn ich das Ganze als 2 Konsolenanwendungen(eine für Server, eine für Client) laufen lasse, funktionierts prima. Aber sobald ich das in eine Windowsform packe stürzt der immer ab. Das einzige was ich ändere ist, dass die Ausgabe nicht mehr auf der Console stattfindet, sondern in einer Textbox. Aber daran kanns wohl kaum liegen.

Ich krieg blöderweise auch keine Fehlermeldung. Form stürzt einfach sang- und klanglos ab. X(

4.221 Beiträge seit 2005
vor 18 Jahren

Sind mehrere Threads im Einsatz ?

Wenn ja sind die Zugriffe auf den UI-Thread mit Invoke gelöst ?

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

S
8.746 Beiträge seit 2005
vor 18 Jahren

Warum benutzt du nicht einfach Web Services?

Das ist genau für deinen Anwendungszweck gedacht. Und es gibt Beispiele wie Sand am Meer.

S
8.746 Beiträge seit 2005
vor 18 Jahren

Original von Programmierhans
Wenn ja sind die Zugriffe auf den UI-Thread mit Invoke gelöst ?

Du wirst lachen (oder weinen), es gibt kein Control.Invoke() im CF....

Dummerweise braucht man es aus den gleichen Gründen wie im normalen CF. Bleibt nur der Umweg über WindowsMessages (würg!). D.h. das ganze Invoking() muss per Hand implementiert werden.....

Zum Glück gibt hat sich schon mal jemand die Mühe gemacht und das ganze in einer Invoker-Klasse gekapselt hat....

Manchmal hat man echt das Gefühl, das ganze CF ist nur schnell-schnell zusammengefrickelt. Es fehlen so essentielle Bestandteile dass es schon fast schmerzt....

4.221 Beiträge seit 2005
vor 18 Jahren

Ich hab auch erst kürzlich mein erstes Mobile-Teil geschrieben....

Und funzt recht gut mit WebServices

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

J
JDizzle Themenstarter:in
15 Beiträge seit 2005
vor 18 Jahren

wegen Threads weiß ich jetzt gar nicht. Hab mich beim TcpClient/Listener an die Vorgaben aus der MSDN gehalten

TcpClient
TcpListener

brauch ich für Web-Services nicht einen Webserver?

H
63 Beiträge seit 2005
vor 18 Jahren

öööhm,

ich vermute mal, wenn Du noch nichts mit Threading am Hut hattest, das Dein CLient perfekt funktioniert !!

Grund: Der Listener lauscht und lauscht - und wegen: ohne Threading - hat die MainForm in der Lauschphase mal eine Sendepause - d.h. Dein PRogramm tut nur so, als wenn es tot ist....

Lösung: Trenne die UI von der Logik ab und starte den Client als Thread aus der Mainform heraus.
Dann kannst Du jederzeit den Thread aus der MainForm beeinflussen (beenden, Parameter ändern....) und die MainForm arbeitet auch, wenn der Client arbeitet.....

Näheres in der Hilfe unter Thread.Start

Warum so einfach, wenn's auch kompliziert geht !

S
8.746 Beiträge seit 2005
vor 18 Jahren

Die Beispiele, an denen du dich orientiert hast, sind Consolen-Beispiele. Da hast du keine Multi-Threading-Problem. Bei einer Windows-Anwendungen musst man sowas immer asynchron, d.h. mit Hilfe von Threads machen, weil sonst die Oberfläche einfriert.

Herons Hinweis wird also vermutlich in die richtige Richtung führen.

S
8.746 Beiträge seit 2005
vor 18 Jahren

Noch eine Frage: Wie hast du eigentlich eine Consolenanwendung auf einem mobilen Client hinbekommen?

S
8.746 Beiträge seit 2005
vor 18 Jahren

Sorry, Korrektur, Form.Invoke() gibts natürlich im CF, aber leider kein BeginInvoke(), welches man vermutlich auch hier eher einsetzen sollte.

Abhilfe: http://www.jwhedgehog.com/Samples/UISafeInvoker.zip

H
63 Beiträge seit 2005
vor 18 Jahren

?? Hä?? das hat doch mit dem Problem überhaupt nix zu tun ??

er hat 2 Konsolenanwendungen: Test
dann: er macht aus einer eine WinApp: Fehler...

ich mach das genauso: bevor ich an CE gehe, teste ich die prinzipielle Vorgehensweise mit 2 Winapps. Das spart zumindest mal ein ganzen Haufen Arbeit! Und spätestens wenn Dir einmal die Zeit zum Release gefehlt hat, machst Du es!

Warum so einfach, wenn's auch kompliziert geht !

S
8.746 Beiträge seit 2005
vor 18 Jahren

Wenn du Ereignisse aus einem Thread (in diesem Fall dein TCPListener) empfängst und an die Oberfläche leiten willst (z.B. empfangene Bytes oder so), dann musst du es in den GUI-Thread einschiessen, also mit Invoke() oder BeginInvoke(). Ersteres scheidet aus, weil es den Empfänger-Thread blockiert, was vermutlich eher unerwünscht ist. Also muss du BeginInvoke() einsetzen und das gibt es eben nicht unter CF. Da kommst du mit deiner Window-App und sagst: Äh... wie jetzt? Wenn du nicht auf den UISafeInvoker zurückgreifst dann fängst du an mit WindowsMessages und unsichtbaren MessageForms als MessageHandler rumzuhantieren.

Mein Posting bezog sich also auf deine Anregung hinsichtlich der Threading-Problematik und wie sie im CF umzusetzen ist.

Du Idee erst unter normalen .NET zu entwickeln und dann "nur noch" auf CF zu portieren funktioniert aus diesem und aus vielen anderen Gründen nicht. Wenn man keinen Plan hat - wie z.B. das mit dem TCP unter .NET überhaupt geht - ist das natürlich völlig in Ordnung. Funktionale Prototypen bauen sich natürlich auf dem PC eifnacher als in der mobilen Umgebung.

Als Entwicklungsmethodik für mobile Anwendungen kann ich jedoch nur davon abraten. habe nämlich genau das gerade gemacht und von meinen erhofften 90% Wiederverwendung blieb letztlich nur 50% übrig (rein fachlicher Code).

Von der Oberflächenentwicklung ganz zu schweigen... da kannst du gar nichst wiederverwenden.

Bei solchen Projekten gilt also: Beide Plattformen gut kennen und bei der Architektur sorgsam sein um möglichst viel dynamisieren (Adaptoren, Strategien) um fehlende Features (z.B. Serialisierung) alternativ lösen zu können ohne in unterschiedliche Implementierungsstränge abzudriften.