Begin Sequence [ERLEDIGT]

[Manfred]

Hi,

ich möchte hier nun einmal eine Frage stellen, die mir schon seit Clipperzeiten unter den Nägeln brennt. Entweder habe ich ein Brett vor dem Kopf, oder.....

Diese Sache mit Begin Sequence scheint ja richtig mächtig zu sein. Ich habe sie auch in klitzekleiner Routine im Einsatz, aaaaber.... Mein Problem liegt darin, sie bis in die Tiefen zu verstehen. Ich habe einmal etwas größeres zusammengebaut um den Einsatz zu verstehen, oder zu testen. Wenn ich nun eine Routine innerhalb der Begin Sequence programmiere um Fehler abzufangen, dann passiert es, dass ich bei einer DO While Schleife innerhalb von Begin Sequence auch irgendwann diese mit einem EXIT z.B. verlassen muß. Das hat aber in meinem Fall immer dazu geführt, das Begin Sequence komplett verlassen wurde. Was mache ich falsch? Mache ich überhaupt was falsch, oder denke ich hier verkehrt? Es ist klar, das EXIT usw. dazu führen es zu verlassen, aber was baue ich denn dann innerhalb von BEGIn SEQUENCE ein um es im größeren Rahmen zu nutzen?

Gruß

Manfred

PS: kleine Anmerkung an Jan: Fragen habe ich en masse auf Lager...

[Jan]

Hallo Manfred,

da können wir uns ja auf was gefasst machen, mal immer her mit den Fragen

Zu dem Begin Sequence: Ich habe jetzt leider gerade kein Clipper dabei, das habe ich inzwischen nur noch zu Hause auf dem Rechener. Aber wenn ich das richtig im Kopf habe verlässt man eine Begin Sequence-Schleife doch mit Break? Und nicht mit Exit?

Ansonsten: Kannst Du die Do While-Bedingung nicht umschreiben? Daß Du die nicht mit Exit verlassen mußt sondern die sich selber auf Grund der Bedingung beendet? Um es übertrieben auszudrücken: Es muß ja nicht immer ein "Do While .T." sein.

Ich schaue mir das heute Abend mal an, wenn ich wieder an meinem heimischen Rechner sitze.

Jan

[Manfred]

Hallo Jan,

halt Stop brems.......

Clipper sollte nur den Zeitrahmen darstellen. Begin Sequence ist ja auch in Xbase vertreten....

Egal, was ich einbaue, wenn man ein Loop oder andere Dinge, die in Begin Sequence vorkommen, aber auch für Schleifen benötigt werden können, dann gibt es Probleme.

Deshalb frage ich mich die ganze Zeit: "Wie setzt man das Teil noch weiter sinnvoll ein?"

Im Moment nutze ich es nur zum Öffnen von Dateien um dann entsprechend zu reagieren. Das klappt, das habe ich genau verstanden. Eigentlich habe ich es komplett verstanden, ich kriege es bloß nicht so umgesetzt, wie ich es glaube verstanden zu haben.

Hm, das Leben ist echt schwer.....

Gruß

Manfred

[Jan]

Hallo Manfred,

schlechte Nachrichten. Ich hatte mal für einen Bekannten in Auftragsarbeit für sein Apothekenprogramm einige Routinen für den Ausdruck geschrieben, und da dann auch einiges mit Begin Sequence reingebaut. Da wollte ich Dein Problem nachvollziehen.

Leider scheint es so, daß ich irgendwann nach Abschluß der Arbeiten alles gelöscht habe (selten dämlich, ich weiß). So ist das mit der Hilfe für Dich also ersteinmal nicht so kurzfristig möglich wie ich gehofft hatte. Ich bleib aber am Ball und melde mich dann bei Dir.

Jan

[Manfred]

Hallo Jan,

nicht so schlimm, ich habe jetzt solange gewartet, da würde ein bisschen mehr auch nicht den Kohl fetter machen.

Danke für Deine Bemühungen

[Tom]

Hallo, Manfred.

Egal, was ich einbaue, wenn man ein Loop oder andere Dinge, die in Begin Sequence vorkommen, aber auch für Schleifen benötigt werden können, dann gibt es Probleme.

