Seltsames Memo LoadFomFile inculde Phänomen

[himitsu]

Wieso hab ich das gepostet?

Hab es "gefährlich" genannt und genug Gründe erwähnt es besser sowas nicht zu machen, was Uwe auch grade nochmal anschaulich demonstriert hat. :roll:
(bis auf spezielle Sonderfälle macht man sowas einfach nicht, welche hier nicht vorliegen, wenn man die Funktion reparieren würde)

True ist nunmal nicht als 1 (die Konstante True) deklariert, sondern als <>0, was die automatische Booleanauswertung ordentlich berücksichtigt.

[Sailor]

Wer so was macht, gehört abgemahnt und im Wiederholungsfall gefeuert.
Oder macht Ihr auch das?

Code:

PROCEDURE Main;
 VAR
  myString: String;
         i: Integer;

 BEGIN
  Move('1234',i,4);
  IF i = 1234 
   THEN Writeln('OK!')
   ELSE Writeln('Shit!')
 END;

Man kann mit einem Hammer Nägel in die Wand oder sich auf den Daumen hauen. Ich ziehe ersteres vor. Na ja, war OT und damit Ende Gelände.

[mkinzler]

War ja nur ein Beispiel. Eine weiteres wäre der andere Wert für die Konstante True in der Sprache C, also auch alle Rückgaben von WinAPI Funktionen.

Die Konstante hat in Delphi den Wert 1 in C das binäre Komplement zu False ( 0) nämlich -1!
Und 1 ist was anderes als -1!

als True <> True.

[Sailor]

@Himitsu:
True ist nunmal nicht als 1 (die Konstante True) deklariert, sondern als <>0, was die automatische Booleanauswertung ordentlich berücksichtigt.

Nein, True ist nicht als <> 0 deklariert, sondern in Delphi so implementiert. True ist True und nicht 0 oder 3.5 oder HmstlBmpl. Implementierungsdetails haben in einem Programm nichts zu suchen. Das fällt einem sofort auf die Füße, wenn man z.B. unter Delphi entwickelt und dann auf andere Pascalsysteme portiert. Haben wir jahrelang so gemacht, erfolgreich. Mit obigen Tricks wären wir wohl ziemlich auf die Nase gefallen.

@MKinzler
Wenn ich mich außerhalb meiner Sprache bewege, muß ich eben aufpassen. Lies mal Integerwerte ein, die von einer IBM/360 stammen. In C gibt es im Unterschied zu Pascal keinen Wert True, das ist dort ein
#define true -1.

Aber nu is wirklich gut.

[Ajintaro]

Hi,

vielen Dank für eure Impulse. Meine Validierungsfunktion soll bei fehlerfreier Validierung TRUE zurückgeben und ansonsten FALSE. Ich dachte mit dem try-Block kann ich genau das erreichen. Aber jetzt frage ich mich, ob ich die Funktion nicht grundlegend ändern sollte.


Allerdings haben wir uns etwas vom Kurs abbringen lassen :)
Ich bin mir jetzt immer noch nicht sicher, wie ich den bekannten Pfad der includes so setzen kann, damit diese auch Berücksichtigung findet.

Läuft nicht:

Delphi-Quellcode:

xsd := 'C:\test.xsd';
memo_xsd.Lines.LoadFromFile(xsd);
//do validation...

Läuft:

Delphi-Quellcode:

if OpenTextFileDialog1.Execute then memo_xsd.Lines.LoadFromFile(OpenTextFileDialog1.FileName);
//do validation...

Wie mjustin bereits erwähnt hat, wird beim Benutzen des opendialogs "das Verzeichnis" richtig gesetzt, während bei LoadFromFile dies nicht der Fall ist. Was macht denn der opendialog im Detail anders?

[Uwe Raabe]

Zitat:

Zitat von Ajintaro (Beitrag 1274725)

Wie mjustin bereits erwähnt hat, wird beim Benutzen des opendialogs "das Verzeichnis" richtig gesetzt, während bei LoadFromFile dies nicht der Fall ist. Was macht denn der opendialog im Detail anders?

Lies dir mal die Hilfe zu

Delphi-Quellcode:

ofNoChangeDir

in

Delphi-Quellcode:

TOpenOptions

durch: http://docwiki.embarcadero.com/Libra...s.TOpenOptions

Dann probier dein Beispiel mal mit beiden Einstellungen aus.

[Ajintaro]

:coder2:

Ah jetzt ! Uwe, der Hinweis war Gold wert ! Das Problem liegt daran, dass der OpenDialog das Arbeitsverzeichnis wechselt - das hat vermutlich auch mjustin gemeint. Ein kleines

Delphi-Quellcode:

SetCurrentDir

behebt das kleine, nervige Problem :-)

:dp: