vb.net Problem mit dem Programmaufbau eines Config-Tools

[tantal.lpt (Gast)]

Hallo,

leider bin ich noch Anfänger was VB.net angeht und stehe vor dem Problem 
das ich nicht weiß ich ich mein Programm aufbauen soll.

zum Programm:

Es handelt sich um ein Configurationstool für eine Reihe von Geräten, 
welche über RS-232 Angesprochen werden. Die Geräte sind sich recht 
ähnlich nur von der Ausstattung unterschiedlich.
Es soll nach dem Programmstart ausgewählt werden welches Gerät am PC 
angeschlossen ist, und daraufhin die Oberfläche entsprechend angepasst 
werden. Also unterstützte Kommandos aktivieren (z.B. Button enabled) und 
nicht unterstützte Kommandos deaktivieren (z.B. Button disabled).
Außerdem haben einige Kommandos noch weitere Parameter. Diese Parameter 
sind auch von Gerät zu Gerät unterschiedlich (z.B. Gerät1 Output_Power 
0.1 - 1.0Watt und Gerät2 0.1 - 5.0Watt). Ich möchte also gern für 
entsprechende Gerät auch NUR die passenden Kommandoparameter in eine 
Auswahl (z.B. Combobox) laden.

Die Geräte sind noch in der Entwicklung, also können noch Befehle 
und/oder Parameter hinzukommen. Zudem wird in der Zukunft die 
Gerätereihe noch vergrößert und ich müsste das Tool entsprechend 
anpassen. Daher ist es mir wichtig eine gute Strukturierung zu haben, 
wodurch ich später leicht Befehle und Parameter 
hinzufügen/entfernen/ändern kann. Z.B. Gerät1 unterstüzt jetzt einen 
weiteren Befehl, den vorher nur Gerät2 unterstüzte.

Kann mir da einen n Tipp geben, wie ich sowas geschickt aufbauen kann? 
Was für Klassen ich erstellen sollte und was sie beinhalten? Also eine 
grobe Strukturierung.

Gruß
Mathias

[Bolek (Gast)]

Ich würde da net geizen und für jedes Gerät eine eigne .dll schreiben, 
auch wenn die Befehle redundant sind. copy and paste tut da net weh und 
erst recht nicht wenn sich jedes Gerät individuell verändern könnte. Die 
.dlls lassen sich dann auch in jedes weitere Programm einbinden, was die 
Geschichte im nachhinein angenhemer machen würde.

[Ralf (Gast)]

> copy and paste tut da net weh und erst recht nicht wenn sich jedes Gerät
> individuell verändern könnte.
Aber wie das weh tut, vor allem dann wenn's 20 Geräte sind und sich 15 
Sachen geändert haben.
Ich würde deine Idee dahingehend modifizieren dass es eine DLL mit den 
Befehlen gibt und in den Geräte-DLLs wird auf die Befehle verwiesen.
Hat beispielsweise den Vorteil, dass nur ein einer DLL der Befehl 
geändert werden und danach neu compiliert werden muss.

Ob OOP der passende Ansatz ist um die Geräte abbilden zu können musst du 
selbst entscheiden.

Ralf

[anon (Gast)]

Und ich hätte jetzt ganz einfach gesagt, dass du dir eine abstrakte 
klasse bastelst mit den ganzen Eigenschaften die so ein gerät potenziell 
hat und passende getter und setter. (Bool hasFeatureX, double 
powerOutMax, ..)

Jede Geräteart erbt von der klasse und setzt dabei die Eigenschaften so 
wie Sie eben für das gerät passen. Du kannst dann evtl. Auch in dieser 
klasse noch Attribute für die aktuelle einstellungsauswahl des Nutzers 
hinzufügen.

Deine GUI bekommt dann einfach eine Instanz der abstrakten klasse und 
kann über die getter die unpassenden Buttons ausgrauen und so.

Ob du die abstrakte klasse und ihre Implementierungen in eine dll 
packst, ist eig. Nur wichtig, wenn du diese auch für ein anderes Projekt 
brauchen kannst. Compilieren dauert ja unter vb.Net vermutlich ähnlich 
kurz wie bei c#.

sorry für die schreibweise ,ist auf meinem Handy getippt.

[tantal.lpt (Gast)]

Hallo,

erst einmal vielen Dank für eure Anregungen. Wie gesagt bin noch recht 
frisch in dem Gebiet. Eine .dll hab ich noch nie erstellt und möchte da 
auch erst mal die Finger von lassen. Es geht momentan auch nur um 2 
Unterschiedliche Geräte und es kommen noch max. 2 hinzu.

Der Vorschlag von "anon" gefällt mir soweit ganz gut ... hatte auch 
selbst schon in diese Richtung gedacht. Nur hapert es etwas an der 
Umsetzung ...

könnte mir da vielleicht Jemand mit nem Beispiel auf die sprünge helfen?

als Beispiel:

Gerät1 :
hat die Befehlte "set_Out_Power" mit den Parametern  "0.1 ; 0.5 ; 1.0 ; 
2.0 ; 5.0",
den Befehl "set_duty_cycle" mit den Parametern "10% ; 50% ; 100%"
und den Befehl "Output_ON/OFF" mit den Parametern "true, false".

Gerät2 :
hat ebenfalls den Befehl "set_Out_Power" jedoch mit den Parametern  "0.1 
; 0.2 ; 0.3 ; 0.4 ; 0.5"
und den Befehl "set_duty_cycle" mit den Parametern "10% ; 50% ; 100%".
Der Befehl "Output_ON/OFF" wird nicht unterstüzt.


Ich benötige also 2 ComboBox für "Out Power" und "duty cycle" sowie eine 
CheckBox für "ON/OFF". diese Müssen dann je nach Auswahl angepasst 
werden.


Ich habe mir bis jetzt erst ein paar Enums erstellt für die Parameter 
(in Rohform) die zum Gerät gesendet werden sollen:

    Public Enum commands As byte
        set_duty_cycle = &hf1
        set_Out_Power = &hf2
        set_Out_ONOFF = &hf3
    End Enum


    Public Enum Out_Power As Short
        mW_50 = 50
        mW_100 = 100
        mW_150 = 150
        mW_200 = 200
        mW_250 = 250
        .
        .
        .
    End Enum


    Public Enum OUT_ON_OFF As byte
        Power_ON = &hff
        Power_OFF = &h0
    End Enum


    Public Enum duty_cycle As byte
        dc10 = &h1
        dc50 = &h5
        dc100 = &ha
    End Enum




gruß
Mathias

[Karl H. (kbuchegg)]

Mein Tip:
rede mit deinem Projektmanager, wie er sich das vorstellt und entwickle 
mit ihm gemeinsam ein Konzept!

So ein Konfigurationstool steht ja nicht im luftleeren Raum, sondern 
wird von jemanden benutzt. Und mit dem musst du reden!

Der für dich zuständige wird dir ein paar Brocken hingeworfen haben, 
damit du dir erst mal Gedanken darüber machst. Das schlimmste was du 
jetzt tun kannst, ist es, aus Scham dir eine Blösse zu geben, nicht mit 
ihm zu reden und ihn mit Fragen zu löchern. Wenn du das im stillen 
Kämmerlein machst (und hoffst hier mit dem Forum eine vernünftige Lösung 
hinzukriegen) dann prophezeihe ich dir jetzt schon eine Version 2.0, die 
praktisch wieder bei 0 anfängt.

[tantal.lpt (Gast)]

Hi,

ich kann jetzt hier schlecht erklären wie es dazu gekommen ist, das ICH 
dieses tool schreiben soll. Fest steht nur, das es nur intern zu 
testzwecken genuzt wird, damit nich immer die config über ein Terminal 
per Tastatur eingegeben werden muss.

Ich könnte es auch als "quick and dirty" -Lösung realisieren und einfach 
alles mit copy and paste für jedes gerät alles neu laden ... so viele 
Geräte und Befehle sind es ja auch nicht.
Mir geht es hier eher um den Lerneffekt wie man so etwas ordentlich, 
praktisch und übersichtlich aufbauen kann. Zumindest für meine 
verhältnisse :-)

Gruß
Mathias

[Karl H. (kbuchegg)]

Mein Ansatz wäre

Es gibt ein Gerät. Das ist erst mal eine Klasse für sich (ob Vererbung 
da Sinn macht, kann ich nicht entscheiden).

In deiner Datenbasis gibt es eine Reihe derartiger Geräte. (Liste, 
Array, wie auch immer)

Jedes Gerät hat eine Beschreibung. Da ist sein Name, Typbezeichnung, und 
ein Kommentarfeld für sonstige textuelle Information ist auch immer gut.

Jedes Gerät unterstützt aber auch eine Reihe von Aktionen.

So eine Aktion hat ihrerseits einen Namen (damit man später in der GUI 
einen Text zum Anzeigen hat), ist von einem bestimmten Typ und verfügt 
ebenfalls über ein Kommentarfeld (den man zb für Hilfetexte benutzen 
kann)

Welche konkreten Aktionen gibt es
* einfach ein Kommando zum Gerät schicken, ohne dass der Benutzer
  weiteres einstellen muss (vulgo: ein "Befehl")
* Benutzer kann aus mehreren möglichen Möglichkeiten auswählen
  und seine Auswahl wird an das Gerät übertragen (vulgo: eine "Option")

------
Soweit so gut.
Damit ergibt sich für mich (in angelehnter C++ Notation, VB müsste ich 
mich erst wieder einlesen) eine erste Klassenstruktur

class Action
{

   string Name;
   string Comment;
};

class OperationAction : public Action
{

   string Command;   // Text der für diese Aktion zum Gerät zu schicken ist
};

class Option
{
   string Name;      // wie heißt diese Option (kriegt der Benutzer zu sehen)
   string Command;   // Text, der für diese Option zum Gerät zu schicken ist
};

class OptionAction : public Action
{
   string Name;
   string CommandPreamble;  // Einleitungstext
   list<Option> Options;
   string Comment;
};

class Device
{
  string Name;
  string Comment;
  list<Action> Actions;
};

class Database
{
  list<Device> Devices;
}

Das Programm ist 2-geteilt.
Zum einen braucht es einen Teil, mit dem es möglich ist Geräte anzulegen 
und die Beschreibungen zu verändern. Das könnte zb eine klassische 
Oberfläche sein, in der die Dinge in List Controls aufgeführt sind, mit 
Editormöglichkeiten.

Zum anderen benötigt man eine Ausführungseinheit (kann auch ein eigenes 
Programm sein), welches sich die Beschreibung eines bestimmten Gerätes 
holt und daraus dann die Oberfläche generiert. OperationAction Objekte 
werden in Form von Buttons abgebildet (die dynamisch erzeugt werden), 
OptionAction Objekte werden in Form von Combo Boxen abgebildet (die 
natürlich ebenfalls dynamisch erzeugt werden).

Wie jetzt die jeweiligen Bedienelemente im Formular angeordnet werden, 
darüber müsste man reden. Es spricht ja nichts dagegen, dass man bei den 
jeweiligen Action Objekten auch noch zb Positionsangaben mitspeichert 
und es zb einen graphischen Editor gibt (als Teil des ersten 
Programmteiles) mit dem derjenige, der die Beschreibung erstellt, die 
Elemente anordnet. Vielleicht gibt es auch noch 'Action' die nicht ans 
Gerät geschickt werden, und die reine GUI Elemente darstellen, wie zb 
Fixtexte oder Bilder und nur dazu dienen, die Oberfläche besser zu 
gestalten.


Aber um Himmels Willen: rede mit deinem Projektleiter!

[Karl H. (kbuchegg)]

tantal.lpt schrieb:

> Ich könnte es auch als "quick and dirty" -Lösung realisieren

Da eure Geräte anscheinend konfiguriert werden, indem man ihnen 
Kommandos in Textform schickt, wäre eine Quick&Dirty Lösung, einfach die 
Konfiguration in Textform in eine Datei zu schreiben und auf Anforderung 
holt sich ein Tool diese Datei und überträgt den kompletten Dateiinhalt 
an das Gerät.
Für jeden Gerätetyp gibt es ein Subverzeichnis, in dem sich die Sammlung 
der Dateien befindet.

