Beiträge

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?

[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.

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

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!