Dokumentation - Hilfe

Welche Quelltexte werden geparsed?

Da die Quelltexte alle �ber TurnOver ver�ndert werden, wird haupts�chlich �ber TurnOver die Dokumenation erstellt. Dieses geschieht �ber das Programm TO_EXP_1, welches beim TurnOver Exit Point 1 (Form Finalization) automatisch ausgef�hrt wird. Der Exit Point 1 wird beim Abschliessen einer gelaufenen Form ausgef�hrt. Dabei spielt es keine Rolle von welcher Ebene diese Form l�uft. Es werden alle Objekte der Form geparsed, deren Typ in der KEYPP unter dem Schl�ssel TO_RPGDOCS / CODETYPESxx gelistet sind. Alle alten Dokumentationsinformationen der Programme werden gel�scht. Es werden nur Objekte geparsed, bei denen sich der Quellcode ver�ndert hat. Objekte, die nur rekompiliert werden, werden nicht geparsed.

Das Exit Point Programm ruft das Dokumentationsprogramm ILEDOCS auf.

Falls ein Programm/Quelltext eingetragen ist, aber keine Dokumentationseintr�ge vorhanden sind, wird dieses Programm nicht auf den Webseiten dargestellt.

Voraussetzungen RPG

Um die Dokumentationseintr�ge verarbeiten zu k�nnen, m�ssen bestimmte Voraussetzungen getroffen sein.

Voraussetzungen CL

Um die Dokumentationseintr�ge verarbeiten zu k�nnen, m�ssen bestimmte Voraussetzungen getroffen sein. Hinweis: In CL-Programmen spiel die Position des Textes keine Rolle.

Hinweise zum Dokumentieren RPG

Tags

\main 
 Dieser Text erscheint auf der ersten (Haupt-) Seite.
  
  Beispiel:
\main �berschrift auf der Hauptseite
Text auf der Hauptseite,
der �ber mehrere Zeilen gehen kann.

\author 
 Name des Autors
  
  Beispiel:
\author Name des Autors

\brief 
 Eine zusammenfassende �berschrift f�r das Programm (Pflichteintrag)
  
  Beispiel:
\brief Hier steht eine kurze �berschrift

\date 
 das Datum z. B. Mai 2006
  
  Beispiel:
\date 07. Mai 2006

\param 
 Beschreibung eines Parameters
  
  Beispiel:
\param Artikelnummer (DAN)

\return 
 Beschreibung eines R�ckgabewertes einer Prozedur (auch mehrzeilig m�glich)
  
  Beispiel:
\return *on = erfolgreich
*off = Fehler

\todo 
 Beschreibung einer noch nicht erledigten Aufgabe
  
  Beispiel:
\todo Falls man noch Aufgaben in dem Programm oder
in der Prozedur offen hat, die man irgendwie notieren will,
kann man das hier �ber mehrere Zeilen tun.

\link 
  Ein Hyperlink auf eine Datei. Die URL muss ohne Leerzeichen angegeben werden. Leerzeichen evtl. durch %20 ersetzen. Die Beschreibung muss von der URL durch ein Leerzeichen trennt werden. Die Beschreibung des Links kann Leerzeichen enthalten.
  
  Beispiel:
\link http://hier.sollte.die.url.stehen/zu-dem-dokument/index.html Beschreibung des Hyperlinks

\warning 
 Ein Text, der den Programmier auf gewisse Dinge hinweisen soll.
  
  Beispiel:
\warning �hnlich wie <b>\todo</b>, allerdings mit einem etwas anderen Charakter

\info 
 Ein Text, der den Programmier �ber gewisse Dinge informieren soll.
  
  Beispiel:
\info �hnlich wie <b>\todo</b>, allerdings mit einem etwas anderen Charakter

\rev 
  Ein Text, der die �nderung am Programm auflistet. Auf der ersten Zeile steht das Datum und der Programmierer. Das Datum darf keine Leerzeichen enthalten. Auf allen folgenden Zeilen steht die kurze, zusammenfassende Beschreibung der �nderung.
  
  Beispiel:
\rev 02.10.2006 Mihael Knezevic
       Hier steht der �nderungstext,
       �ber mehrere Zeilen

\deprecated 
  Veraltet: Dieses Programm oder diese Prozedur sollte nicht mehr genutzt werden. �berlicherweise wird der Grund angegeben und ein Workaround bzw. das Programm oder die Prozedur, die diese nun ersetzt hat.
  
  Beispiel:
\deprecated Diese Prozedur wurde ersetzt durch die Prozedur procSQL. Der Datenzugriff findet nun per SQL statt.

\critical 
  Falls das Programm als kritisch eingestuft wurde, soll dieser Tag eingetragen werden. Es braucht kein zus�tzlicher Text erfasst werden.

\authcode 
  Der Berechtigungscode f�r das Programm soll hier angegeben werden. Falls das Programm verschiedene Berechtigungscodes hat, k�nnen diese aufgenommen werden. Pro Tag soll ein Berechtigungscode erfasst werden. F�r mehrere Codes m�ssen mehrere Tags erfasst werden.
  
  Beispiel:
\authcode 6000/19
Berechtigungscode f�r Men� XY

\config 
  Falls ein Programm einen Konfigurationsparameter ben�tigt, zum Beispiel aus der Datei KEYPP, dann kann man den Eintrag hier aufnehmen. Es sollte nur der Schl�ssel und nicht der Wert aufgenommen werden. Eine Beschreibung der Werte sollte auch mit aufgenommen werden.
  
  Beispiel:
\config MAILSERVER/1
IP-Addresse des Mail-Forwarding-Servers

Beispiel RPG

     /**
      * \brief Dokumentationstool f�r RPG Programme
      *
      * Hier steht dann die eigentliche Beschreibung.
      * Diese kann auch in mehreren Zeilen stehen.
      * Alles was nicht zu einem Tag geh�rt, geh�rt automatisch
      * zur detailierten Beschreibung.
      *
      * <div><b>HTML-Tags</b> sind im Kommentar auch erlaubt, um die 
      * Beschreibung zu formatieren.</div>
      *
      * \author Mihael Knezevic
      * \date   Mai 2006
      *
      * \todo Hier steht eine noch nicht erledigte Aufgabe
      *  , welche auch �ber mehrere Zeilen stehen kann.
      *
      * \link http://www.stack.nl/~dimitri/doxygen/ Doxygen
      *
      * <div>Dieses geh�rt auch noch zur detailierten Beschreibung.</div>
      * 
      *       \warning Ein Tag kann auch weiter hinten anfangen. Allerdings muss
      *          das Kommentarzeichen * auf Spalte 8.
      *
      * \info Falls man dem Programmierer noch etwas sagen will,
      *       dann kann das hier stehen.
      *
      * \rev 02.10.2006 Mihael Knezevic
      *      �nderung zum Programm (Task WWSP00XX01)
      *
      * \critical
      *
      * \config MAILSERVER/1
      *         IP-Addresse des Exchange Servers f�r Mail-Forwarding
      *
      * \authcode 6000/17
      *           Berechtigungscode f�r Men� VK5000
      * \authcode 5000/18
      *
      * \param Artikelnummer (DAN)
      * \param G�ltigkeitsdatum
      */
			

HTML Tags

Hier ein paar HTML Tags, um die Dokumentation etwas klarer und �bersichtlicher zu gestalten. HTML sollte hier nicht verwendet werden, um es nur sch�ner zu gestalten. Es handelt sich schliesslich um eine technische Dokumentation.

HTML Tags k�nnen sowohl klein als auch gross geschrieben werden. Die Webbrowser akzeptieren (und interpretieren) beides. Der Standard sieht allerdings vor, dass die HTML Tags klein geschrieben werden, zum Beispiel <html>.

Zeilenumbruch: <br> (eine Leerzeile wird einfach durch zwei Zeilenumbr�che erzeugt) , br = break

Fettschrift: <b>mein fett geschriebener Text</b> , b = bold (fett)

Kursivschrift: <i>mein kursiv geschriebener Text</i> , i = italic (kursiv)

Unterstreichen: <u>mein unterstrichener Text</u> , u = underline (unterstrichen)

Liste:
<ul>
    <li>Erster Listeneintrag</li>
    <li>Zweiter Listeneintrag</li>
    <li>Dritter Listeneintrag</li>
    <li>usw.</li>
</ul>


Pfeile: einen einfachen Pfeil kann man durch das Attribut &rarr; ( → ) oder &larr; ( ← ) darstellen. Doppelte Pfeile kann man durch das Attribut &rArr; ( ⇒ ) oder &lArr; ( ⇐ ) darstellen.

Falls jemand eine andere Formatierung ben�tigt kann er diese sicherlich auf folgender Webseite finden: SELFTHTML

Am schnellsten findet man das Gesuchte dort �ber die Kurzreferenz: HTML.

Eine �bersicht �ber alle m�glichen Sonderzeichen (zum Beispiel auch Pfeile) kann man hier finden.

Frequently Asked Questions (FAQ)

TurnOver: Fall das Parserprogramm auf einen Fehler l�uft, kommt eine Fehlernachricht auf der Nachrichtenwarteschlange des QSYSOPR. Das Programm kann man ruhig abbrechen. Der Status der Form wird dadurch nicht ver�ndert. Das Parsen der Form / Erstellen der Dokumentation kann man sp�ter nachholen, indem man das zu dokumentierende Programm als Parameter per Hand aufruft. Das Dokumentationsprogramm ist ILEDOCS.