OOP und C# ich werd noch verrückt :-/ Form-From Kommunikation

Bassti schrieb:
> Wenn ich nicht zwischen zwei Fenstern kommunizieren kann, dann macht
> doch das ganze MDI Formatgehabe keinen Sinn?!
Klar kann man. Das Problem ist: Wenn du von zwei Unterfenstern aus das 
machst, wird der gleiche Serialport zweimal für verschiedene Dinge 
verwendet, und nichts funktioniert. Daher müsstest du zB. in jedem 
Unter-Form einen eigenen Serialport haben, oder was sonst für deine 
Anwendung Sinn macht.
> Da muss es doch noch was einfach geben?!
Übergeb halt dem Unter-Form beim Konstruktor einen Pointer auf das 
Main-Window, und darüber kannst du dann Funktionen aufrufen und ggf. auf 
Member-Veriablen zugreifen. Aber du musst eben beachten, dass mehrere 
Unter-Forms das gleichzeitig können.

Wo ist denn überhaupt das Problem?

Du könntest z.B. ein kleines Interface basteln, welches die Hauptform 
implementiert und an die Child-Forms übergibt. Über das Interface können 
diese dann auf die gewünschte Funktionalität der Parent form zugreifen.

Ist jetzt nur einer von 1.000.000 möglichen Wegen... musst halt schauen 
was in deiner Anwendung am besten passt.

Bassti schrieb:
> Ich hab vor nem Jahr schonmal C# (2008) in die Ecke
> geschmissen und schnell was in VB.net (2008) programmiert, weil das dort
> ohne weitere Handstände möglich war.

wo soll das der unterschied sein? Beides ist .net und bietet die 
gleichen funktionen. Nur die eingabe-Sprache ist unterschiedlich.

Wie hast du es denn in VB.net gemacht, und wo ist das Problem bei der 
Umsetzung zu C#?

Hi,

für was der ganze Umstand? Erzeuge ein ContainerObjekt der die Daten, 
etc. beinhaltet, leite deine Forms von der System.Windows.Forms.Form 
Klasse ab, erstelle ein Konstruktor dem du dieses ContainerObjekt 
übergeben kannst und übergebe es an beide Forms. Ich hoffe das du das 
Verstanden hast, wenn du ein Beispiel brauchst, gebe ich dir eins.

> Ich hab vor nem Jahr schonmal C# (2008) in die Ecke
> geschmissen und schnell was in VB.net (2008) programmiert, weil das dort
> ohne weitere Handstände möglich war.

Welchen Unterschied gibt es den zwischen C# und VB.NET, außer dem 
Syntaktischem und höchstens dem, dass man in C# mittels Unsafecode 
Zeiger benutzen kann? Ich habe früher auf VB.NET geschworen, heute tue 
ich es auf C#, da mir die C Syntax sehr viel besser gefällt ;).

Wieso gibts da keinen Unterschied?!

SerialPort hab ich einfach nur auf die GUI gezogen und auf public 
gesetzt

Also in VB ruf ich in dem neuen Form2 einfach Form1 so auf:

Form1.SerialPort.Write("SU")

Und das funktioniert in C# anscheinend nicht...

@Christopher C. das ist irgendwie schwer verständlich... Ich programmier 
nicht so oft unter Windows :-/
Ein Beispiel wäre schön....

@Der Weise ja das hab ich auch schon probiert. Hat aber nicht so recht 
funktioniert :-/

Die Idee ist das ich den Serialport von den Client Forms aus steuern 
kann. Öffnen,Schließen etc.
Und das was mit hilfe von delegate im Form1 Empfangen wird, soll auf die 
Childforms verteilen werden.

MfG

Basti

Bassti schrieb:
> Form1.SerialPort.Write("SU")
> Und das funktioniert in C# anscheinend nicht...

und warum nichts? Was gibt es für eine Fehlermeldung?


Ich würde es aber eh nicht so mache, was hat der ComPort mit der Gui zu 
tun? Man sollte es doch gleich richtig machem, und dafür trennt man die 
gui möglichst von der Programm logik.

Damit ist es auch einfacher einen Dienst oder ein Konsolenprogramm 
daraus zu machen.

Es gibt also meinetwegen eine Worker-Objekt. Diese steuert den ComPort. 
Die beiden Formulare bekommen dann im Kontruktor die Referenz auf das 
Worker Objekt übergeben.

Bassti schrieb:
> Form1.SerialPort.Write("SU")
Geht in C# natürlich auch, du musst halt im Form2 eine Variable namens 
"Form1" anlegen, die im Konstruktor auf das Form1 gesetzt wird, oder so.
> SerialPort hab ich einfach nur auf die GUI gezogen und auf public
> gesetzt
Dann "zieh" (waddiss dat denn für ne programmierweise O_o) es eben auf 
das Client-Form.
> Die Idee ist das ich den Serialport von den Client Forms aus steuern
> kann. Öffnen,Schließen etc.
Warum nicht direkt aus dem Main-Form?

Also gut ein Beispiel:

Hier die Form1:

1

public partial class Form1 : Windows.Windows.Forms.Form

2

{

3

    private SerialPort serialPort;

4

5

    public Form1(SerialPort serialPort) : base()

6

    {

7

       this.serialPort = serialPort;

8

    }

9

10

    ...

11

}

12

13

//Form2 genau das Gleiche:

14

public partial class Form2 : Windows.Windows.Forms.Form

15

{

16

    private SerialPort serialPort;

17

18

    public Form2(SerialPort serialPort) : base()

19

    {

20

       this.serialPort = serialPort;

21

    }

22

23

    ...

24

}

Jetzt musst du nur noch vor dem Initialisieren der Forms das SerialPort 
Objekt initialisieren und den Forms das Objekt mit dem Konstruktor 
übergeben. Also in Program.cs.
Allerdings würde ich dir die Methode von Peter II eher empfehlen.

Ich frage mich immer wieder, wieso Microsoft auf die schwachsinnige Idee 
gekommen ist, eine SerialPort-Klasse als GUI-Komponente zu designen!? 
Was ist an einem Serial-Port "Graphical"?

Dadurch werden weniger erfahrene Entwickler immer wieder davon 
abgehalten, vernünftige Software zu designen, die das MVC-Pattern 
verfolgen.

Gruß
Markus

Markus V. schrieb:
> Ich frage mich immer wieder, wieso Microsoft auf die schwachsinnige Idee
> gekommen ist, eine SerialPort-Klasse als GUI-Komponente zu designen!?
> Was ist an einem Serial-Port "Graphical"?

vermutlich habe sie es nur Borland mit Delphi nachgemacht. Leider fehlen 
mir für große programme noch die TCP-Server-Sockets. Du muss man jetzt 
von Hand programmieren - wie rückständig.

Wunderbar, der Source von Christopher C. hat funktioniert...

Ich musste nur das SerialPort noch mit new in Form1 wirklich erstellen.

Hab auf die Weise jetzt gleich das komplette Form übergeben und kann 
jetzt auf meine public erstellen Funktionen in Form1 auf Form2 
zugreifen, so wie ichs aus VB.net kannte.

Danke für die Hilfe...

MfG

Basti