Was dann auch immer in diesen Dateien drinnen steht.
Das kann eine komplette Konfiguration sein, dass kann aber auch eine 
Konfiguration in Bezug auf einen Teilaspekt sein.

Das Tool bietet mir dann einfach eine Liste der relevanten Dateien an 
(mit einem Erklärungstext, der vielleicht ebenfalls in der Datei steht) 
und auf Knopfdrück jagt es den Dateiinhalt (ohne den Erklärungstext) an 
das Gerät raus.

[Karl H. (kbuchegg)]

Wenn du deine Datenbasis zb mit XML aufbaust, dann wäre der erste 
Programmteil zb etwas, wofür man nicht gleich ein eigenes Programm 
benötigt. Ändert sich die Datenbasis nicht allzuoft, dann kann man XML 
durchaus auch ganz einfach mit einem Texteditor bearbeiten. Es gibt aber 
auch Editoren, die mit einer zusätzlichen Beschreibung XML Files 
editieren können, ohne das der Bediener etwas von XML verstehen muss
(zb 
http://www.altova.com/de/produkte/authentic/xml_db_formular_editor.html

Damit wäre der erste Teil schon mal ganz gut abgedeckt und du musst dich 
nur um den 2.ten Teil kümmern, der aus der XML Beschreibung dann die 
Oberfläche zur Laufzeit erzeugt mit der dann dein Benutzer tatsächlich 
arbeitet.
Wobei XML hier wiederrum den Vorteil hat, dass VB komplette Klassen 
dafür mitbringt. D.h. du musst überhaupt keine Klassenstruktur erfinden, 
sondern lässt dir von den vorhandenen XML Klassen die Beschreibung 
einlesen (DOM-Modell) und arbeitest dann direkt damit.

In eine ähnliche Kerbe schlagen Lösungen, die zb auf einer Datenbank 
aufsetzen. Auch da stellt dir der Datenbankhersteller Werkzeuge zur 
Verfügung, mit der du einfach Formulare zur Pflege der Datenbank 
erstellen kannst. Der Zugriff auf die Datenbank ist dafür etwas 
komplizierter, dafür kannst du aber eine Datenbank wieder einfacher 
zentral pflegen.

Auch die DLL Lösung von weiter oben ist nicht von der Hand zu weisen, 
hat aber den Nachteil, dass man bei Erweiterungen oder Änderungen immer 
einen Programmierer braucht, während die anderen Lösungen komplett 
datengetrieben sind. Im Prinzip könnte jede Sekretärin ein neues Gerät 
damit anlegen.

Möglichkeiten gibt es viele. Aber mit jeder Entscheidung, die du jetzt 
triffst, musst du jahrelang leben. Daher sollte diese Entscheidung 
besser eine gute sein! Und da du noch nicht über die Erfahrung verfügst 
abzuschätzen, welche Auswirkungen eine Entscheidung auch in Zukunft mal 
haben wird/kann, musst du mit jemandem reden, der das kann und der auch 
in der Lage ist die weitere Entwicklung (sowohl technologisch als auch 
strategisch) innerhalb eurer Firma abzuschätzen (zb auch was mit diesen 
Konfigurationsdaten noch alles gemacht werden könnte). Das kann ich von 
hier aus nicht, ich kann dir nur Möglichkeiten aufzeigen.

[tantal.lpt (Gast)]

Hallo,

danke für deine Hilfe! Ich möchte noch mal kurz anmerken, das es mir da 
nur um den Lernprozess geht. Das tool verlässt die Firma nicht und wird 
auch nur während der Entwicklung als kleines Hilfsmittel zur schnellen 
Koniguration verwendet.

Da ich mich mit .xml und .dll absolut gar nicht auskenne, würd ich es 
gern ohne lösen.

Es soll ja kein Meisterstück werden ... ich möchte nur mit etwas mehr 
Struktur an die Sache herangehen um mir nach und nach einen einigermaßen 
ordentlichen Programmierstiel anzueignen.

Mir währe mit einem kleienen Beispiel in vb.net sehr geholfen. Bitte 
nicht zu kompliziert! Wie gesagt, bin noch Anfänger und habe bis jetzt 
nur ganz ganz kleine Ein-Fenster Anwendungen in vb geschrieben.

Gruß
Mathias