himXML (gesprochen himix ML)

[himitsu]

Soooooo,

ab jetzt wird auf dem Desktop eine etwas detailiertere Fehler-Log erstellt
und dann ohne die __CompareBlocks gearbeitet ... also etwas langsamer, aber es läuft :)

bastell nun noch etwas an den Blöcken rum und lad danach das Update hoch


Wie nennt man das eigentlich, wenn der "Ersteller" der Software kontaktiert werden soll?
(also die Software, wo mein Teil dann drin verbaut ist?)

Zitat:

pleace contact the ....

blöd, wenn ich die VM in meinem schnuckligem 15"er nicht im Vollbild laufen laß -_-°
tja, wo nun anfang des Jahres der PC komplett neu gemacht werden mußte .. da leidet nun geldmäßig der Monitor etwas http://fnse.de/S01/0GU.gif

[edit]
Anhänge entfernt ... ist nun in Post #1 eingebaut ^^

[Satty67]

Zitat:

Zitat von himitsu

pleace contact the ....

in meinem Fall würde ein ...stupid idiot, who made this shit reichen, aber ganz allgemein kommt wohl besser

please contact the developer
please contact the software provider
please contact the software distributor

denke da inzwischen alles über einen Vertieb läuft und nicht mehr über Entwickler/-Studios wäre letzteres logischer, ersteres klingt besser.

[himitsu]

hab das Letzte verbaut :angel:

dann läuft es wieder in bzw. nun auch unter Windows 7


und damit dürften die aktuellen Systemvorausetzungen wie folgt ausehn:

ab Delphi 2006 bzw. Turbo Delphi bis Delphi 2009
Windows 2000 (eventuell auch schon NT) bis Windows 7 RC
(alles bis Win98/ME fällt alleine schon wegen der standardmäßig nicht vorhandenen Unicodeunterstützung weg)


Update siehe #1

[Satty67]

Auch hier mit der neuen Version keine Probleme mehr, wenn das von Interesse ist.

Hatte schon eine eigene XOR Verschlüsselung für Strings (vorgelagert) implementiert und teste die laufende Woche mal das neue Feature mit XMLfile direkt zu verschlüsseln.

[himitsu]

*freu* :-D

eigentlich nur Kleinigkeiten

• Zeilenzählung wärend des Parsens integriert ... jetzt wird auch entlich mal die Zeile direkt angezeigt und nicht nur die Byteposition innerhalb der Datei, wenn es beim Parsen zu einem Fehler kommt.
• und mal nix mit der Lib selber, aber es gibt eine neue Demo > Demo_Tree2 < , welche sich kaum von der "1" unterscheidet, außer daß der TTreeView nun dynamisch gefüllt wird ... also quasi fast, wie man es von der VTV kennt.
  So ist nun z.B. die eine ~30 MB-XML-Test-Datei in knapp 6 Sekunden geladen und "teilweise" RAM-sparend im TreeView verfügbar.

[edit]
hab noch etwas an der Demo2 rumgespielt
hier das Ergebnis (jetzt nicht extra alles nochma neu hoch)
- auf-/zuklappen des Trees verbessert usw.

[edit]
Anhang entfernt ... ist nun in Post #1 enthalten (demos\Demo_Tree2.dpr)

[Mithrandir]

Sodele,

ich bin jetzt in der Situation, dass ich TXMLDatabase bräuchte. Machste das gleich noch fertig? :mrgreen:

Ginge auch ohne, wäre aber... "hübscher".... :stupid:

[Satty67]

Wobei ich mir das zimlich elend vorstelle, DataSet/DataSourec erwarten eine Tabellstruktur (denke ich) und XML kann ja alles sein... Tabelle, Baum, Liste etc.

Andere Frage, ist die Frage nach einer Lizenz schon geklärt. Hab' jetzt gar nicht ins letzte Archiv geschaut, ob da schon was vermerkt ist. Eine mögliche Verwendung von himXML in ClosedSource Applikationen wäre wirklich nett. Ein nicht kommerziell vertriebenes, aber kommerziell angewendetes Programm soll für Einstellungen und eine Exportfunktion mit himXML ausgestattet werden.

[himitsu]

also die Lizenz ist geklärt ... siehe Post #1 mißt, dacht ich hätt's da schon reingeschrieben :shock:

Zitat:

MPL v1.1 , GPL v3.0 or LGPL v3.0

und was die DB angeht, das Format in XML ist schon fast klat, im Grunde kann man alles als Baum ansehn
> Hauptknoten > Tabellen > Spalten/Felder > Daten

aber erstmal versuch ich es so mySQL-mäßig, wie aus PHP bekannt, zu machen und dann muß ich mal sehen, wie man es mit DataSet/DataSource verknüpfen kann ()kab noch keine Ahnung, wie Letzeres intern arbeitet und wie man dann da rangehn müßte.

[Mithrandir]

Naja, ne Anbindung ans TDataset brauch ich nun nicht unbedingt. Aber SQL-Statements fände ich irgendwie geil. :)


Aber zwei Fragen haben sich doch noch gestellt. Hab mir bei Wikipedia den Artikel über XML angesehen, aber keine Antwort gefunden:

• Gibt es eine Beschränkung bei der Anzahl der Zeichen pro Zeile?
• Ziffern als Knotenbezeichner sind nicht erlaubt?

Hintergrund: Meine XML-Datei sieht so aus:

XML-Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<xml>
  <ETNT>
    <weather metarstring="ETNT 291720Z 04006KT 9999 FEW220 22/15 Q1019 BLU+" temperature="22" humidity="65" dewpoint="15" altimeter="1019" metartime="2009-06-29T17-20-00.000" currenttime="2009-06-29T19-59-42.437" winddir="2" intensity="1" descriptor="1" obscuration="1" precipitation="1" other="1" cloudcover="2" altimeterunit="0" speedunit="2" />
    <weather metarstring="ETNT 291720Z 04006KT 9999 FEW220 22/15 Q1019 BLU+" temperature="22" humidity="65" dewpoint="15" altimeter="1019" metartime="2009-06-29T17-20-00.000" currenttime="2009-06-29T20-02-30.156" winddir="2" intensity="1" descriptor="1" obscuration="1" precipitation="1" other="1" cloudcover="2" altimeterunit="0" speedunit="2" />
    <weather metarstring="ETNT 291720Z 04006KT 9999 FEW220 22/15 Q1019 BLU+" temperature="22" humidity="65" dewpoint="15" altimeter="1019" metartime="2009-06-29T17-20-00.000" currenttime="2009-06-29T20-02-30.156" winddir="2" intensity="1" descriptor="1" obscuration="1" precipitation="1" other="1" cloudcover="2" altimeterunit="0" speedunit="2" />
    <weather metarstring="ETNT 291720Z 04006KT 9999 FEW220 22/15 Q1019 BLU+" temperature="22" humidity="65" dewpoint="15" altimeter="1019" metartime="2009-06-29T17-20-00.000" currenttime="2009-06-29T20-04-34.375" winddir="2" intensity="1" descriptor="1" obscuration="1" precipitation="1" other="1" cloudcover="2" altimeterunit="0" speedunit="2" />
  </ETNT>
  <EDDH>
    <weather metarstring="EDDH 291750Z 05007KT 9999 FEW042 23/14 Q1019 NOSIG" temperature="23" humidity="57" dewpoint="14" altimeter="1019" metartime="2009-06-29T17-50-00.000" currenttime="2009-06-29T20-04-07.281" winddir="2" intensity="1" descriptor="1" obscuration="1" precipitation="1" other="1" cloudcover="2" altimeterunit="0" speedunit="2" />
  </EDDH>
</xml>

Muss ich da irgendwie mit Problemen rechnen?

[himitsu]

Theoretisch gibt es da keine Längenbeschränkung ... wäre auch blöd, wenn man die XML kompackt und ohne Zeilenumbrüche erstellen ließe. :zwinker:
(obwohl einige XML-Editoren eine Grenze drin haben ... z.B. hat die Delphi IDE ab 1024 Zeichen pro Zeile arge Probleme und schneidet den Rest ab, Notepad bricht dan wenigstens "nur" um)

Aber bei der Base64-Codierung wird dennoch (meißten) aller 'ner gewissen Zeichenzahl eine Trennung reingemacht.

Nur die SQL-Statements machen einige Probleme:
- ich hab quasi keine Ahnung von Parsern (drum übe ich grad erstmal an einem kleinem Mathe-Parser zur StringMathLib)
- dann muß ich auch noch einen "schönen" Befehlssatz für die SQL-Statements zusammenbekommen
- und zusätzlich noch überlegen ob/wie ich eine "schnelle" zusätzliche Indizierung der Schlüsselfelder hinbekomm (wenn ich welche zulaß)

[Mithrandir]

Hm... Aber Zahlen kann ich immer noch nicht als Knotenbezeichner benutzen, oder? :stupid:

[himitsu]

Als Index, um auf existierende Knoten zuzugreifen schon,
Zahlen (z.B Integer) als Bezeichner wäre schwer, da es dann keine Unterscheidung zwischen Bezeichner und Index gäbe.

[Mithrandir]

:gruebel:

Also, nicht als Integer, sondern als String:

Delphi-Quellcode:

TWH.XML.Node['EDDH'].Node('2009').Node['Juni'].Node['30'].Attribute['haha'] := 'Putzilein';

Code:

---------------------------
Project1
---------------------------
EXMLException (TXMLNodeList.Add):

invalid name.
---------------------------
OK   
---------------------------

[Zwoetzen]

Soweit ich weiß müssen laut XML die Bezeichner für die Knoten mit einem Buchstaben beginnen, eine Ziffer als erstes Zeichen ist nicht zugelassen (wie in Delphi eben ;))

[Mithrandir]

*knirsch*

Ok, danke. Dann muss ich mir was überlegen. Und wenn ich da ein "Y", "M" oder "D" vorklatsche. :mrgreen:

[himitsu]

Zitat:

Zitat von Zwoetzen

Soweit ich weiß müssen laut XML die Bezeichner für die Knoten mit einem Buchstaben beginnen, eine Ziffer als erstes Zeichen ist nicht zugelassen (wie in Delphi eben ;))

achso, sowas :wall:

nee, als erstes Zeichen eines Bezeichners sind laut XML-Speck keine Zahlen erlaubt :nerd:

Code:

ANSI:
erstes Zeichen     '_', ':', 'A'..'Z', 'a'..'z', 'À'..'Ö', 'Ø'..'ö'
folgende Zeichen   '_', ':', 'A'..'Z', 'a'..'z', 'À'..'Ö', 'Ø'..'ö', '-', '.', '0'..'9', '·'

Unicode:
erstes Zeichen     '_', ':', 'A'..'Z', 'a'..'z', #$00C0..#$00D6, #$00D8..#$00F6, #$00F8..#$02FF,
                   #$0370..#$037D, #$037F..#$1FFF, #$200C..#$200D, #$2070..#$218F, #$2C00..#$2FEF,
                   #$3001..#$D7FF, #$F900..#$FDCF, #$FDF0..#$FFFD
folgende Zeichen   '_', ':', 'A'..'Z', 'a'..'z', #$00C0..#$00D6, #$00D8..#$00F6, #$00F8..#$02FF,
                   #$0370..#$037D, #$037F..#$1FFF, #$200C..#$200D, #$2070..#$218F, #$2C00..#$2FEF,
                   #$3001..#$D7FF, #$F900..#$FDCF, #$FDF0..#$FFFD,
                   '-', '.', '0'..'9', #$00B7, #$0300..#$036F, #$203F..#$2040

[add]
ich könnte diese Grenze in meiner Lib zwar abschaltbar machen, aber dann müßten andere Libs bei derartigen Bezeichnern rummotzen, falls sie soeine Datei abbekommen.

[Mithrandir]

Dann wäre der _ auch eine Alternative. :stupid: Warum das erste Zeichen keine Ziffer sein darf, erschließt sich mir allerdings nicht wirklich... :gruebel: Komische Specs...

//Edit: Oder ich manipuliere die Lib.. Muahahaha... :twisted: :twisted:

[himitsu]

Zitat:

Zitat von Daniel G

Dann wäre der _ auch eine Alternative. :stupid: Warum das erste Zeichen keine Ziffer sein darf, erschließt sich mir allerdings nicht wirklich... :gruebel: Komische Specs...

//Edit: Oder ich manipuliere die Lib.. Muahahaha... :twisted: :twisted:

tssstssstsss :twisted:

mir erschließt sich das auch nicht wirklich,
außer wie bei Bezeichnern in Delphi und Co., aber eigentlich dürfte dieses da keine Probleme gegen.

[xZise]

Zitat:

Zitat von Daniel G

Delphi-Quellcode:

TWH.XML.Node['EDDH'].Node('2009').Node['Juni'].Node['30'].Attribute['haha'] := 'Putzilein';

Code:

---------------------------
Project1
---------------------------
EXMLException (TXMLNodeList.Add):

invalid name.
---------------------------
OK   
---------------------------

Könnte man nicht in der Fehlermeldung nicht auch den Pfad oder Name angeben :D So weiß man, dass es sich (wahrscheinlich) um "EDDH\2009" handelt.

MfG
xZise

[himitsu]

joar, könnte man ... ich bastle eh ständig noch etwas an schöneren und "verständlicheren" Exceptions rum :angel2:
(anfangs hießen alle noch 'Fehler' und man wußte nicht aus welcher Funktion sie kommen :lol: )

PS:

Delphi-Quellcode:

TWH.XML.Node['EDDH\2009\Juni\30'].Attribute['haha'] := 'Putzilein';
// bsw.
TWH.XML.Attribute['EDDH\2009\Juni\30\haha'] := 'Putzilein';

[Zwoetzen]

Die besten Fehler sind doch sowieso:

---------------------------
Project1
---------------------------
Es ist ein Fehler aufgetreten
---------------------------
OK Abbrechen
---------------------------

:lol:

[himitsu]

Zitat:

Zitat von Zwoetzen

---------------------------
Project1
---------------------------
Es ist ein Fehler aufgetreten
---------------------------
OK Abbrechen
---------------------------

also das ist definitiv keine meiner Exceptions ... kann mich jedenfalls nicht erinnern irgendwo sowas noch verbaut zu haben. :shock:

außerdem sollten alle meine selbstausgelösten Exceptions mindestens den Namen der Funktion enthalten, worin diese erzeugt wurde.

[edit] und selbst in den Delphi-Sourcen konnte ich soeine Meldung nicht finden ... könnte also vermutlich eine Windows-Meldung sein :gruebel:

[Zwoetzen]

Das war nicht auf himiXML bezogen, sondern allgemein auf Programme, wo man sowas ab und zu mal zu gesicht bekommt ;)

(Sorry, falls das nicht direkt klar rübergekommen ist :oops: )

[Zwoetzen]

Hmm wollte jetzt mal ein wenig mit himXML arbeiten, doch bekomme ich beim Versuch einen XML-String zu setzen nur ein

Zitat:

Zitat von himXML

EXMLException (TXMLFile.ReadData):
invalid file encoding.

Ich vermute, dass es da einfach Probleme mit den verschiedenen String-Typen gibt, nur kenn ich mich da nicht sonderlich gut aus ^^
Könntest du mir sagen, wie es richtig heißen muss? Momentan verwende ich (aufs Problem angepasst):

Delphi-Quellcode:

var
  XML: TXMLFile;
begin
  XML := TXMLFile.Create;
  try
    //XML.asXML := FContent;
    XML.asXML := '<root>â</root>'; // <-- Hier macht es Bumm
  finally
    XML.Free;
  end;
end;

Wie gesagt, ich denke, es wird an der (impliziten) Umwandlung String -> AnsiString liegen, habe auch schon bissl probiert, aber mangels Wissen war ich nicht wirklich erfolgreich.

Würde mich freuen, wenn du mir helfen kannst :)

MfG Zwoetzen


PS: Habe auch nen Tippfehler in einer Fehlermeldung entdeckt:

Zitat:

Zitat von himXML

EXMLException (TXMLNodeList.Add):
text node can't constain subnodes.

Ich denke das s in "constain" ist zu viel (wollte dich nur mal drauf hinweisen auch wenn die Fehler wohl nochmal geändert werden :mrgreen: )

[Satty67]

Ist ja auch kein vollständiges XML, sowas würde gehen:

Delphi-Quellcode:

XML.asXML := '<?xml version="1.0" encoding="UTF-8" standalone="yes" ?><root>â</root>';

oder

Delphi-Quellcode:

XML := TXMLfile.Create(self, 'root');
XML.RootNode.Text := 'â';

€: hast soweit recht, dass das Zeichen â scheinbar (bei asXML) für Verwirrung sorgt. Konnte jetzt auch nicht ermitteln, unter welcher Zeichencodierung das auch so in der Datei steht und damit eine gültige XML-Struktur wäre.

Das funktioniert auch nicht, sollte es aber, da das eine gültiges XML ist

Delphi-Quellcode:

XML.asXML := '<?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?><root>â</root>';

Sieht so aus, als ob asXML an der UTF-8 Kodierung festhält

[Zwoetzen]

Danke für deine Antwort :)

Die erste Variante ändert nix: Selbst mit ordentlichem XML-Header kommt der Encoding-Fehler.

Der zweite Vorschlag bringt etwas Besserung, allerdings erhalte ich später dann die Meldung

Zitat:

Zitat von himXML

EXMLException (TXMLNodeList.Add):
text node can't constain subnodes.

wenn ich versuche, auf einen Knoten zuzugreifen.
Ich denke es hängt damit zusammen, das himXML bei der Zuweisung an .TExt davon ausgeht, dass es wirklich nur Text ist, und somit diesen nicht weiter parst.

Ich habe auch probiert, statts .Text das .XMLText zum zuweisen zu verwenden, doch dann bekomme ich den Fehler

Zitat:

Zitat von himXML

EXMLException (TXMLFile.ParsingTree):
unexcepting end of data - not all opened tags are closed

error at byte position 11.498 ("#000D#000A " on line 75)

wobei der zugewiesene String wohlgeformtes XML ist.



Als Information:
Die Quelldaten habe ich mit zuvor als XHTML-Datei aus dem Internet geladen, und bereits das genauer zu analysierende <div> extrahiert. Das heißt ich habe ein <div> als Wurzelknoten im String, was dann natürlich alles mögliche noch enthält. Der extrahierte Code ist dabei gültiges XHTML, sollte also keine Probleme geben.
Das Dokument liegt dabei als UTF-8 vor, und ich lade es mittels IdHTTP.Get in einen String. Nach ein paar String-Operationen (Extrahieren des gewünschten divs) will ich diesen nun als XML interpretieren lassen um ihn weiter analysieren zu können (wird sonst mot Pos/PosEx etwas mühselig ^^).


(Btw: Habe ich schon erwähnt, dass ich Delphi2009 unter Windows7 verwende? Keine Ahnung, ob das irgendwie Auswirkungen hat, Delphi2009 wird laut erstem Post auf jeden Fall unterstützt, Windows7 laut Seite 5 des Threads oder so auch.)

[himitsu]

Unter Delphi2009 wird es hauptsächlich entwickelt und dann abund zu mal in TDE und D7 getestet
und Windows (auch Windows 7) hat eigentlich nur einen Einfluß auf die caseinsensitiven Namensvergleiche und wa wurd ja vor Kurzem alles an Win7 angepaßt und nun auch eine Notfallalternative implementiert,
also da sollte es zumindestens keine Probleme mehr geben ... es hängt also nur noch von der Delphiversion ab.

<root>â</root> ist insofern eine ungültige Codierung, da XML ohne Angabe einer Codierung standardmäßig UTF-8 ist.

Node.Text nimmt nur "Text" entgegen, welcher in dem Node gespeichert wird, ansonsten gibt es noch Node.XMLText, welches eine XML-Struktur entgegennehmen würde (ähnlich zu Document.asXML).

Document.asXML wird nur an LoadFromXML/SaveToXML weitergeleitet und sollte eigentlich auch andere Codierungen verstehen können. :gruebel:

Wegen dem Rest muß ich dann mal in Ruhe schauen (hab hier grad kein Delphi und auch etwas wenig Zeit)

[Zwoetzen]

Danke für deine Antwort.
Nehm dir ruhig die Zeit, die du brauchst, vorrübergehend arbeite ich mit einer "korrigierten" Version der XHTML-Datei, wo ich die ganzen Sonderzeichen korrigiert habe, sodass die Datei problemlos eingelesen kann und ich die Auswertung schonmal programmieren kann ;)



Allerdings bin ich da schon auf einen nächsten Fehler gestoßen:

Test-Prozedur:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
const
  S: String = '<root>Some Text<child>Ding</child>Something else</root>'; // <-- Sollte gültiges XML sein
var
  XML: TXMLFile;
begin
  XML := TXMLFile.Create;
  try
    XML.asXML := S;
    ShowMessage(XML.RootNode.XMLText);
  finally
    XML.Free;
  end;
end;

Normalerweise würde man davon ausgehen, dass man nun als Ausgabe genau den Teil zwischen den <root>-Tags bekommt, allerdings erscheint:

Zitat:

Zitat von ShowMessage

Some Tex
<child>Ding</child>
Something els

Das bedeutet, dass sowohl das letzte Zeichen vor dem öffnenden <child> als auch vor dem schließenden </root> fehlt. Habe es mit verschiedenen Werten probiert, es scheint immer genau ein Zeichen zu fehlen.

[himitsu]

Also das asXML bzw. XMLText nimmt wirklich keine anderen Kodierungen an, da hab ich wohl etwas "falsch" bedacht, wird mit dem nächsten Update geändert.
(nur das dauert noch etwas, da sich grad einiges ändert und noch nicht alles fertig ist)

Du könntest aber deinen Text in einen Stream und das XML dann von dort laden.

in etwa so:

Delphi-Quellcode:

var MS: TMemoryStream;
  Text: AnsiString;

MS := TMemoryStream.Create;
MS.WriteBuffer(Text[1], Length(Text));
MS.Position := 0;
XML.LoadFromStream(MS);
MS.Free;

Zitat:

<root>Some Text<child>Ding</child>Something else</root>

Ist kein valides XML ... dieses ist nur eine "Untat", welche aus HTML bekannt ist.
Ein Knoten enthält entweder Unterknoten oder Text,
aber ich eigentlich sollte sowas schon möglich sein, da über die Option xoAllowUnknownText (standardmäig gesetzt), bei derartigem Text-Knoten-Mischmasch der Text jeweils in Unterknoten vom Typ xtUnknown ausgelagert werden sollte,
allerding klappt das nicht unter allen Umständen.
Mein letzter Versuch verlief da nicht so gut > http://www.delphipraxis.net/internal...042683#1042683 ,
wobei HTML selber ja kaum noch ein valides XML darstellt.

[Zwoetzen]

Das mit der Kodierung muss ich ein andern mal in Ruhe anschauen, auf Anhieb hatte es grad nicht geklappt.


Aber zu dem "Fehler":
Sollte XHTML nicht eigentlich valides XML sein? (Dass HTML keins ist, ist klar, dachte bisher, dass XHTML eigentlich gültiges XML sein sollte.)

Und mal von dem valide abgesehen: Sollte nicht das, was "reingetan" wird, bei .XMLText auch 1:1 wieder rauskommen? Denn ich würde es so verstehen, dass .XMLText den Inhalt eben 1:1 wiedergibt. (Ok, wenn der Testcode nicht erlaubt ist, ist die Korrektheit natürlich nichtmehr garantiert.)

[himitsu]

.XMLText:
Also in himXML wird der eingelesene/geparste Text ja in seine Einzelteile zerlegt und nur die enthaltenen Informationen gespeichert.
Beim "Auslesen" dieser Eigenschaft wird der XML-Text dann neu zusammengebaut.

Klar könnte ich jetzt noch alle möglichen Zusatzinfos über die ursprüngliche Textformatierung mit speichern, aber das wollte ich nicht ... ist mehr Aufwand, benötigt mehr Speicher und vorallem bremst es alles aus.

Das ist gerade ein Vorteil gegenüber dem MSXML-DOM ... die Geschwindigkeit und der Speicher

Und außerdem kommt es hier ja mehr auf den Inhalt und nicht das Datenformat an. :angel2:

XHTML ist ja "nur" ein Mischmasch aus HTML und XML,
aber wie gesagt, ich bin dabei einige "Restiktionen" zu lockern und "Umwege" einzubauen, aber alles werd' ich wohl nie hinbekommen, da ich vorwiegend nur Fehlererkennungen einbau und keine Fehlerbehebung (die Parser der großen Browsern könn ja nahezu jedes Problem gekonnt "ignorieren", was aber och blöd ist, da gerade deswegen viele Internetseiten eigentlich "defekt" sind, aber es läuft halt, drum läßt man es so)

[himitsu]

Zitat:

Zitat von Daniel G

Hm... Aber Zahlen kann ich immer noch nicht als Knotenbezeichner benutzen, oder? :stupid:

wie ich grad bemerke ... gib für den Node einen Namespace an und schon ginge ex :mrgreen:

ich weiß allerdings grad nicht, ob der Name so auch noch der XML-Spec entspricht,
aber selbst wenn ich das ändern sollte ... ich leg grad eine neue Option an, wo man die Namensprüfung etwas lockern kann könnte.

z.B. "num:123" um es leicht wieder zu trennen oder es getrennt zu setzen, kannst du die Möglichkeiten für die Namespacebehandlung des Nodes nutzen (.Namespace und .NameOnly).

[himitsu]

ich weiß, es gab 'ne Weile kein Update, aber nun geht's weiter

hier mal der aktuelle Stand (abgesehn von einigen Problemchen läuft es erstmal/wieder)

• die Exceptions wurden alle fast komplett überarbeitet
  und liefern zusätzlich nun auch ein paar Infos mehr
  (z.B. den "falschen" Nodenamen, welcher bemängelt wurde)
  
• die DLL-Version läuft auch (anscheinend)
  - der Memory Manager der EXE wird zur DLL durchgeshleift
  - die Klassen der DLL sind in der EXE verlinkt (die RTTI wird zur Laufzeit übertragen)
  - die Behandlung von Exceptions in der DLL wird an die EXE weitergereicht
  
• die Pfade zu den Units werden jetzt nichtmehr in den Demos/Testprogrammen per IN-Statement angegeben, sondern über die Suchpfade
  - welche das sind (z.B. für ältere Delphi-Versionen) steht im Dateiheader
  
• die globalen Kompilerschalter werden nicht mehr in der Interfaceunit (himXMLi.pas) angegeben
  dieses kann jetzt für jedes Projekt einzeln in den Projektoptionen angegeben werden
  (bei Wechsel des aktiven Projektes sollte das Projekt neu erzeigt werden, da Delphi bei Änderung der Optionen sonst vergißt die Units neu zu kompilieren :? )
  - Infos zu den möglichen Kompilerschaltern siehe Hilfe-Abschnitt in himXMLi.pas
  
• der SAX-Parser und einige der neuen Klassen in den Tools sind noch nicht fertig
• und die Interface-Version der DLL muß ich demnächst auch mal überarbeiten und versuchen die Fehler in der Referenzzählung zu finden

Datei siehe Post #1



Bezüglich einiger der Probleme der letzen 2 Seiten, wie z.B. die Kodierung usw.,
werd' ich mich jetzt erstmal damit etwas beschäftigen und versuchen alles nachzuvollziehen.

Falls einer 'ne Testdatei hat, wo etwas nicht läuft, könnte er sie mir ja gern mal zur Verfügung stellen.

[himitsu]

hab grad die EXMLException überarbeitet

- ein netter Fehler in der Paremeterbehandlung in der Exceptionsklasse wurde behoben
('ne Exception in der Exception, welche den eigenentlichen Fehler verbarg)
- überlange Fehlertexte werden abgeschnitten (also hier z.B. eingeblendete Name)
- Steuer- und Unicodezeichen werden umgewandelt und Hexadezimal angezeigt

bei diesem

Delphi-Quellcode:

XML.Node['EDDH'].Node['2009'].Node['Juni'].Node['30'].Attribute['haha'] := 'Putzilein';
XML.Node['EDDH\2009\Juni\30'].Attribute['haha'] := 'Putzilein';
XML.Attribute['EDDH\2009\Juni\30\haha'] := 'Putzilein';

kommt also nun sowas raus (wenn NodeAutoCreate aktiviert ist)

Zitat:

---------------------------
Test
---------------------------
EXMLException (TXMLNodeList.Add):

invalid name ("2009")
---------------------------
OK
---------------------------

Wenn NodeAutoCreate nicht aktiv ist, dann würde Node[] ein nil zurückliefern,
darum hab ich mir grad überlegt noch eine weitere Option anzubieten, welche dann mit einer "Node existiert nicht"-Exception um sich wirft (dieses sollte dann die Zugriffsverletzung auf "nil" verständlicher machen) ... also beim nächsten Update vermutlich dann mit enthalten

[himitsu]

aus Post #108

Zitat:

Zitat von Zwoetzen

Allerdings bin ich da schon auf einen nächsten Fehler gestoßen:

Test-Prozedur:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
const
  S: String = '<root>Some Text<child>Ding</child>Something else</root>'; // <-- Sollte gültiges XML sein
var
  XML: TXMLFile;
begin
  XML := TXMLFile.Create;
  try
    XML.asXML := S;
    ShowMessage(XML.RootNode.XMLText);
  finally
    XML.Free;
  end;
end;

Normalerweise würde man davon ausgehen, dass man nun als Ausgabe genau den Teil zwischen den <root>-Tags bekommt, allerdings erscheint:

Zitat:

Zitat von ShowMessage

Some Tex
<child>Ding</child>
Something els

Das bedeutet, dass sowohl das letzte Zeichen vor dem öffnenden <child> als auch vor dem schließenden </root> fehlt. Habe es mit verschiedenen Werten probiert, es scheint immer genau ein Zeichen zu fehlen.

da war ein kleiner "Trim"-Fehler in Bezug auf den Nodetyp xtUnknown, welcher in der Prozedur AssembleTree jeweil ein Zeichen zuviel entfernte :oops:

beim Einlesen war alles noch OK und auch wärend man mit dem Bäumchen arbeitete ... es verschand also nur wärend des Speicherns :angel2:

hab auch gleich mal die restlichen verbliebenen (langsameren) Suchschleifchen in ParsingTree ersetzt und ebefalls nach TXMLFile.ParsingTree._Search verlagert :stupid:

Update siehe Beta in Post #1

[himitsu]

• [add] die Exceptions hab ich auch noch etwas umgebaut
  - z.B. wird jetzt bei allen Exceptions wärend des Parsens die aktuelle Dateiposition angezeit
  - aber was Kodierungsfehler angeht ... da wird nur die etwaige Position genannt, also den Start der aktuellen Leseposition entsprechende des Lesepuffers (standardmäßig 32 KB).
  eine genauere Positionsangabe ist derzeit noch nicht vorgesehn (bissl aufwendig) ... kümmere mich da erstmal um andere Dinge
  
• hab noch 'nen kleinen Fehler in ReadBOM behoben ... da wurden alle Vorgaben auf UTF-8 zurückgesetzt, wenn kein BOM gefunden wurde ... lso Vorgaben waren wirkungslos
  
• die Interface-Verion läßt sich schonmal wieder kompilieren und sieht garnicht soooo schlecht aus ...
  nun muß ich nur noch irgenwann mal das mit der defekten Referenzzählung hinbekommen
  
• dieses geht nun also
  
  Delphi-Quellcode:

  Var S: AnsiString;
  
  S := '<root>â</root>';
  XML.LoadFromXML(S, xeIso8859_1, False);
  
  XML.LoadFromXML('<root>â</root>', xeIso8859_1, False);
  
  // bzw. direkt für D2009 (sonst würde die UnicodeVersion aufgerufen
  // und Unicode nach ISO-8859 geht nicht mehr)
  XML.LoadFromXML(AnsiString('<root>â</root>'), xeIso8859_1, False);

• wollte eigentlich noch dieses unterstützen,
  
  Delphi-Quellcode:

  XML.asXML[xeIso8859_1] := '<root>â</root>';

  aber leider klappt das mit den Vorgabewerten bei den Parametern nicht :cry:
  und man müßte immer eine Kodierung angeben.
  also hab ich's weggelassen und es ist da immer UTF8
  
• die bisher freie Umschaltmöglichkeit der Kodierung wurde begrenzt und es kann nur noch umgeschaltet werden (via Prozessor-Style-Tag <?xml encoding="..."?> ), wenn der Zeichensatz mindestens eine gleich große Char-Size aufweist.
  
  also von Unicode nach UTF-8 umschalten geht nicht mehr
  - Grund dafür sind die Änderungen, welche einem nun erlauben das Encoding vorzugeben/abzuschalten
  und weshalb ich selber nicht mehr die volle Kontrolle über die Kodierung/Speicherbelegung hab.
  ein halbes Char in einem UnicodeString ist halt nicht möglich und darum mußte ich eine Sperre einbauen.
  
• dann hab ich mir mal erlaubt die Dateiheader und settings aufzuräumen
  
• da Delphi ja einige Probleme mit geänderten Compilerschaltern in den Projektoptionen hat:
  + mit der includen der himXMLCheck.inc, nach dem Usesabschnitt, kann nun im eigenen Projekt geprüft werden, ob die Units des himXML mit den selben Basisoptionen kompiliert wurden, wie das Projekt
  + in meinen Units wurde eine ähnliche "Selbstüberwachnung" ebenfalls integriert
  > es gibt dann eine Compilerwarnung, welche auffordert die Units neu zu compilieren

[himitsu]

Ups, da gab's nen größeren Fehler in der Encodierung :oops:

Der reichte von falscher Decodierung, über fälschlicher Beschuldigung einer falschen Codierung, obwohl sie womöglich doch korrekt war,
über einen Pufferüberlauf, bzw. einer Exception, weil außerhalb des Puffers lesend zugegriffen wurde

Grund: der Lesepuffer wurde bei Änderung der Codierung (via <?xml-Tag) falsch geleert und der Zeiger nicht zurückgesetzt :?

Update siehe Post #1 > v0.94

[holliesoft]

Hi,

ich nutze seit einigen Wochen himXML für einen kleinen RSS Feedreader und habe mit der neuesten (Beta)Version vom 18.07. leider das Problem, dass beim Parsen einiger Feeds (u.a. bei der DP) ein Fehler auftritt.

Hier der Text von der himXML Exception:

Delphi-Quellcode:

EXMLException (TXMLFile.ParsingTree):
invalid closing tag - node #0022description#22 is not opened

error at byte position 389 ("</description>#0A    <image>#0A#09   <title>Delphi-PRAXiS</title>#0A#09   <url>http://www.delphipraxis.net/misc/banner/banner_dp_130_100.g..." on line 1)

Anbei die XML-Datei...

Gruß
Patrick

[himitsu]

Also hier kann ich mal beruhigt die Schuld dem bösen Daniel R. Wolf in die Schuhe schieben, :angel2:

denn die angehängte Datei ist nicht korrekt kodiert, bzw. enthält ungültige Zeichen.
z.B. das Markierte #$0F im Anhang Unbenannt.png .
Dieses Zeichen ist laut Spezifikation in XML-Dateien nicht als gültiges "Char" definiert.

Aber zum Glück hab ich für so'nen Fall schon vorsorglich vorgesorgt. :mrgreen:

Lösung:
laß "ungültige" Zeichen in ein Leerzeichen umwandeln

Delphi-Quellcode:

XML.Options := XML.Options + [xoChangeInvalidChars];
XML.LoadFromFile('..\Feed_1242DP.xml');

Und ich überleg mir grad, ob ich diese Option nicht gleich mit in die Standardoptionen aufnehmen soll? :gruebel:

[himitsu]

eigentlich kaum erwähnenswert, aber da ich vorhin eine Nachricht bekam, daß etwas nicht mehr geht ...

• die Interfaces werden jetzt wieder richtig "deaktiviert", wenn sie nicht benötigt werden, da einige Compiler (D2006 & D2007) nicht mit überladenen Defaultproperties in Interfaces klar kommen.
• es wurden die Projektdateien für's "alte" BDS hinzugefügt (*.bdsproj & *.groupproj), damit auch diese Nutzer in den Demos die voreingestellten Suchpfade der Projektoptionen nutzen können.