If everything fails, read the fucking manuals.

Innerhalb einer SEQUENCE-Kontrollstruktur dürfen EXIT, LOOP und RETURN nicht genutzt werden. Iterationen und Schleifen jeglicher Art dürfen nur auf "natürliche" Art terminieren, ansonsten verläßt man die Sequenzen mit BREAK. BREAK springt auf die Programmzeile nach END SEQUENCE, es sei denn, die Struktur enthält eine RECOVER-Anweisung, an die ansonsten gesprungen wird. Das zweite Beispiel der XBase-Docs zeigt, wie eine Sequenz mit RECOVER-Rücksprungmarke dazu genutzt werden kann, fehlende Indexdateien beim Öffnen von Datenbanken zu erzeugen, indem einfach der Betriebssystemfehler 2 (Datei existiert nicht) abgefangen bzw. innerhalb des dann ausgetauschten Error-Codeblocks ausgewertet wird, um die fehlenden Dateien zu erzeugen.

Ich würde tendentiell davon abraten, diese Kontrollstruktur zu nutzen, um Schleifen zu programmieren, die aus unüblichen Gründen terminieren sollen, also nicht alle vorgesehenen Iterationen durchlaufen. Zu beachten ist auch, daß BREAK den Thread beendet, in dem die Sequenz läuft.

Wozu willst Du das eigentlich genau nutzen?

[Manfred]

Hi Tom,

Egal, was ich einbaue, wenn man ein Loop oder andere Dinge, die in Begin Sequence vorkommen, aber auch für Schleifen benötigt werden können, dann gibt es Probleme.

If everything fails, read the fucking manuals.

Habe ich ja gemacht.

Innerhalb einer SEQUENCE-Kontrollstruktur dürfen EXIT, LOOP und RETURN nicht genutzt werden. Iterationen und Schleifen jeglicher Art dürfen nur auf "natürliche" Art terminieren, ansonsten verläßt man die Sequenzen mit BREAK. BREAK springt auf die Programmzeile nach END SEQUENCE, es sei denn, die Struktur enthält eine RECOVER-Anweisung, an die ansonsten gesprungen wird. Das zweite Beispiel der XBase-Docs zeigt, wie eine Sequenz mit RECOVER-Rücksprungmarke dazu genutzt werden kann, fehlende Indexdateien beim Öffnen von Datenbanken zu erzeugen, indem einfach der Betriebssystemfehler 2 (Datei existiert nicht) abgefangen bzw. innerhalb des dann ausgetauschten Error-Codeblocks ausgewertet wird, um die fehlenden Dateien zu erzeugen.

Alles genau so im Einsatz. DB öffnen mit Index usw. Wie schon von mir vorher erwähnt.

Ich würde tendentiell davon abraten, diese Kontrollstruktur zu nutzen, um Schleifen zu programmieren, die aus unüblichen Gründen terminieren sollen, also nicht alle vorgesehenen Iterationen durchlaufen. Zu beachten ist auch, daß BREAK den Thread beendet, in dem die Sequenz läuft.

Auch klar mit dem Thread

Wozu willst Du das eigentlich genau nutzen?

Siehst Du, da kommen wir meiner Frage nämlich recht nahe: Wozu benutzt man das denn überhaupt sinnvoll, außer wie oben mit Index schon erwähnt? Ich lese immer nur "mächtiges Werkzeug" in der Doku, kann aber nicht wirklich nachvollziehen, was man damit effizient alles machen kann, bzw. machen sollte.

[Jan]

Hallo Manfred,

Wozu benutzt man das denn überhaupt sinnvoll, außer wie oben mit Index schon erwähnt?

Gute Frage. Ich kann da auch nur eine Amateurhafte Antwort drauf geben, denn ich benutze das eigentlich auch nicht (mehr). Wie ich oben schon gesagt habe hatte ich das mal in einer Druckersteuerung. Vielleicht kann ich das anhand dieses Beispiels erklären.

Früher einmal, zu Zeiten der Nadeldrucker, als Druckdaten nicht seitenweise sondern zeilenweise an den Drucker geschicht wurden, gab es manchmal Probleme, wenn etwa das Papier ausging. Dann gab es unter Clipper eine Fehlermeldung, was ansich ganz in Ordnung war. Hat man aber das Papier nachgefüllt nützte das auch nichts, denn das Programm hatte sich sozusagen ordnungsgemäß verabschiedet. Und selbst wenn man über Retry versuchte weiterzudrucken fehlte da was im Ausdruck.

Und genau das konnte man dann mit Begin Sequence - Recover auffangen. Wenn dann nämlich ein Fehler in dieser Richtung auftauchte konnte man den Auffangen, sauber verarbeiten, und der Ausdruck konnte nach Beheben des Problems ordentlich vortgeführt werden (wenn Du möchtes schicke ich Dir dazu mal einen Codeausschnitt, auch wenn das heute praktisch gesehen nicht mehr viel hift. Aber vielleicht zum Verständnis).

Also kannst Du diese Schleife immer dann verwenden, wenn Du Fehler nicht mit der Standard-Error-Routine auffangen möchtest sondern mit einem für diesen speziellen Fall angepasste Routine auffangen möchtest. Was oftmals auch mit einer angepassten errorsys nicht geht (auch da habe ich teilweise schon meine eigenen Routinen reingebaut, aber alles kann man damit auch nicht abfangen).

Im Moment benutze ich Begin Sequence aber ehrlich gesagt auch nicht mehr. Denn in Zeiten der Seitendrucker und der Druckverwaltung durch den Spooler von Windows taucht der beschriebene Fehler nuneinmal nicht mehr auf. Und rein praktisch gesehen wüsste ich ansonsten auch keine vernünftige Anwendung dafür. Was nicht heißen muß daß es die nicht gibt. Wie gesagt, dafür bin ich dann vielleicht doch wieder zu sehr Amateur.

Jan

[Manfred]

Hallo Jan,

das habe ich mir gedacht.....

Die Sache mit dem Drucker wäre noch etwas gewesen. Nun mußte ich aber im laufe der letzten Wochen, während des Umbaus meines Clipper PRG´s nach Xbase++, feststellen, dass alle Druckerabfragen mehr oder weniger Unsinn geworden sind, weil eben besagter Druckerspooler über Windows läuft. Soweit ich es ausprobiert hatte, war es mehr oder weniger Wurscht, ob ein Drucker dran hängt oder nicht (ein Drucker sollte aber schon installiert sein). ne Meldung kommt eh nicht. Also sehe ich es so, das eh alles alte, was PRINTREADY() usw. war, ausgebaut werden kann, zumal ich mich bei vielen Dingen dazu entschlossen habe, oder entschließen werde, es über den Weg lösen werde in eine Textdatei zu schreiben, die dann mit einem Editor aufgemacht wird. Gibt sowieso mehr Sinn, weil viele Listen über Nacht gedruckt werden würden und wenn dann der Drucker streikt.....

Ich wollte auch nur wissen, ob ich mal wieder etwas verschlafen habe, oder ob diese Routine wirklich nicht soooo wichtig ist, einen Einsatz zu finden.

[Tom]

Hallo, Jan, hallo, Manfred.

Genau so isses, und das sagen die Docs ja auch: BEGIN SEQUENCE ist vor allem dafür gedacht, beim Handling von Error-Objekten Alternativen zum üblichen oder selbstprogrammierten Errorhandler ausführen zu können. Im Beispiel wird statt einer einfachen Abfrage File(cIndexName) der Index mit OrdListAdd() geöffnet, um dann bei Eintreten des Fehlers (Index existiert nicht) eben jenen zu erzeugen. Das ist zwar irgendwie cool, aber für eleganter halte ich dann doch eher sowas:

IF !File(cIndexName)
CreateMyIndex(cIndexName,cIndexExpression)
ENDIF

oder ähnlich. So richtig umhauen tut mich die Lösung per BEGIN SEQUENCE in diesem Zusammenhang nicht.

Ich habe mal nachgesehen - außer im ErrorSys nutze ich SEQUENCE an einer Stelle, und das ist das threadbezogene Laden der DBE, sofern ADS läuft (bzw. eigentlich erwartet wird). Aber auch dort könnte ich das Laden der DBE in dem Fall, daß keine Connection zum Server hergestellt werden kann, mit IF .. ENDIF ebenso einfach umgehen. Der Unterschied besteht darin, daß ich in der SEQUENCE-Variante die initiierte Session nicht kappen muß.

[Manfred]

Hi Tom,

Das ist zwar irgendwie cool, aber für eleganter halte ich dann doch eher sowas:

IF !File(cIndexName)
CreateMyIndex(cIndexName,cIndexExpression)
ENDIF

hm, eigentlich hast Du Recht. Ich weiß aber jetzt zum Verrecken nicht, warum ich die Lösung mit Begin Seq gelöst habe und nicht über IF ! FILE...

Früher hatte ich das nämlich genaus so gelöst, aber irgendwie war ich damit nicht zufrieden. Ich glaube ich muß nochmal in mich gehen und darüber nachdenken, warum....

Ich vermute einmal, dass es wohl die Verführung des Beispieles in der Doku war, denn wenn ich mir jetzt den Code so ansehe...

[Armin]

huhu zusammen,

BEGIN SEQUENCE

WHILE ...
IF ....
EXIT
ENDIF
ENDDO
RECOVER
...
END

funktioniert natürlich.

Handbuch:
Innerhalb von BEGIN SEQUENCE..RECOVER gibt es folgende Restriktionen: In dem Programmcode, der zwischen diesen beiden Anweisungen steht, dürfen die Anweisungen EXIT, LOOP und RETURN nicht verwendet werden. In dem Code, der nach der RECOVER Anweisung steht, können diese drei Anweisungen wieder verwendet werden. Das bedeutet, daß der Programmcode zwischen den Anweisungen BEGIN SEQUENCE und RECOVER nur durch die Anweisung BREAK bzw. durch die Funktion Break() abgebrochen werden kann.

damit ist wohl gemeint, dass mit z.B. EXIT nicht aus der BEGIN SEQUENCE gesprungen werden kann.

Ich habe z.B. mehrere modale Fenster, die z.B. bei der Neueingabe Stammdaten/ Auftrag ... hintereinander ausgefüllt werden müssen. Ein Rücksprung ist aus jedem Fenster möglich. Die Fenster können auch von anderen Routinen aus aufgerufen werden.

Das ist vielleicht auch besser lösbar, ich hab´s jedoch mit BEGIN S. usw. gelöst.

Dann weiss ich, egal wo abgebrochen, wo ich wieder aufsetze und welche Einstellungen ich wieder zurücksetzen muss.

Auch zum Rückgängigmachen einer kompletten Buchung bei einem unvorhersehbaren Laufzeit-Fehler (z.B. Datenlängenfehler...) - das ist das was ein DB-System mit Transaktionen, bzw. Journal macht.

Urzustand merken

BEGIN SEQUENCE
Buchen 1
Buchen 2
Fehler
Buchen 3
RECOVER
Urzustand wieder herstellen
END

Armin

[Manfred]

Hallo Armin,

aha, das ist doch mal was, was ich anfassen kann. Muß ich auch einmal drüber nachdenken.

[Tom]

Ergänzend zu Armin: Wenn man sehr komplex verschachtelte Kontrollstrukturen hätte, zum Beispiel einen eigenen Eventhandler, der für jede Objektart irgendwas tun soll, spart man sich auf diese Art ggf. sehr tiefe IF THEN ELSEIF - Strukturen.

[Manfred]

Ich ergänze hier mal mit einer Erfahrung, die ich gerade mache.

In meinem derzeitigen (geerbten) Projekt wurde nahezu alles in Begin Sequence verpackt, was nicht schnell genug flüchten konnte. Eingabemenues, Do While Schleifen, usw. Ob das wirklich so gewollt war/ist vom Xbase++ Konzept, das der Entwickler es dafür nutzt?

PS: über 1200 mal eingebaut

[Tom]

Mmh.

Du wirst dadurch möglicherweise mit dem Problem konfrontiert, dass echte Fehlersituationen an Dir vorbeigehen, weil sie nie das Fehlersystem erreichen, und möglicherweise verhält sich Deine Applikation dann auch merkwürdig. Verabschiedet sich beispielsweise ein Eventhandler, weil es in ihm einen Programmierfehler gibt, der nur in Sonderfällen erreicht wird, hakt unter Umständen das Programm völlig. So ist das ganz sicher nicht gedacht. Sondern für kritische Prozesse, die die Laufzeitfehlerbehandlung wirklich umgehen sollen. So ein Prozess wäre beispielsweise die Reparatur einer korrupten Tabelle, die feldweise Inhalte umkopiert, aber eben nicht abschmieren soll, wenn er auf falsche Inhalte tritt. Ein Eventhandler, der sich verabschiedet, wenn ein Laufzeitfehler auftritt, handlet keine Events mehr.

[Manfred]

OK,

jetzt stellt sich mir die Frage, wie kann man herausfinden, was überflüssig ist und was nicht. Ich würde es schon der Übersicht wegen gerne reduzieren. Wie so andere Dinge darin auch...

[Tom]

Es kann natürlich sein, dass Du durch diese Vorgehensweise eine Applikation auslieferst, die einen besonders stabilen Eindruck macht. Das kann ein Vorteil sein, muss es aber nicht. Es ist in jedem Fall ein Nachteil, wenn es um die Eingrenzung möglicher Fehler geht, einfach, weil Du ihnen nicht mehr begegnest. Andererseits ist natürlich auch möglich, dass die Sequenzen nie abgebrochen werden, weil die Applikation schlicht fehlerfrei ist. Aber die Wahrscheinlichkeit hierfür geht gegen Null. Tausend Zeilen getesteter Quellcode enthalten Fensterkreuz mal Pi trotzdem zwei Fehler. Die Quote sinkt mit der Erfahrung der Entwickler, aber sie erreicht nie den Nullpunkt. Das ist praktisch unmöglich.

Ich benutze Sequenzen wirklich nur in kritischen Situationen, die Fehler generieren können, wie die oben skizzierte (Reparatur einer Tabelle). In Reorganisations- und umfangreichen Kontrollroutinen befinden sich ebenfalls Sequenzen, obwohl sich das Programm abschottet, wenn solche Prozeduren aufgerufen werden. Und dann gibt es im Ownerdrawing noch ein paar Sachen, wo die Datenquellen so flexibel sind, dass ich unmöglich alle denkbaren Fälle abdecken kann. Auch dort setze ich Sequenzen ein. Oder z.B. in extrem umfangreichen Auswertungen und Datenübergaben, in denen ich auf die Zusammenarbeit mit Drittprodukten angewiesen bin, etwa mehrere Excel-Mappen bestücke oder einen SQL-Server mit großen Datenmengen füttere. Ansonsten aber nicht.

[brandelh]

Ähm Manfred,

kannst du CODE LESEN

Code: Alles auswählen

BEGIN SEQUENCE
RECOVER
END SEQUENCE

hat übrigens nicht immer etwas mit Fehlerbehandlung via ErrorSystem zu tun. Nur wenn das Errorsystem auf Break(e) umgelegt wird, dient es (auch) der Fehlerbehandlung.

Ansonsten nutzt man es z.B. um aus tief verschachtelten Ebenen schnell und definiert heraus zu kommen, an diese Stellen findet man BREAK !
Wenn du also kein BREAK findest und auch keine Fehlerumleitung auf Break(e) aktiv ist, kann man normalerweise die Sequence entfernen.

Aber nur im Code selbst kann man das tatsächlich klären.

Beispiel:

Code: Alles auswählen

BEGIN SEQUENCE
   do while ?
       if 
         for ... 
            for ... 
                if ...
                   Break // springt aus allem heraus, EXIT nur aus dem FOR
                endif
            next
         next
       endif
   enddo
END SEQUENCE

[Manfred]

Hubert,

Du hast den Nagel auf den Kopf getroffen.

Hier ein Beispiel. Ein Break ist vorhanden. Aber ich sehe den Sinn und Zweck der Sache nicht, ein Begin Sequence um sowas herumzubauen. Das ist nur ein Beispiel von vielen.

Code: Alles auswählen

FUNCTION nachrichten_neue( )
         LOCAL yy    := 0
         LOCAL ar_yy := { "Fr Login " + oVtPara:p_user + " :: Sie haben neue Nachrichten erhalten.", "von                  fr den        Inhalt", Replicate( "Ä" , 112 ) }

         MEMVAr oVtPara

         BEGIN SEQUENCE //----------------------------------------------------------
               nim_nach( "S" , 0 , 3 , "NACH" )
               nach->(DbEVal( {|| IF( nach->status = "2-NEU" , EVal({ || yy++ , AAdd( ar_yy,nach->l_von + " " + DToC(nach->dat_vor) + " :: " + nach->txxt )}),) } ) )
               nach->(DbCloseArea())
               DO CASE
                  CASE yy = 0
                       BREAK()
                  OTHERWISE
                       IF Len(ar_yy) > 15
                          ASize( ar_yy , 15 )
                          AAdd( ar_yy , " ..." )
                          AAdd( ar_yy , " ... und weitere Nachrichten " )
                          AAdd( ar_yy , " ..." )
                       ENDIF

                       AAdd( ar_yy , " " )
                       AAdd( ar_yy , " Im Anwahlpunkt 'NACHRICHTEN' k”nnen sie weitere Details einsehen." )
                       AAdd( ar_yy , " " )

                       sag_break( ar_yy )
               ENDCASE
         END SEQUENCE//-------------------------------------------------------------------
         ASize( ar_yy , 0 )
         RETURN( yy )

In der Funktion sag_break() befindet sich dann nochmals ein Break(). Aber das Case würde doch eh verlassen werden, wenn es ausgewählt wird und das darauffolgende abgearbeitet ist. (sofern überhaupt etwas abgearbeitet werden soll. Es würde ja nichts drin stehen. Also ist es doch m.E. überflüssig.
Deshalb meine Frage, ob ich evtl. irgendwas nicht bedenke.

[brandelh]

Hallo Manfred,

in deinem Beispiel würde nach Sag_Break() sowieso alles beendet werden, das ist richtig.

Aber der Sinn der Sache es mit BREAK zu machen ist der, dass man unabhängig von zukünftigen Erweiterungen wird, die nachträglich eingefügt werden.
Egal was danach (ein anderer Programmierer) noch hinzufügt, wird ein BREAK direkt zu END SEQUENCE springen. Das kann schon Sinn machen.

Eventuell ist es aber auch ein Zeichen von zu komplexen Funktionen, die man lieber auflösen sollte.

[Manfred]

Das verstehe ich jetzt nicht. Warum unabhängig von späteren Erweiterungen? Wenn z.B. Case yy = 0 ist, dann ist Feierabend. Da steht ja nichts mehr. Wozu dann ein break()? Und was will man da erweitern wollen/können?

[brandelh]

Nun nach END CASE und vor END SEQUENCE könnte ein Programmierer noch code einfügen und übersehen, dass dieser im Falle von yy = 0 nicht ausgeführt werden sollte ... aber wie gesagt, das ist alles reine Spekulation, wer weiß schon warum ein anderer es so und so gemacht hat.

[Tom]

Die Sequenz hat in diesem Fall keinen Sinn, auch nicht im Hinblick auf zukünftige Erweiterungen. Der Code würde ohne BEGIN ... END exakt genauso funktionieren.

Es widerspricht zudem ein wenig den Grundsätzen der strukturierten Programmierung, denn es handelt sich im Prinzip um ein nachgebildetes GOTO, das einige vielleicht noch aus ihren BASIC-Anfängen kennen. Spaghetticode also. Immerhin sieht es schick aus.

[Manfred]

OK,

es geht/ging mir auch nur darum, habe ich etwas übersehen oder nicht. Was andere denken, oder gedacht haben ist so jetzt nicht nachprüfbar. Es hätte aber sein können, das hier jemand sofort sagt: "Klar, das hat den und den Grund. Lass es mal so." Oder auch: "Nee, mach mal anders. Das bringt so nur Probleme." (egal welcher Art)