[NACHTRAG] LO Makro Basic Option ''Optional'' - ''IsMissing'' immer ''False''

de-users
#1

Hallo,

ein kleiner Nachtrag ...

Die "Optional"-Option verhält sich ein wenig "beliebig":

[1] Ist nur 1 "Optional"-Parameter in der Schnittstelle aufgeführt, so führt die Typ-Deklaration nicht zu einer Fehlfunktion:

Sub Calling_1
    Dim A as Integer
    A= 1
    Called_1()
End Sub

Sub Called_1(Optional A as Integer)
    Dim S as Integer
    MsgBox("A: " & IsMissing(A) & Chr(13))
    S=0
    If (Not IsMissing(A)) Then : S=S+A : End If
    MsgBox("S=" & S)
End Sub

[2] Werden mehr als 1 "Optional"-Parameter in der Schnittstelle aufgeführt, so führt nur die Typ-Deklaration bezüglich des weggelassenen Parameters - hier "B" - zu einer Fehlfunktion:

Sub Calling_3
    Dim A,B,C as Integer
    A= 1 : B = 1 : C = 1
    Called_3(A,C)
End Sub

Sub Called_3(Optional A as Integer,Optional B,Optional C as Integer)
    Dim S as Integer
    MsgBox("A: " & IsMissing(A) & Chr(13) &_
           "B: " & IsMissing(B) & Chr(13) &_
           "C: " & IsMissing(C) & Chr(13))
    S=0
    If (Not IsMissing(A)) Then : S=S+A : End If
    If (Not IsMissing(B)) Then : S=S+B : End If
    If (Not IsMissing(C)) Then : S=S+C : End If
    MsgBox("S=" & S)
End Sub

[3] Ich finde, der "Optional"-Parameter sollte sich immer gleich verhalten, egal, wie oft er in der Schnittstelle aufgeführt ist - also immer das Weglassen der Typ-Deklaration erfordern. In genau diese Falle bin ich getappt, da meine ersten Anwendungen mit dem "Optional"-Parameter immer nur mit 1 "Optional"-Parameter in der Schnittstelle waren und deshalb die Typ-Deklaration nicht "störte" - und mit mehr als einem "Optional"-Parameter bin ich dann "in die Fehlfunktion gelaufen" ...

[4] Sollte man das unterschiedliche Verhalten des "Optional"-Parameters als BUG melden ?

Grüße
Hans-Werner

#2

Hallo Hans Werner,

nein, kein Bug. völlig normales Verhalten. Nur von Dir falsch angewendet.

Eigentlich ein Zufall, dass es überhaupt funktioniert;)

Optionale Parameter dürfen nur am Ende einer Kette verwendet werden. Nach dem ersten optionalen Parameter müssen alle anderen ebenfalls optional sein.

Das Modell sah nie vor, mittlere Parameter auszulassen - also so etwas wie bei Dir: "Called_3(A,C)" - das das überhaupt funktioniert hat mich sowieso gewundert. Hier sollte - wenn überhaupt- der Bug hin.

