Ini ohne IniFiles Project (WinApi)

[KodeZwerg]

zumindest geh ich kurz auf diesen Punkt ein:

Zitat:

Zitat von himitsu (Beitrag 1472461)

Warum gibt ReadInteger einen Cardinal zurück?

Weil das die WinApi so macht. Sie returned einen Cardinal/UINT.

Danke für den Record Vorschlag!
Wie gesagt, das ist gestern Nacht innerhalb von ein paar Minuten nur per Notepad und Windows SDK entstanden.
Etwaige Fehler oder Prüfung ob Code überhaupt ausführbar ist steht mir noch bevor.

[Daniel]

Zitat:

Zitat von KodeZwerg (Beitrag 1472462)

Etwaige Fehler oder Prüfung ob Code überhaupt ausführbar ist steht mir noch bevor.

Dann muss die Frage erlaubt sein, warum Du ihn in diesem Zustand überhaupt veröffentlichst ... ?

[TiGü]

Immerhin kompiliert das (XE 10.2).

Das Destroy braucht ein

Delphi-Quellcode:

override;

anstatt ein

Delphi-Quellcode:

overload;

!

[KodeZwerg]

Zitat:

Zitat von Daniel (Beitrag 1472463)

Dann muss die Frage erlaubt sein, warum Du ihn in diesem Zustand überhaupt veröffentlichst ... ?

Klar sind Fragen jeder Art erlaubt, mein Hauptpost sagts doch eigentlich schon.

Zitat:

Status: Alpha (nur per Notepad erstellt, noch ungetestet)

Hier stelle ich Euch schonmal meine Grundidee vor

Falls das noch zu ungenau ist, vielleicht so:
Ich sammel auf diese Weise eindrücke bzw verbessere alles nach Kritik oder stampfe Projekt ein.
himitsu's record zBsp = mega! Darauf bin ich Nachts nicht gekommen.

Cool das es kompiliert @TiGü und Danke für's durchlaufen lassen! Klar Override nicht Overload *schäm*

[TigerLilly]

Das

Code:

case s[i] of
  'A'..'Z','Ä','Ö','Ü':
       Result[i] := CHR(Byte(s[i]) + 32);

funktioniert in Unicode-Zeiten doch nicht mehr für die Umlaute?

[KodeZwerg]

@TigerLilly: die kleinen _helfer fliegen zu morgen raus. alles wird intern auf string umgestellt (integer bool etc), leichtere Handhabung und readinteger kann dann auch integer returnen :)

[Rollo62]

Bin ich jetzt der Einzige der mal hinterfragt wie Kompatibel das Ganze ist ?
https://stackoverflow.com/questions/...m-kernel32-dll

Das ist doch meiner Meinung nach für Win-10 gar nicht mehr aktuell,
oder irre ich mich da ?

[himitsu]

Dort war das Problem bei UWP und da bist die mit Delphi sowieso im Arsch, denn Embarcadero weigert sich schon seit 8 Jahren hartnäckig einen Compiler für WinRT/UWP zu bauen.

Das ist leider die einzige INI-API, also geht es nicht anders.
Und dieser Hinweis steht schon seit 25 Jahren dort ... glaub mir, das werden die nicht so schnell ausbauen :angle2:,
auch wenn Microsoft will, dass wir von INI auf die Registry umstellen,
dabei nutzen die selbst massenhaft INIs, überall im System.

Nicht die API ist als deprecated eingestuft, sondern der Speicherort. :zwinker:

Zitat:

Weil das die WinApi so macht. Sie returned einen Cardinal/UINT.

Das kann man ja casten.


Ich hatte mir auch schon eine kleine INI-Klasse gebastelt, die z.B. auch Multiline-Values erlaubt, so wie es andere INI-Libs, z.B. in einigen Games oder für Linux auch anbieten.

[venice2]

Zitat:

für den produktiven Einsatz wird es dann vielleicht doch spannend, ob das selbst geschriebene FileExists auch auf Netzwerkpfaden funktioniert und derlei mehr.

Muss da nochmal drauf eingehen was ist da so schwierig? Und oder spannend.

1.Ich prüfe erst einmal ob es sich um einen Netzwerkpfad handelt.
Dazu vergleiche ich auf "\\" im Pfad.

2.Anschließend prüfe ich ob es sich um ein Remote Laufwerk handelt
über GetDriveType = DRIVE_REMOTE

3. Dann verwende ich WNetGetConnection mit dem Flag ERROR_MORE_DATA
falls der Buffer zu schmal ist alloziere ich einen entsprechenden der dann passt.
Über WNetGetConnection erhält man den UNC Pfad von einem gemappten Laufwerk. (Nur zur Vervollständigung)

4.Gibt der nächst Aufruf von WNetGetConnection NO_ERROR zurück dann wurde der Pfad gefunden.

5.Das alles garantiert mir aber nicht das ich die Datei auch lesen kann.
Also muss ich einen ping absetzen der mir garantiert das der Port auch geöffnet ist um die Datei lesen zu können.
"IsPortAvailable"

6. Wenn dann der Pfad und die Datei existiert "PathFileExists" ist die Rückgabe true.

Wo ist nun das Problem eine Function gleich "FileExists" für ein Netzwerkpfad zu erstellen?
Und ja habe nichts neu erfunden wie schon gesagt ist alles vorhanden.

Habe jetzt nur mal einen möglichen Vorgang beschrieben Code gibt es nicht.
Jeder nutzt halt eine für sich angepasste variante von FileExists die meisten die Vorgekaute.
Ob es jetzt mit Portprobe Probleme mit der Firewall oder anderen Sicherheitssuiten gibt kann ich nicht garantieren muss man halt testen.

Er könnte nun sein _FileExists entsprechend meiner Vorgehensweise anpassen und schon klappt das mit deinen Netzwerkpfaden.

Nachtrag:
Ping ist aber kein Garant das der Server/Client auch wirklich hochgefahren ist.
Deswegen nutze ich eine Portprobe und schau ob ein bestimmter Port vom Server/Client erreichbar ist.
Ist der Port erreichbar ist der Server auch hochgefahren und dann sollte auch der Ordner\Datei erreichbar sein.

[Rollo62]

Um zu Testen ob ein Zugriff nach allen Vortests wirklich machbar ist, z.B. bei mobilen Platformen und deren Verzeichnissen,
Lasse ich auch schon Mal gern eine Temporäre Datei erzeugen und lösche die gleich wieder.
Wenn man ohne Exceptions durchkommt ist Alles IO, und ich kann den echten Zugriff machen.

Ist suboptimal, erfüllt aber seinen Zweck wenn alle möglichen Unwägbarkeiten den Zugriff behindern.