Fehler beim Kompilieren: Erwartet: Optional

Moderator: ModerationP

Fehler beim Kompilieren: Erwartet: Optional

Beitragvon agripina » 12. Jun 2021, 19:33

Hallo,
die Zeilen
Code: Alles auswählen
Public Function fctKWMon(ArgKW As Byte, Optional ArgJahr)
Dim M As Date
'...
fctKWMon = M
(http://www.donkarl.com?FAQ2.9)
habe ich so ergänzt:
Code: Alles auswählen
Public Function fctKWMon(ArgKW As Byte, Optional ArgJahr, pgm as string) as String
Dim M As Date
'...
fctKWMon = Cstr(M)

Es kommt bei pgm:
Fehler beim Kompilieren: Erwartet: Optional

Wieso dies? 'ArgKW As Byte' ist doch auch nicht optional eingestellt.
Außerdem wundert mich, dass kein Rückgabewert beim ersten Code angegeben ist. Wird beim Fehlen das automatisch intern ergänzt?
Man könnte optional ja ergänzen, um den Fehler nicht zu bekommen, aber optional ist nicht nötig. Wie muss das dann geändert werden?
Gruß Heinz
agripina
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 43
Registriert: 02. Sep 2018, 22:29

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon Gast » 12. Jun 2021, 20:15

Auf optionale Argumente dürfen keine nichtoptionalen folgen => Reihenfolge tauschen
Gast
 

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon Gast » 14. Jun 2021, 08:36

Hallo,
danke. Das war der Grund.
zu: "Wird beim Fehlen das automatisch intern ergänzt?"
In der OH steht [As Typ], also optional.
Und es läuft auch ohne "as String".
Warum also angeben? Besserer Stil?
Gruß Heinz
Gast
 

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon Doming » 14. Jun 2021, 11:23

Wenn kein Datentyp angegeben wird, ist der per default „Variant“

Fehlende Werte nehmen eingestellten Nullwert an (Byte, Long usw sind dann 0, String dann NULL) meine ich

Gruß
Doming
Benutzeravatar
Doming
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 163
Registriert: 01. Jul 2014, 05:19

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon Gast » 15. Jun 2021, 00:21

Hallo,
Fehlende Werte nehmen eingestellten Nullwert an (Byte, Long usw sind dann 0, String dann NULL) meine ich

zu String dann NULL
Ich glaube, das nennt man eine Null-Zeichenfolge. Aber nicht zu verstehen als NULL-Zeichenfolge. Also eine Zeichenfolge der Länge 0.
Vielleicht ist dazu passend der Satz der OH:
Null ist auch keine Zeichenfolge der Länge Null (""), die manchmal auch als Null-Zeichenfolge bezeichnet wird.

Man hätte besser statt "als Null-Zeichenfolge" das "als 0-Zeichenfolge" formuliert.
Folgendes sehe ich als Beweis.
s="String"
?isnull(mid(s,7))
Falsch
?(mid(s,7))=""
Wahr
Aber warum den Datentyp angeben und nicht per default „Variant“ verwenden?
Statt "Besserer Stil?" hätte ich besser "Sicherer Stil" schreiben sollen
Gruß Heinz
Gast
 

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon knobbi38 » 15. Jun 2021, 11:01

Hallo Heinz,

die Aussage von Doming
Fehlende Werte nehmen eingestellten Nullwert an (Byte, Long usw sind dann 0, String dann NULL)

ist natürlich Quatsch, denn was soll ein "eingestellter Nullwert" sein? Den Begriff gibt es nicht und fehlende Werte werden mit ihren Initialwerten übergeben. Diese sind per Definition in VBA für jeden Datentyp festgelegt, z.B. bei einem Long-Datentyp der numerische Wert 0 und bei einem String eine leer Zeichenfolge (ein String der Länge 0).

Was du als "Beweis" anführst, ist genauso Unsinn und auch kein "Beweis". Schau dir mal den Rückgabewert/-Typ der Funktion Mid() an und wann genau Mid() eine NULL zurückgibt und was zurückgegeben wird, wenn der Startwert größer ist als die zu Anzahl der Zeichen.

Aber warum den Datentyp angeben und nicht per default „Variant“ verwenden?

Ja, warum werden in Programmiersprachen überhaupt Datentypen eingeführt, wenn es doch einen universellen Datentyp gibt?
Ich glaube, wenn du mal genau darüber nachdenkst, wirst du schon selber zu der Erkenntnis gelangen, wofür Datentypen in Programmiersprachen verwendet werden und gut sind.

Wenn du noch solche grundlegenden Fragen hast, ist vielleicht ein Forum nicht die richtige Anlaufstelle, um Grundlagen der Programmierung zu vermitteln. Ein gutes Fachbuch, ein VHS Kurs oder ein Video Traningskurs sind dafür sicherlich besser geeignet.

Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3330
Registriert: 02. Jul 2015, 14:23

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon Gast » 15. Jun 2021, 16:14

Hallo Ulrich,
wenn du mal genau darüber nachdenkst, wirst du schon selber zu der Erkenntnis gelangen, wofür Datentypen in Programmiersprachen verwendet werden und gut sind.

Gerade deswegen ja die Nachfrage, da mich die 1. Zeile des Codes vom Eingangspost stutzig machte. Hier verzichtet DonCarl auf die Angabe des Datentyps beim Rückgabewert und nicht nur dort. Ich gehe davon aus, dass er weiß, wofür Datentypen gut sind. Und dein Rat zu VHS... - Na ja.
Ich beziehe ihn jetzt erstmal auf andere, denn ich bin nicht der Autor dieser Zeile, sondern stellte dazu eine Frage aus Verwunderung.
Schau dir mal den Rückgabewert/-Typ der Funktion Mid() an und wann genau Mid() eine NULL zurückgibt und was zurückgegeben wird, wenn der Startwert größer ist als die zu Anzahl der Zeichen.

s="String"
a)Schau dir mal den Rückgabewert/-Typ der Funktion Mid() an;
?TypeName(mid(s,7))
String Was soll man daran bez. NULL erkennen?
b)wann genau Mid() eine NULL zurückgibt; also meinst du das mit obigem String ?mid(null,1) ist ja klar.
c) was zurückgegeben wird, wenn der Startwert größer ist als die zu Anzahl der Zeichen
?mid(s,7); keine Fehlermeldung, sondern ein Nullstring. Daher wahr. Du meinst, es sei kein Beweis? Wie kann man es belegen?
Gruß Heinz
Gast
 

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon mmarkus » 15. Jun 2021, 17:37