Die Reihe wird immer von vorne nach hinten (also vom ersten zum letzen Parameter abgearbeitet.

Der typische Aufruf sähe also aus:

Called_3(A,C)

dazu dann die Funktion:

Sub Called_3(Optional A as Integer, Optional B as integer, Optional C as Integer)

Das heisst, die Funktion akzeptiert Null bis max drei Parameter, in der jeweiligen Reihenfolge.

Übergibst Du keinen - alles ok.

Übergibst Du einen - wird der auf A gemappt, die beiden anderen fehlen.

Übergibst Du zwei, wird der erste auf A gemappt, der zweite auf b gemappt, der dritte fehlt.

Übergibst Du drei, werden sie der Reihenfolge nach auf die Variabel A,B,C gemappt.

Ein Aufruf "Called_3(A,C)" übergibt drei Parameter auch wenn der 2. leer ist. Dieser wird auf B gemappt - im Falle das unbestimmten Platzhalters (variant) ist dieser leer und wird quasi als "nicht übergeben" interpretiert. Ist der Platzhalter kein unbestimmter Typ, wird immer der Grundwert angenommen (bei integer ist das Null, beim String Leer etc - d.h. der 2. Parameter fehlt nicht!

Hier ist der Konstrukt einfach falsch und sollte anders programmiert (sauber;)) werden.

Viele Grüße

Thomas

#3

Hallo Thomas,

danke für Deine Erläuterungen. Sie hören sich für mich (durchaus) logisch und nachvollziehbar an, aber beschreiben eine doch etwas andere Vorgehensweise als in der BASIC-IDE-Hilfe (identsich mit der englischen Version) dargestellt und lassen die Anweisung "IsMissing" ins "Leere laufen":

[1] Optional (in Anweisung Function) [Laufzeit]
[1.1] "Ermöglicht es, ein Argument, das einer Function übergeben wird, als optionales Argument zu definieren."
[1.2] Beispiele
+ Function MeineFunktion(Text1 As String, Optional Arg2, Optional Arg3)
+ Result = MeineFunktion("Hier", 1, "Dort") ' alle Argumente vorhanden.
+ Result = MeineFunktion("Test",1) ' zweites Argument fehlt.

Diese Hilfebeschreibung empfinde ich schon etwas "dünn". Dennoch, wenn ich das Hilfe-Beispiel (richtig) interpretiere:

+ Der erste Parameter darf wohl nicht "Optional" sein.
+ Alle Parameter nach dem ersten müssen "Optional" sein.
+ Wird der (erste) "Optional"-Parameter weggelassen, bleibt das zugehörige Komma (,) erhalten.

Allerdings ist es in der praktischen Anwendung so, dass man die Schnittstelle bezüglich Reihenfolgen gestalten kann wie man möchte und auch die optionalen Parameter weglassen kann wie man möchte, wenn man sich an die beiden "Regeln" hält:
+ Das Komma (,) des weggelassenen optionalen Parameters bleibt bestehen.
+ Keine Typ-Deklaration bei optionalen Parametern.
Über "IsMissing" hat man stets die volle Kontrolle über die weggelassenen Parameter. Siehe unten Punk [3].

[2] Funktion IsMissing [Laufzeit]
[2.1] "Ermöglicht es, festzustellen, ob einer Funktion ein optionales Argument übergeben wurde."
[2.2] Test-Makro 4

Sub Calling_4
    Dim A1,optB2,optC3,optD4 as Integer
    A1=1 : optB2=2 : optC3=3 : optD4=4
    Called_4(A1,optB2,optC3,optD4)
End Sub

Sub Called_4(A1 as Integer,Optional optB2,Optional optC3,Optional optD4)
    Dim ZK as String : ZK = ""
    MsgBox("IsMissing(optB2): " & IsMissing(optB2) & Chr(13) &_
           "IsMissing(optC3): " & IsMissing(optC3) & Chr(13) &_
           "IsMissing(optD4): " & IsMissing(optD4) & Chr(13))
    ZK = ZK & "A1=" & A1 & Chr(13)
    If (Not IsMissing(optB2)) Then : ZK = ZK & "optB2=" & optB2 & Chr(13) : End IF
    If (Not IsMissing(optC3)) Then : ZK = ZK & "optC3=" & optC3 & Chr(13) : End IF
    If (Not IsMissing(optD4)) Then : ZK = ZK & "optD4=" & optD4 & Chr(13) : End IF
    MsgBox (ZK)
End Sub

[2.3] Lässt man, wie von Dir angegeben, das Komma (,) des weggelassenen Parameters auch weg, läuft die "IsMissing"-Anweisung "ins Leere". Behält man das Komma (,) bei, funktioniert alles bestens.

[3] Test-Makro 5

Sub Calling_5
    Dim A1,optB2,optC3,optD4,E5 as Integer
    A1=1 : optB2=2 : optC3=3 : optD4=4 : E5=5
    Called_5(A1,optB2,optC3,optD4,E5)
End Sub

Sub Called_5(A1 as Integer,Optional optB2,Optional optC3,Optional optD4,E5 as Integer)
    Dim ZK as String : ZK = ""
    MsgBox("IsMissing(optB2): " & IsMissing(optB2) & Chr(13) &_
           "IsMissing(optC3): " & IsMissing(optC3) & Chr(13) &_
           "IsMissing(optD4): " & IsMissing(optD4) & Chr(13))
    ZK = ZK & "A1=" & A1 & Chr(13)
    If (Not IsMissing(optB2)) Then : ZK = ZK & "optB2=" & optB2 & Chr(13) : End IF
    If (Not IsMissing(optC3)) Then : ZK = ZK & "optC3=" & optC3 & Chr(13) : End IF
    If (Not IsMissing(optD4)) Then : ZK = ZK & "optD4=" & optD4 & Chr(13) : End IF
    ZK = ZK & "E5=" & E5 & Chr(13)
    MsgBox (ZK)
End Sub

[3.1] Hält man sich an die Regeln
+ das Komma (,) des weggelassenen optionalen Parameters bleibt bestehen
+ keine Typ-Deklaration bei optionalen Parametern
funktioniert alles bestens. Egal, welchen und wie viele optionierte Parameter man weg lässt, mit "IsMissing" hat man stets die volle Kontrolle.

[4] Das Zusammenspiel von "Optional" und "IsMissing" ist so, wie man es erwartet. So kann ich nicht wirklich nachvollziehen, dass das Konstrukt falsch sein sollte beziehungsweise hier "unsauber" programmiert wurde, zumal sich das Ganze auch mit der Beschreibung in der BASIC-IDE-Hilfe deckt.

[5] Da ich den Source-Code nicht kenne und deshalb nur "indirekt" argumentieren kann, bin ich jetzt doch etwas ratlos, zumal die Hilfe-Beschreibungen zu "Optional" und "IsMissing" doch etwas "dünn" sind und dummerweise (offensichtlich) auch noch im Gegensatz zu Deiner Darstellung (insbesondere bezüglich "Komma beibehalten" versus "Komma weglassen") stehen.

Grüße
Hans-Werner

------ Originalnachricht ------

#4

Hallo Werner,

siehe es pragmatischer ( und programmtechnisch logisch). Ich kürze mal Deine ausführlichen Tests und Ideen.

Eine Funktion wird mit Parametern aufgerufen.  Die Liste der Parameter musst Du nun "parsen" - das würdest Du auch in jedem anderen Programm ganz einfach machen: Den übergebenen Ausdruck (Also die Liste der Parameter) nehmen, am vereinbarten Trenner teilen und dann einzeln auswerten.

Ich versuche es in Basic auszudrücken:

meineFunktion(a,b,c)   -> drei Parameter übergeben -> entsprechend Sprache (basic) Komma-separiert.

- nun löse ich den Ausdruck (a,b,c) auf - Parameter = split("a,b,c", ",")   - also ich teile am Tennner - und erhalte einen Array (oder eine Liste) mit drei Elementen. Jedes Element wird nun einzeln ausgewertet.

So macht es auch das Programm - ganz egal, was Du übergibst. Und die werden nun entsprechend Ihrer Reihenfolge auch genau so übergeben. An die Funktion, die Parameter übernimmt.

Das "missing" muss sich darauf beziehen, dass ein Parameter fehlt - das kann aus der Logik heraus nur am Ende passieren. d.h. der übergeben Array hat weniger Elemente als die Funktion theoretisch übernehmen kann - und damit es zu keinem Fehler kommt, wird der/die evt. fehlende/n als "optional" gekennzeichent.

Insofern kann auch nur am Ende der Kette Parameter fehlen -> alle anderen werden übergeben!  Das ist die Programmlogik.

Es wäre ein ungültiger Ausdruck zu schreiben:  sub MeineFunktion(a, optional b, c)  - egal ob mit oder ohne Deklaration. In dem Fall wäre ja nur der mittlere Parameter optional - das aber kann die Logik nicht abbilden. Steht auch irgendwo so in der Hilfe: "wird ein Parameter als optional gekennzeichnet, müssen auch alle nachfolgenden als "optional" gekennzeichnet sein".

Wenn Du eine Funktion wie in deinem Beispiel mit funktion(a,c) aufrufst, übergibst Du drei Parameter! auch wenn der mittlere leer ist - der Array besitzt drei Elemente - die dann auf deine Funktion entsprechend gemappt werden. Die Besonderheit bei Basic ist eben, dass Variablen erst zur Laufzeit von Basic erzeugt werden entsprechend des übergebenen Typs (der Interpreter übernimmt die Konstruktion) - es sei denn , du deklarierst den Typ selbst - dann wird die Variable schon mal erzeugt (mit dem standard-Vorgabewert). Die Unsauberkeit der Sprache ist wahrscheinlich, dass das Konstrukt  meineFunktion(a as integer, b, c as integer) bei der Interpretation die Variablen a + c bereits erzeugt entsprechend der Deklaration, b aber erst, wenn der Interpreter den Typ kennt entsprechend der Übergabe-Werte. Wenn dann nix interpretierbar ist (leerer Array-Wert) tut er halt nix… und dann gibt es die Variable b eben noch nicht - und das isMissing(b) wirft true aus, weil die Variable eben noch nicht existiert. Das sind die Unsauberkeiten der Basi-Sprache.

Korrekte Programmierung heisst aber für mich, die Programm-Logik beizubehalten. Der zweite Parameter (b) wird bei Dir eben übergeben- wenn auch "nicht bekannt" "0", oder "-1" - keine Ahnung... das bestimmst Du selbst und musst den Fall abfangen.

Wenn die Hilfe von Basic hier missverständlich ist oder unvollständig... na ja, wird ja auch nur von Menschen geschrieben;)

Viele Grüße

Thomas

#5

Hallo Thomas,

das kann ich schon alles nachvollziehen, aber es beantwortet nicht die Frage, für was es denn dann die Anweisung "IsMissing('name')" gibt ?

Lässt man das Komma des weggelassenen Parameters weg, liefert "IsMissing('name')" eine falsche Aussage, behält man das Komma des weggelassenen Parameters bei, liefert "IsMissing('name')" eine richtige Aussage. Dabei ist es egal, ob man im rufenden Makro die Zeile "Dim A1,optB2,optC3,optD4 as Integer" kommentiert oder nicht:

Sub Calling_4
' Dim A1,optB2,optC3,optD4 as Integer
    A1=1 : optB2=2 : optC3=3 : optD4=4
    Called_4(A1,optB2,optC3,optD4)
End Sub

Sub Called_4(A1 as Integer,Optional optB2,Optional optC3,Optional optD4)
    Dim ZK as String : ZK = ""
    MsgBox("IsMissing(optB2): " & IsMissing(optB2) & Chr(13) &_
           "IsMissing(optC3): " & IsMissing(optC3) & Chr(13) &_
           "IsMissing(optD4): " & IsMissing(optD4) & Chr(13))
    ZK = ZK & "A1=" & A1 & Chr(13)
    If (Not IsMissing(optB2)) Then : ZK = ZK & "optB2=" & optB2 & Chr(13) : End IF
    If (Not IsMissing(optC3)) Then : ZK = ZK & "optC3=" & optC3 & Chr(13) : End IF
    If (Not IsMissing(optD4)) Then : ZK = ZK & "optD4=" & optD4 & Chr(13) : End IF
    MsgBox (ZK)
End Sub

Ich kann nicht nachvollziehen, warum es richtig sein soll, das Komma des weggelassenen optionalen Parameters auch wegzulassen, wenn dadurch die "IsMissing('name')"-Anweisung eine falsche Aussage über den weggelassenen optionalen Parameter liefert:

[1] Called_4(A1,optB2,optD4)

IsMissing(optB2): False
IsMissing(optC3): True
IsMissing(optD4): False

A1=1
optB2=2
optD4=4

[2] Called_4(A1,optB2,optD4)

IsMissing(optB2): False
IsMissing(optC3): False
IsMissing(optD4): True

A1=1
optB2=2
optC3=4

Meine offenen Fragen:

Wenn das Komma des weggelassenen optionalen Parameters auch wegzulassen ist, welchen Sinn macht dann die "IsMissing('name')"-Anweisung mit der Möglichkeit, einen konkreten Parameter-Namen anzugeben und abzufragen, wenn sie sich durch das Weglassen des Kommas auf ein falschen Parameter bezieht (siehe [2]) ?

Warum wird in der BASIC-IDE-Hilfe (DEU + ENG) das Komma des weggelassenen optionalen Parameters nicht weggelassen, wenn es Deiner Meinung nach aber richtig wäre ihn wegzulassen ?

Du sagst "Komma weg lassen", die Hilfe sagt "Komma beibehalten" (und in der praktischen Anwendung funktioniert es auch so) - und was ist nun richtig ?

Oder habe ich Dich vielleicht völlig falsch verstanden ?

Grüße
Hans-Werner

------ Originalnachricht ------

#6

Hallo Hans Werner,

Oder habe ich Dich vielleicht völlig falsch verstanden ?

Hast Du. Versuche mal, die Texte zu lesen und nicht gleich auf deine Anwendung/die Hilfe-Beispiele zu übertragen und Fehlinterpretationen hinzubauen.

Du kannst keine "Kommas" weglassen - das ist weder der Sinn noch meine Aussage.

Trenne das Ganze abstarkt:

Du übergibst beim Aufruf der Funktion dieser eine Liste mit Parametern ... die Anzahl der Parameter wird bestimmt durch die Anzahl der Trenner +1

Also: Funktion(a,b)   -> zwei Parameter, weil ein Trenner dabei ist.

Die Parameter werden nun entsprechend der physikalischen Reihenfolge der aufrufenden Funktion übergeben.

sub Funktion( a1,b1,c1,d1)     -   würde zu einem Fehler führen, da die Funktion 4 Parameter erwartet, aber nur zwei erhält.

Um den Fehler abzufangen, wird der Begriff "optional" eingeführt:

sub Funktion (a1, b1, optional c1, optional d1)  - kein Fehler mehr, zwei Parameter werden übergeben, 2-4 erwartet. Passt.

Mit isMissing() kannst Du nun c1 und d1 abfragen und eventuel neu definieren bzw Werte zuweisen.

Der Aufruf Funktion(a,b)  übergibt 3 Parameter - zwei Trenner! Der mittlere fehlt eben nicht! Wäre aber in dem Fall leer und führt zum Fehler, da die Funktion eine Wert erwartet!

sub Funktion (a1, b1, optional c1, optional d1)  -> a1 bekommt den Wert von a zugewiesen, b1 bekommt den Wert von "nichts" zugewiesen, c1 bekommt den Wert von b zugewiesen, der Parameter d1 fehlt.
Das kann dir isMissing(d1) = true liefern.

Setzt Du alle Parameter auf "optional" würde das bei Basic gehen (siehe letzte mail) - ist aber unsauber und nicht korrekt.

Korrekt wäre: sub Funktion (a1 as integer, b1 as integer, optional c1 as integer, optional d1 as integer)  → Das führt beim Aufruf funktion(2,3) zu dem korrekten Ergebnis:

a1 = 2, b1 = 0, c1 = 3, d1 = ?? -> missing

Das ist auch die korrekte Programmierung.

Zu Deiner Aufgabenstellung:

Du willst doch alle drei Parameter haben, oder?  Lass das optionale weg und verlagere die Prüfung vor den Aufruf. In dem Zusammenhang viel sinnvoller. Und dann übergib immer drei Werte.
Willst Du die Prüfung unbedingt in der aufzurufenden Funktion, arbeite mit Platzhalterwerten - z.B. -1 für "nichts".

Viele Grüße
Thomas

#7

Hallo Thomas,

da habe ich wohl Deine gestrige Aussage (Wed, 6 Dec 2017 23:35:03 +0100) missverstanden:

"[…] Das Modell sah nie vor, mittlere Parameter auszulassen - also so etwas wie bei Dir: "Called_3(A,C)" - dass das überhaupt funktioniert hat mich sowieso gewundert. […] Der typische Aufruf sähe also aus: Called_3(A,C) […]".

Das hatte ich als "Komma weglassen" verstanden, aber Du wolltest mir darstellen, dass so eine Schnittstelle-Definition "Sub Called_3(Optional A as Integer,Optional B,Optional C as Integer)" verbunden mit dem Aufruf "Called_3(A,C)" programmiertechnisch "unsauber" ist und es Dich wunderte, dass es überhaupt funktionierte. Und dann haben wir wohl etwas aneinander vorbei argumentiert, weil wir unterschiedliche Problem-Schwerpunkte sahen …

Ich denke, ich habe jetzt verstanden, worauf Du hinaus wolltest. Zur Gegenkontrolle zusammengefasst mit meinen Worten.

[1] Test-Makros

Sub Calling
    Dim A,B,C,D,E as Integer
    A=1 : B=2 : C=3 : D=4 : E=5
    Called (A,B,C,D,E)
End Sub

