string concatentation mit NULLs

[Krampus]

hallo!

folgende Delphi6 - programmzeile liefert nur unter VISTA (unter W2000, XP läufts)
die meldung "ungültige variant operation".

bisher war ich es gewohnt, dass das ergebnis für v einfach NULL ist,
aber keine variant-exception verursacht.

Code:

var
 v: Variant;
begin
 v := (NULL + 'EIN_STRING');
end

hintergrund:
natürlich abstrahiert das ganze - NULL ist in der praxis ein TADOField.Value,
der tw. halt NULL sein kann.

workarounds zu finden ist nicht das problem - ich will nur den grund für
die anomalie herausfinden (vielleicht gibts ja irgendeinen compiler-switch o.ä.)

danke für eure hilfe!

[HeinzJ]

Ich denke mal, das der Operator + (für Stringverkettung) da mal schlicht keinen NULL Wert zuläßt.
Versuchs mal mit VariantFeld.AsString.

[Krampus]

Zitat:

Zitat von HeinzJ

Ich denke mal, das der Operator + (für Stringverkettung) da mal schlicht keinen NULL Wert zuläßt.
Versuchs mal mit VariantFeld.AsString.

AsString kenn ich schon...

wie eingangs schon erwähnt lässt er´s auf 2 von 3 rechnern schon zu.
auf dem dritten läuft vista (was der einzig erkennbare unterschied ist) -
vielleicht ist die lösung aber auch ein delphi-compliler-switch (oder was halt immer - DAS ist die frage)

so ists halt urpraktisch, ein schöner einzeiler und vermeidet dutzende if-s bzw. doppelte leerzeichen.
so wird das leerzeichen nur verwendet, wenn das feld auch einen wert hat:

Code:

sName := Nz(rs.FieldValues[FLD_TITEL] + ' ', '') + Nz(rs.FieldValues[FLD_NAME2] + ' ', '') +
    Nz(rs.FieldValues[FLD_NAME1], '') + Nz(' ' + rs.FieldValues[FLD_NAME3], '');
--------------------------------------------------
function Nz(val, replace: variant): Variant;
begin
   if (val <> NULL) then
      result := val
    else
      result := replace;
end;

nachdem ich das seit 10 jahren so mache hab ich einfach keine lust
100e codezeile aufzublasen nur weil ich mal am samstag nachmittag
in der gartenhütte mit dem sch*** vista-notebook ein paar code-zeilen schreibe...
...wenn die möglichkeit besteht die URSACHE der anomalie zu finden
und das auf dem vista-ding auch zum laufen zu kriegen.

[Neutral General]

Hi,

Vielleicht kannst du es einfach so machen:

Delphi-Quellcode:

var
  v: Variant;
  tmp: String;
begin
  tmp := ADOField.Value;
  v := (tmp + 'EIN_STRING');
end

Gruß
Neutral General

[gammatester]

Zitat:

Zitat von Krampus

hallo!
workarounds zu finden ist nicht das problem - ich will nur den grund für
die anomalie herausfinden (vielleicht gibts ja irgendeinen compiler-switch o.ä.)

danke für eure hilfe!

Wenn dasselbe EXE-File auf allen Systemen läuft, liegts wohl an den Compilereinstellungen. Wenn's nicht läuft, am System.

Gruß Gammatester

[Krampus]

Zitat:

Zitat von Neutral General

Delphi-Quellcode:

var
  v: Variant;
  tmp: String;
begin
  tmp := ADOField.Value;
  v := (tmp + 'EIN_STRING');
end

würde eine exception verursachen sobald das feld leer ist.
NULL kann keiner string-variable zugewiesen werden.
wenn dann entweder mit FieldbyName(FLD).AsString (siehe 2. posting)
oder VarToStr(ADOField.Value) (='') ... aber das alles ist nicht die frage.

brauche keinen workaround sondern eine konkrete antwort auf die
frage warum eine string-concatentation mit einem null-wert (NULL + 'WASWEISSICH') *)
auf einem PC funktioniert (und NULL ergibt) und auf dem anderen nicht?