Gast hat geschrieben:?mid(s,7); keine Fehlermeldung, sondern ein Nullstring. Daher wahr.


Könnte man so sehen.
Genau genommen hängt es aber von der Definition von Nullstring ab.
Die Konstante vbNullString ist jedenfalls was anderes wie ein String der Länge 0.
Wenn man also genau ist, ist es kein Nullstring und wenn man versteht, was ein Nullstring ist, kann man das auch ganz einfach beweisen. :D

Die Frage ist aber worum es dir überhaupt geht.
Warum man nicht einfach immer Variant verwenden soll - dazu gibt es viele Abhandlungen - einfach mal kurz googeln.

Aber für einen Vergleich aus dem realen Leben.
Du fährst auch nicht mit dem LKW dein Kind aus der Schule abholen, sondern mit dem PKW. Warum darfst du selbst beantworten.
Man verschwendet in der Regel nicht einfach Laufzeit und Ressourcen, wenn es keinen Sinn macht.
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 2095
Registriert: 16. Apr 2012, 16:07
Wohnort: Oberösterreich

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon knobbi38 » 15. Jun 2021, 20:10

Hallo Heinz,

OT:
Warum meldest du dich nicht mehr an, sondern verwendest einen Gastzugang?
Ganz nebenbei: die Webseite heißt "https://www.donkarl.com/" und die Person dahinter heißt Karl Donaubauer.

Der Hinweis auf VHS war nur symbolisch gemeint und steht natürlich auch für andere Bildungseinrichtungen, wie z.B. das "BZK der Arbeitskammer des Saarlandes" und vergleichbare Einrichtungen.

Zurück zum Thema:
zu a) Der Rückgabewert ist Variant/String, d.h. es könnte auch NULL zurückgegeben werden. Mit String alleine wäre das nicht möglich. Zur Typbestimmung wird bei Variant VarType() und nicht Typename() verwendet!

zu b) ist klar - hat sich somit erledigt.

zu c) Es wird kein Nullstring, wie bei der Zuweisung mit vbNullstring, sondern ein leere Zeichenfolge(String) der Länge 0 zurückgegeben. Das ist etwas anderes!!!

Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3330
Registriert: 02. Jul 2015, 14:23

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon agripina » 17. Jun 2021, 08:04

Hallo,
"Gastzugang": manchmal schreibe ich von anderen PCs. Das ist dann schneller.
Man verschwendet in der Regel nicht einfach Laufzeit und Ressourcen, wenn es keinen Sinn macht.

In dem Sinn wäre geholfen, wenn besagte Zeile bei donkarl.com einmal richtig hier gepostet wäre.
Sie war ja der Anlass der Frage und hat bei den Antworten bei mir noch mehr Fragen aufgeworfen. :?
z.B.:
zu c) Es wird kein Nullstring, wie bei der Zuweisung mit vbNullstring...
Wie sieht die Zuweisung mit vbNullstring im Direktbereich aus? Sie hat wahrscheinlich in der Praxis keine Bedeutung?
wenn man versteht, was ein Nullstring ist, kann man das auch ganz einfach beweisen
Wie sieht der Beweis denn aus?
Gruß Heinz
agripina
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 43
Registriert: 02. Sep 2018, 22:29

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon knobbi38 » 17. Jun 2021, 10:41

Hallo Heinz,

wie eine Zuweisung im Direktbereich aussieht, brauche ich dir wohl nicht mehr erklären, aber unabhängig davon macht so eine Zuweisung im Direktbereich auch keinen Sinn. Dir ist schon bewußt, daß du im Direktbereich immer mit Variants arbeitest?
Sie hat wahrscheinlich in der Praxis keine Bedeutung?

Natürlich hat ein Nullstring eine Bedeutung, sonst hätte man diesen wahrscheinlich einfach weggelassen. Nullstrings werden vornehmlich in Verbindung mit APIs verwendet, können aber auch sonst in Codes vorkommen.
Wie sieht der Beweis denn aus?

Bei einem Nullstring zeigt die interne Variable-Referenz eines Strings auf NULL. Das kann man mit den Funktionen varptr() und strptr() erkunden bzw. nachvollziehen. Das sind Internas von VBA, auf die ich jetzt aber nicht weiter eingehen möchte.

Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3330
Registriert: 02. Jul 2015, 14:23

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon Bitsqueezer » 18. Jun 2021, 00:27

Hallo,

die Funktion von Karl ist soweit schon "OK". Warum so und nicht ArgJahr mit explizitem Datentyp?

Wenn man einen optionalen Parameter verwendet, dann MUSS dieser als Variant deklariert werden, wenn man die Funktion "IsMissing" verwenden möchte, um zu prüfen, ob der Parameter übergeben wurde. Der Datentyp beim "Weglassen" ist dann "Variant/Error".

Dummerweise erlaubt Variant aber nun mal, alles mögliche zu übergeben, weswegen man besser auf "IsMissing" verzichtet und einen expliziten Datentyp angibt, dem man einen Initialwert verpaßt, mit dem man dann prüfen kann, ob der Parameter übergeben wurde. Denn ein Aufruf mit z.B. "NULL" als ArgJahr geht hier in die Hose. Ebenso "x" als Parameterwert. Besonders sicher ist das also so nicht.

Besser ist, "Optional ArgJahr As Integer" (oder Long, wenn man das Jahr 32767 überschreitet... :lol: )
Denn nun wird bereits beim Aufruf der Funktion der Parameter abgewiesen, wenn versucht wird, etwas anderes als eine Zahl zu übergeben. Vorsicht: Es geht weiterhin, einen String oder einen Double etc. zu übergeben, solange per implizierter Typumwandlung eine gültige Zahl im Wertebereich des Parameters rauskommt. Übergabe von "2021" funktioniert also, bei "x" nicht. Übergabe von "43673415634" gibt auch einen Fehler - Überlauf.

Statt "IsMissing" kann man hier nun einfach "If ArgJahr = 0" verwenden. 0 ist ohnehin der Default von Integer, ansonsten könnte man eben auch einen anderen Wert verwenden, wenn "0" erlaubt sein soll. Dann wäre es z.B. "Optional ArgJahr As Integer = -1" und man könnte stattdessen auf -1 testen.

Rückgabewert: Hier liegt Karl mit dem Fehlen des Datentyps (und damit automatisch Variant) falsch oder besser "nicht sehr genau". Da "M" als Date deklariert ist und das am Ende der Funktion zugewiesen werden soll, sollte die Funktion auch explizit mit "As Date" den Rückgabetyp deklarieren. "As String" ist natürlich ebenso falsch, weil dann eine implizite Typumwandlung mit Formatierung in Regionaleinstellung stattfindet, die bei Wechsel der Regionaleinstellung dann schon zu Problemen in der Anwendung führen könnte.

Da Date nie NULL sein kann, ist hier ein Variant nicht notwendig. Es wird ein Datum als Rückgabe erwartet, die Funktion hat keine anderen Rückgabewerte für Fehlerfälle.

Unabhängig davon sollte man auch beachten, daß es sich hier um FAQ-Lösungen handelt. Das heißt, es soll möglichst einfach demonstriert werden, wie man eine Lösung zu allgemein häufigen Problemen lösen kann. Die Funktion ist in der gezeigten Form nicht geeignet, um 1:1 in eine produktive Anwendung übernommen zu werden, da sie bei jedem Fehler sofort hängenbleibt und z.B. über keinen Errorhandler verfügt, um damit umzugehen. Der muß auch zur verwendeten Anwendung passen, denn es kann ja sein, daß "ArgJahr" bei der Übergabe NULL ist und dann soll statt eines Fehlers z.B. einfach NULL wieder zurückgegeben werden, weil man die Funktion etwa in einem SQL-Befehl verwenden will und der soll keine Fehler ausgeben.

Also: Eigenen Kopf einschalten und nicht einfach Copy/Paste-Programmierung verwenden. Ein Wert von -2000 für ArgJahr etwa geht genauso in die Hose. Gerade solche "kleinen" Funktionen sollte man sehr gründlich testen, damit man sich für die "großen" felsenfest darauf verlassen kann. Und Datentypen immer auf das einschränken, was man wirklich braucht.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 8335
Registriert: 21. Jun 2007, 12:17

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon Gast » 18. Jun 2021, 17:14

Hallo,
@Ulrich
daß du im Direktbereich immer mit Variants arbeitest

Wie passt denn deine Aussage zu diesem ?
Code: Alles auswählen
s="String"
?vartype(s)
 8 ' aus OH: vbString 8 Zeichenfolge (String)
?typename(s)
String

@Christian
Jetzt ist es klarer.
nicht einfach Copy/Paste-Programmierung verwenden

im Eingangspost ergänzte ich ja den Code, also kein C/P. Ich denke, Cstr ist für den Rückgabewert auch passend, da er im Form_Current an ein ungebundenes Textfeld übergeben wird.
fctKWMon = Cstr(M)
Gruß Heinz
Gast
 

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon knobbi38 » 18. Jun 2021, 17:32

Hallo Heinz,

immer noch nicht verstanden? Schon mal in der Hilfe nachgelesen? :roll:

Wenn VarType den Wert 8 zurück gibt, was meinst du, ist das für eine Datentyp? Wer Lesen kann ist klar im Vorteil und ich habe nun wirklich keine Lust mehr, mich immer wiederholen zu müssen. Entweder du glaubst das was ich und die Helfer hier schreiben oder du reimst dir deine eigene Wahrheit selber zusammen und bleibst dabei, alles und jenes in Frage zu stellen.

Ich bin dann mal raus.

Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3330
Registriert: 02. Jul 2015, 14:23

Re: Fehler beim Kompilieren: Erwartet: Optional

Beitragvon agripina » 18. Jun 2021, 19:21

Hallo Ulrich,
was meinst du, ist das für eine Datentyp? Wer Lesen kann ist klar im Vorteil

Stimmt, aber ich schrieb bereits:
8 ' aus OH: vbString 8 Zeichenfolge (String)

Außerdem schrieb ich:
?typename(s)
String

Beides zeigt, dass im Direlktbereich die Variable s als string behandelt wird und das steht mE im Widerspruch zu deiner Aussage "... du im Direktbereich immer mit Variants arbeitest"
Gruß Heinz
agripina
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 43
Registriert: 02. Sep 2018, 22:29

Nächste

Zurück zu Access Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste