Hallo,
ich habe ein USerControl auf dem der Benutzer einige Eingaben machen kann.
Diese Eingaben sollen dann genutzt werden um automatisiert später aus dem System etwas zu drucken.

Wie ich aus einer Form/UserControl eine andere Aufrufe und Werte übergebe weiß ich.
Aber wie kann ich am Ende den Drucken Button aktivieren und das geöffnete Form wieder schließen?

Danke

Gruß
Daniel

Indem du den Button public machst und die Methode PerformClick aufrufst.
Das ist aber - entschuldige bitte den Ausdruck - ganz großer Schrott und sollte unbedingt vermieden werden.

Besser ist, wenn du dafür in dem Control eine public Methode erstellst, die dann intern aufgerufen wird, wenn der Button geklickt wird. Möchte jemand von Außen drucken, ruft er einfach die Methode auf.

Eventuell ist aber auch das MVVM-Pattern die noch bessere Wahl.

Hi,
ich dachte halt immer wegen der Datenkapselung, dass man keine Methoden public machen um von außen dran zu kommen.
Deswegen habe ich das nicht gemacht.

Kannst du, dass mit dem ModelViewViewModel näher erläutern wie ich da ran gehen sollte?

Danke

Gruß
Daniel

Hallo Talemantros,

man sollte keine Felder (d.h. Membervariablen) public machen, aber Methoden und Eigenschaften stellen ja gerade die Schnittstelle einer Klasse dar (sonst könnte ja keine andere Klasse diese benutzen).

Wenn du aber eine Form nur aufrufst, damit du programmgesteuert etwas drucken kannst, wäre es nicht besser, wenn du eine eigene Logik-Klasse dafür anbietest?

Ich vermute, das Drucken hängt an der Form selber.
Am einfachsten ist es immer noch, alles in der Form darzustellen und einen Screenshot davon zu drucken.

In's Business-Layer würde ich das aber nicht legen, sondern vielleicht die Grundlogik zum Drucken.
Was am Ende gedruckt werden soll - und das ist vermutlich der eigentliche Aufwand - gehört meiner Meinung nach aber in die View-Ebene.



Was das MVVM angeht, ganz grob beschrieben:
Die View-Ebene wird in zwei Ebenen aufgesplittet: View und ViewModel
Die View hat einzig die Aufgabe darzustellen. Keine Logik, die nicht explizit zur Darstellung (z.B. Animationen) gehört.
Das ViewModel ist die Datenquelle von der View, sie bekommt die Daten von irgendwo (z.B. mehrere BusinessObjects) und bereitet sie so auf, dass die View sie direkt und ohne Aufwand nutzen kann. Im Idealfall kann die View per DataBinding ein Feld an eine Property im ViewModel binden. Oder sie nutzt die Funktionen, die das ViewModel bereit hält (z.B. Anmeldungsformular öffnen und dessen Daten empfangen).
Ziel ist es, die reine Darstellung, die schwer bis gar nicht zu testen ist, von der gut testbaren Logik zu trennen. Zusätzlich kannst du bei Bedarf die View komplett austauschen, ohne die View-Logik, die ja im ViewModel liegt, mit übertragen zu müssen. Außerdem - so empfinde ich das - trägt es viel zur Übersichtlichkeit bei, da komplexere Controls sich leicht verständlich auf zwei rund halb so große Klassen splitten lassen.
Am besten funktioniert das mit WPF, das MVVM-Pattern ist auf WPF zugeschnitten und umgekehrt, viele Features von WPF machen das ganze View-Layer auf diese Weise deutlich "schöner". Bei WPF kann man auch nur mit dem MVVM-Pattern wirklich jedes Feature effektiv ausnutzen.
Bei Forms geht das auch und ist in gewisser Hinsicht bestimmt auch besser als alles Andere, aber es ist nicht so angenehm umzusetzen.