Bug in INI_PARSER bzw. unscharfe Dokumentation

[selli69]

Hallo,

Weiß nicht ob das in diese Unterforum gehört, wenns nicht passt, dann bitte verschieben.

Ich setze den INI_PARSER_FILE ein und bin dabei auf ein Problem gestoßen. Wenn der Suchstring für eine Sektion die Zeichen '[' oder ']' enthält, dann findet der Baustein die Sektion (welche diese Zeichen enthält) nicht.

Das ist natürlich ein Grenzfall. Es wäre jedoch schön, wenn man dieses Verhalten entweder ändern/berichtigen könnte oder in der Dokumentation das Vorkommen dieser Zeichen explizit ausschließt.

Ich habe mich jetzt damit beholfen, dass ich beim generieren der .ini Files die eckigen gegen geschweifte Klammen austausche und dies ebenso beim Suchen mit dem Baustein mache. Hintergrund ist, dass ich für die Sektionsnamen Reflections der POUs mit .ini Daten verwende, welche, so sie sich in einem Array befinden, dann eckige Klammen im entsprechenden String haben.


An dieser Stelle einmal Danke an alle, die diese wirklich nützlichen und mir eine Menge Zeit sparenden Bibliotheken entwickeln und pflegen!

gl&hf!

[peewit]

stelle doch mal dein ini.datei online damit ich sehen kann was du genau anstellen willst

[selli69]

Hallo peewit!

Wie gesagt, ich substituiere als Workaround die eckigen zu den geschweiften Klammern. Doch wenn es dich interessiert, dann stelle ich hier mal einen Teil einer .ini Datei ein, in welcher eine Sektions-Suche nach Sektionen welche eckige Klammern beinhalten nicht funktioniert:

Code Auswählen Erweitern


[fbFunctionsManager]
ausiFunctionsGUI=AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wJSYnKCkqKywtLi8wPT4/QA==E
[fbFunctionsManager.afbFunctions[1]]
usiFunctionType=AQ==
xOpenClosed=AQ==
usiGroup=AA==
[fbFunctionsManager.afbFunctions[2]]
usiFunctionType=Ag==
xOpenClosed=AQ==
usiGroup=AA==

...




Wenn ich in dieser Datei nach der Section "fbFunctionsManager.afbFunctions[1]" suche, so findet der Parser nichts.

LG

[peewit]

[fbFunctionsManager.afbFunctions[1]]

da bist du ja aber selber schuld

https://de.wikipedia.org/wiki/Initialisierungsdatei

ein sektionsname muss innerhalb [ ] definiert werden
das machst du nicht und ist auch nicht vorgesehen
das würde ja nicht mal bei windows selber funktionieren da wo dieses format eigentlich herkommt

[selli69]

[fbFunctionsManager.afbFunctions[1]]

da bist du ja aber selber schuld

https://de.wikipedia.org/wiki/Initialisierungsdatei

So? Dann zeige mir bitte wo in dieser Definition die Nutzung eckiger Klammern im Sektionsnamen explizit ausgeschlossen wird.

ein sektionsname muss innerhalb [ ] definiert werden

Der Sektionsname in meiner .ini IST innerhalb [ ] definiert. Das Problem ist, dass dein Parser mit eckigen Klammern im Suchstring nicht zurecht kommt. Kann auch gar nicht gehen, so wie es programmiert ist.

das machst du nicht und ist auch nicht vorgesehen

GENAU DAS mache ich. Und wo steht geschrieben, dass es nicht vorgesehen ist? In deiner Dokumentation nicht und auch nicht auf WP. Dann schreibs halt rein, dass das nicht vorgesehen ist und gut ist.

das würde ja nicht mal bei windows selber funktionieren da wo dieses format eigentlich herkommt

Windows != IEC61131-3

Wenn Du dich auf Windows berufen willst, dann ist in der Dokumentation das entsprechende Paper von Microsoft zu benennen, in welchem das Format gespect ist.

Naja. Für mich war das das letzte Mal, dass ich hier eine Anmerkung zu offensichtlichen Unschärfen mache, wenn nur abgeblockt anstatt nachgedacht wird.

[peewit]

hallo selli69

oscat ist eine sammlung von bausteinen die von einigen wenigen personen in ihrer freizeit erstellt wurden
im dem gesamten paket stecken mehrer tausend arbeitstunden

diese bausteine sind frei nutzbar und opensource - also ein geschenk !

wenn nun jemand der meinung ist das ein baustein anders besser wäre oder besser funktionieren würde dann ist dieser herzlich eingeladen diesen baustein zu verbessern

noch besser ist es wenn du dann den neuen besseren baustein auch noch anderen wieder zur verfügung stellst

[selli69]

hallo peewit!

Ich will hier niemanden angreifen. Die Lib ist wirklich wunderbar und ich bin dankbar dafür, dass ich diese arbeit nicht selbst machen muss.

Doch sind "geschenkt" und "Open Source" keine Argumente um sich Kritik nicht stellen zu müssen. Der Bausten um den es geht funktioniert ja, zumindest dann wenn man sich an Bedingungen hält welche nirgends dokumentiert sind. Und das ist meine Kritik.

Es ist mir vollkommen egal ob das mit eckigen Klammern in Suchstrings funktioniert. Doch es muss dokumentiert sein. Eine Zeile in der Dokumentation einfügen und gut ist. Ich verstehe nicht, wie man sich gegen eine solche Maßnahme derart sperren kann. Mein Anliegen war es EUER Projekt zu verbessern, zu welchem auch die Dokumentation zählt.

Die Zeit in der du mir zwei mal schreibst um mich zum einen für ein bisschen geistig schlicht erklärst und mir dann Open Source erläuterst hätte gereicht um die Dokumentation zehn mal anzupassen. Aber was weis ich schon...

Damit es Dir vllt nicht ganz so schwer fällt, hier der Satz, wie er in die Doku gehört:

"Der Sektionsname darf die Zeichen "[" und "]" nicht enthalten, da eine Suche danach zu unerwarteten Ergebnissen führen kann."

Jetzt ists nur noch ein copy/paste. Zuviel verlangt?