Protokoll Projektgruppentreffen 18.07.2002
============================================
Protokollant: Guenther Reinecker

Tagesordnung:
--------------
0. Anmerkungen zu den letzten beiden Protokollen,
   Protokollant bestimmen, nächster Termin

1. Subsystem "Detektoren"
   (PPT-Vortrag von Alexander Paschold, Rene Harder)
   - Stand der Arbeiten (Konzepte, Probleme)
   - Ausblick

2. Subsystem "neue Manuelle Justage, 
   (Thomas Kullmann und Günther Reinecker)
   - ausgewählte Konzepte zur Trennung von Funktionalität und Oberfläche
   - Stand der Arbeiten, erstellte Dokumente, Thema der Diplomarbeit
   VERSCHOBEN AUF NÄCHSTEN TERMIN

     (!!! E X T R E M  W I C H T I G !!!)
3. Diskussion zu allg. Entwickler-Problemen 
   - Codekonventionen müssen erneuert/ erweitert werden
     ("\"-Zeilenumbruch, #define's, char*-Verwendung, ...)
   - Umstellung auf Visual C++/ Win32
   - CVS 
   KLÄRUNG (z.T.) VERTAGT AUF NÄCHSTES TREFFEN


0. Anmerkungen zu den letzten beiden Protokollen + Protokollant bestimmen
-----------------------------------------------------------------------?--
- keine Anmerkungen zu den alten Protokollen
- neuer Protokollant: Günther Reinecker
- nächster Termin: September


1. Thema Subsystem "Detektoren"
--------------------------------
- Schichtenmodell: 
  Hardwaransteuerung - Steuerlogik - Verwaltung - Benutzeroberfläche
  * problemlose(r) Erweiterung/ Tausch der Hardware
  * Datenkapselung
  * Steuerlogik für häufig verwendete Programmfragmente:
    + Berechnungen
    + Intervallprüfungen
    + Initialisieren mit Daten aus ini-Dateien
  * Dialogfenster in DETECTGUI.H ins Subsystem aufnehmen
    -> Fensterbasisklassen in SPLIB verlagern:
       TheDialog, TheModeless-Problem beseitigen (Aufgabe: Reinecker)

- syntaktische Aufwertung des Qc
  * Auflösen der friend-Relationen: (ggf.) Zugriffsmethoden bereitstellen
  * public-Attribute: 
    private/ protected deklarieren (Accessor/ Mutator-Methoden für Zugriff)
  * Radicon C-Interface: neue Klasse
  * altes C-Interface entfernt: OO-Teile erweitert
  * intuitive Benennung von Klassen, ... (z.B. TDevice -> TDetector)
  * Ersetzen von alten Assembercodezeilen (Portabilität, Lesbarkeit, ...)

- Konzepte zur Hardwareansteuerung unter Win NT/ 2k/ XP
  * Benutzung eines Kernel-Mode-Treibers
    (nur kurzzeitige Testversionen ODER kostenintensiv; nur 8-/ 16-Bit)
  * freigeben der Ports (unsaubere Variante)
    ermöglicht jedoch den „problemlosen“ Umstieg auf Win NT++ Systeme und 
    die Nutzung von DLL's der Hardwarehersteller

- Probleme:
  * derzeit verwendet XCTRL nur Klasse TDetector (neuer Name für TDevice)
    durch das neue Interface müssen nun die Klassen der 
    ein- oder zwei-dimensionalen Detektoren verwendet werden
    -> tief greifende Änderung in anderen Subsystemen 
    -> Zuteilung der Subsysteme zu ein- oder zwei-dimensionalen Detektoren 
       nicht immer sinnvoll/ möglich
  * neue DLL's der Hardwarehersteller sind z.T. nicht abwärtskompatibel
    -> Hardwareansteuerung ohne DLL's, anhand von Programmierbeispielen in
       VisualBasic, ... (sehr test- und zeitaufwendig)


3. Diskussion zu allg. Entwickler-Problemen 
--------------------------------------------
- Codekonventionen 
  * \-Zeilenumbruch vermeiden
    + "\"-Probleme bei zahlreichen Compilern, z.B. Together
    + Länge von 80 Zeichen/ Zeile veraltet:
      BC 4.5-Compiler, VC++, CVS besitzen keine solchen Beschränkungen mehr
    -> vorhandene (bis auf mehrzeilige #defines) entfernen (Aufgabe: Reinecker)
  * Kernigham/ Ritchie-Methodendeklarationen ersetzen:
    Probleme bei Tools wie Together (Aufgabe: Reinecker)
  * #defines vermeiden, statt dessen const
  * char* und TObjekt**-Arrays meiden: 
    besser STL-Objekte (cstring, container) verwenden
  * char[MAXSTRING] sollte unterlassen werden, weil MAXSTRING variieren könnte: 
    lieber Konstante für wirklichen Speicherbedarf; besser cstring aus STL
  * BOOL, TRUE, FALSE (Makros !!!) meiden:
    stattdessen die klein geschrieben Varianten verwenden (Aufgabe: ???)
  * friend-Relationen vermeiden (Probleme bei zahlreichen Analysetools): 
    statt dessen Accessor-/Mutator-Methoden
  * keine public-Attribute!!! 
    besser private oder protected mit entsprechenden Acc.-/ Mut.-Methoden
  * ERGÄNZUNG vom letzten Treffen: die folgenden Ressourcenbezeichner
      IDOK, IDCANCEL, IDABORT, IDRETRY, IDIGNORE, IDYES, IDNO, IDCLOSE, IDHELP
    nicht anders definieren als in Visual C++, WINUSER.H

- Umstellung auf Visual C++/ Win32
  * EINE LETZTE LAUFFÄHIGE VERSION VON XCTRL mit Protokollbuch erstellen, 
    danach Umstellung auf Win32 versuchen :-))))
  * Rücksprache mit Physikern: Win95++ schmackhaft machen ;-)
  * Konvertierung der Ressourcen mit Tool von Herrn Reinecker 
    (letzte erfolgreiche Portierung: CVS-Stand 20.07.2002, 10:00 Uhr)

- CVS 
  * jeder darf nur die Dateien seines Subsystems ändern!!!
    + wird das zu ändernde Subsystem von jemand Anderem bearbeitet, 
      so ist dieser zu bitten, die Änderungen durchzuführen
    + sonst Mail zur Vorankündigung der Änderung verschicken
  * Mail wenn: 
    + Änderungen an Hardware-Subsystemen 
    + Änderungen an fremden Subsystemen
    + Dateien/ Verzeichnisse entfernt oder hinzugefügt
  * Versionen wo simulierte Hardwarekomponenten zu Umstrukturierungzwecken 
    auskommentiert sind, sollte nicht ins CVS eingespielt werden ODER nur dann,
    wenn die Projektmitglieder zuvor informiert wurden 
  * funktionsfähige, getestete Versionen sind per RELEASE-TAG zu kennzeichnen
    PROBLEM: Es kann immer nur der gesamte, aktuelle CVS-Stand "tagged" werden.
             D.h. die Arbeit an allen Subsystemen müsste zu diesem Zeitpunkt 
             abgeschlossen sein!
    VORSCHLAG (Herr Kullmann): CVS-Version für jedes Subsystem (Diskussion bzgl.
              Synchronisation der CVS-Systeme - ODER bessere Vorschläge - müssen 
              noch diskutiert werden)
  * nur GETAGGTE Version darf bei den Physikern installiert werden!!!


==========================================================
   Fehler, Ergänzungen oder Änderungswünsche können auch 
    vor dem nächsten Treffen beim Autor gemeldet werden.
==========================================================