*) der gag bei der sache ist, dass der 'WASWEISSICH'-string nur angefügt
wird, wenn das feld nicht leer ist - was mir einen haufen if-s spart
(hab ich das nicht schon oben gesagt?)...

...der concat von 2 strings ('' + 'irgendwas') führt das ganze ad absurdum
und resultiert in diesem fall in 2 leerzeichen, wenn eine adresse z.b. keinen titel hat
und das ist genau was ich damit auf möglichst einfache weise vermeiden will.

[marabu]

Hallo,

handelt es sich wirklich um das identische Lademodul auf den verschiedenen Rechnern?

Zumindest seit Einführung der Unit Variants ist ein expliziter String-Cast notwendig, wenn du String-Variants mit nativen Strings in einem Ausdruck mischen willst. Damit das ganze überhaupt funktioniert muss noch NullStrictConvert auf False gesetzt sein und NullAsStringValue auf einen leeren String verweisen.

Delphi-Quellcode:

begin
  Variants.NullStrictConvert := False;
  ShowMessage('1' + String(null) + '2');
end;

Ich halte diese Vorgehensweise nicht für eine Umgehungslösung, sondern für eine Notwendigkeit. Vielleicht hat sich da in den neueren Versionen von Delphi etwas geändert. Es kann nicht schaden, wenn du deine Standardeinstellungen für die genannten Variablen überprüfst.

Freundliche Grüße

[Krampus]

[quote="gammatester"]

Zitat:

Zitat von Krampus

Wenn dasselbe EXE-File auf allen Systemen läuft, liegts wohl an den Compilereinstellungen. Wenn's nicht läuft, am System.

denk ich auch (auch wenn ich mir da nicht 100%ig sicher bin...)
ja, die xp-EXE läuft auf dem vista-system.

die compiler-switches (in Programmoptionen) hab ich natürlich schon verglichen - die sind ident (oder ich blind)

manche leute haben aber schon von generellen problemen D6 + vista berichtet.
bis auf diese geschichte läuft hier aber alles soweit einwandfrei.

gibts konkret einen compiler-switch, der varianten-handlings steuert?

----------------------------------------------------

hab mir mal beide CPU-debugfenster angesehen - der assembler-code der beiden systeme ist derselbe.
nur beim vista-system schlägt die anweisung in zeile 00456F32 fehl:

call @VarAdd

hmm...VariantManager...
hat wer eine idee...?

[alzaimar]

Blöde Frage: Auf allen Rechnern hast du die gleichen Updates von D6? Da gibt es doch ein Update für die variants.pas. Bei meinem D6 geht das nämlich *nicht* und das läuft unter XP. Es wäre mir neu, das Variants von Windows abgebildet werden.

Du kannst den VariantManager so umbiegen, das er a) NULL implizit in '' castet oder b) beim Konkatenieren eben deine gewünschte Funktionalität implementiert. Soweit ich das hier sehe, betrifft es die eine Routine 'VarOp' .

Schau mal in 'Variants' und 'System' nach TVariantManager. Das müsste gehen.

[Krampus]

Zitat:

Zitat von marabu

handelt es sich wirklich um das identische Lademodul auf den verschiedenen Rechnern?

Zumindest seit Einführung der Unit Variants ist ein expliziter String-Cast notwendig, wenn du String-Variants mit nativen Strings in einem Ausdruck mischen willst. Damit das ganze überhaupt funktioniert muss noch NullStrictConvert auf False gesetzt sein und NullAsStringValue auf einen leeren String verweisen.

Delphi-Quellcode:

begin
  Variants.NullStrictConvert := False;
  ShowMessage('1' + String(null) + '2');
end;

BINGO!
auf dem vista-system war eine veraltete version der variants-unit.
RTL Patch#2 installiert - hat die Variants.dcu upgedated - PROBLEM BEHOBEN!

P.S: VarToStr statt String() und NullStrictConvert darf TRUE bleiben (default in variants.pas)

Delphi-Quellcode:

ShowMessage('1' + VarToStr(null) + '2');

DANKE! bist mein held des tages und hast mich vor einem vollrausch bewahrt :)