Sub Called (A as Integer,Optional B as Integer,Optional C as Integer,Optional D as Integer,Optional E as Integer)
    MsgBox("IsMissing(B): " & IsMissing(B) & Chr(13) &_
           "IsMissing(C): " & IsMissing(C) & Chr(13) &_
           "IsMissing(D): " & IsMissing(D) & Chr(13) &_
           "IsMissing(E): " & IsMissing(E) & Chr(13)
End Sub

[2] Programmiertechnisch "sauber" definierte Schnittstelle (vgl. "Sub Called"):

+ Zuerst alle "nicht optionalen" Parameter, dann alle "optionalen" Parameter !

[3] "IsMissing" liefert nur korrekte Ergebnisse, wenn die Parameter auch wirklich im Aufruf der Schnittstelle fehlen:

[3.1] Beispiel: Called(A,B)

IsMissing(B): False
IsMissing(C): True
IsMissing(D): True
IsMissing(E): True

"C", "D" und "E" werden durch "IsMissing" erfasst.

[3.2] Beispiel: Called(A,B,)

IsMissing(B): False
IsMissing(C): True
IsMissing(D): True
IsMissing(E): True

"D" und "E" werden durch "IsMissing" erfasst. Und auch "C" - trotz des Platzhalter-Kommas ! LO-BASIC hält sich hier offensichtlich nicht an die Regel: "Anzahl der Parameter" ist gleich "Anzahl der Trenner" + 1.

[3.3] Beispiel: Called(A,B,D)

IsMissing(B): False
IsMissing(C): False
IsMissing(D): False
IsMissing(E): True

"E" wird durch "IsMissing" erfasst, "C" jedoch nicht, weil nicht wirklich fehlt wegen dem ","-Plathalter.

[4] Nicht durch "IsMissing" erfasste, aber dennoch "fehlende" Parameter, muss man durch Platzhalterwerte kennzeichnen.

[5] Test-Makros (modifiziert)

Sub Calling_MOD
    Dim A,B,C,D,E as Integer
    A=1 : B=2 : C=3 : D=4 : E=5
    Called_MOD (A,B,C,D,E)

End Sub

Sub Called_MOD (A as Integer,Optional B as Variant,Optional C as Variant,Optional D as Variant,Optional E as Variant)
    Dim ZK as String
    MsgBox("IsMissing(B): " & IsMissing(B) & Chr(13) &_
           "IsMissing(C): " & IsMissing(C) & Chr(13) &_
           "IsMissing(D): " & IsMissing(D) & Chr(13) &_
           "IsMissing(E): " & IsMissing(E) & Chr(13)
    Z = "A=" & A & Chr(13)
    If (Not IsMissing(B)) Then : If (B <> "!B") Then : Z = Z & "B=" & B & Chr(13) : End If : End If
    If (Not IsMissing(C)) Then : If (C <> "!C") Then : Z = Z & "C=" & C & Chr(13) : End If : End If
    If (Not IsMissing(D)) Then : If (D <> "!D") Then : Z = Z & "D=" & D & Chr(13) : End If : End If
    If (Not IsMissing(E)) Then : If (E <> "!E") Then : Z = Z & "E=" & E & Chr(13) : End If : End If
    MsgBox (Z)
End Sub

[5.1] Setzt man (beispielsweise) für die optionalen Parameter (in "Sub Called") den Typ "Variant", kann man mit einheitlichen Platzhalterwerten für "fehlenden Parameter" arbeiten, beispielsweise für den Parameter "C" mit "!C" für "!parametername". "!" ist in Perl das Zeichen für logisch "NICHT".

[5.2] "Called_MOD(A,B,"!C",D)" liefert

IsMissing(B): False
IsMissing(C): False
IsMissing(D): False
IsMissing(E): True

A=1
B=2
D=4

[6] Persönliche Schlussfolgerungen

[6.1] "Optional" und "IsMissing" sollte man nur nutzen, wenn die betroffenen Parameter bei jeglicher Aufruf-Situation entweder vorhanden sind oder WIRKLICH wegfallen und nicht durch "," "überleben", da man sonst "doppelt prüfen" muss.

[6.2] In allen anderen Fällen ist es sinnvoller, gleich mit "ist nicht vorhanden"-Platzhalterwerten zu arbeiten.

[7] Meine Anwendung

Die Anwendung ist eine für verschiedene SUBs formulierte Test-Anzeige-Routine für Testzwecke, die, aufgerufen in verschiedenen SUBs (eines Projektes), dann immer nur das anzeigt, was in der jeweiligen SUB nach Durchführung der Verarbeitung an verarbeiteten Daten zur Verfügung steht. So "müllt" man sich die SUBs nicht mit Anweisungen für Test-Anzeigen zu, sondern benötigt nur eine Anweisungszeile ...

Nochmals Dank für Deine Geduld und hilfreichen Ausführungen,
Grüße
Hans-Werner :-))

------ Originalnachricht ------

#8

Hi,
nun sind die Popcorn aufgebraucht und da will ich noch meinen Senf dazu geben :slight_smile:
Ich finde es sehr erheiternd, dass Du glaubst Du hättest in den Basics von Basic
einen Bug gefunden :))
Seit Generationen werden angehende Programmierer mit Basic geplagt...
Fast alle sind dabei irgendwannmal in dieses Loch gefallen - Du aber denkst, der
Fehler sitzt diesmal nicht vor dem Rechner. Leider ist es aber doch so :slight_smile:

SCNR

#9

Ehre wem Ehre gebührt ...

... "gefunden" hat diesen BUG (oder auch nicht BUG) Andrew Pitonyak schon 2003,

wenn Dir dieser Name vielleicht etwas sagt ...

Grüße
Hans-Werner ;-))

------ Originalnachricht ------