Compilerfehler bei with do Anweisung?

[robvs]

Hallo zusammen,

ich habe bei mir ein Phänomen festgestellt, welches meiner Meinung nach ein Bug unter Delphi 2006 Win 32 ist. Zur Erkläung der folgende Quelltext:

Delphi-Quellcode:

function TfrmLieferscheinVerarbeite.setAuData(var canEdit : boolean; aiAuftraege: TAryInt): boolean;
var
begin
     Result := FALSE;
     (...)
            with FDM.IBQ_Main do //relevante Auftragsdaten einlesen
            begin
                 canEdit := ((canEdit) or ((FieldByName('VERSANDKOSTEN_J_N').AsString = 'J') and
                                           (TfrmWSLieferscheinDruck(Owner).LSMode in [lsmAuftrag, lsmKundeAu]))); 

                 if (canEdit) then
                    FAuPosi.Versandkosten := FieldByName('VERSANDKOSTEN').AsCurrency
                 else
                     FAuPosi.Versandkosten := 0;
      (...)

            end;//with FDM.IBQ_Main do
     finally
            FDM.IBQ_Main.Close;
     end;
end;

Hierbei geht es um den variablen Parameter "canEdit", welcher immer FALSE bleibt, OBWOHL er TRUE werden müsste, da die Bedingungen nach dem "or" in jedem Fall TRUE ergeben.
Nachdem ich fast vom guten Glauben abgefallen bin, hab ich den Ausdruck mal vor den With-do-Block gesetzt und ES FUNKTIONIERTE!
Um sicher zu stellen, dass es wirklich an dem With-do-Block liegt, habe ich diesen entfernt und überall wo es hingehört, das FDM.IBQ_Main ergänzt und das canEdit wieder zurück an seinen alten Platz gesetzt, ebenfalls mit positivem Resultat.

Eine schnelle Antwort wäre sehr hilfreich, da ich eventuell andere Projekte diesbezüglich umstellen muss.

Viele Grüße
Rob

[dataspider]

Hi,

ich geh mal davon aus, dass IBQ_Main irgendeine Query - Compo ist.
Wenn diese (sollte IMHO so sein) auch die Eigenschaft oder Methode CanEdit hat, so hat dies in einem With den Vorrang.
Das merkt man auch, wenn man mit der Quelltextvervollständigung arbeitet und in der List CanEdit 2 mal hat.
Man sollte ein with in solchen Fällen lieber vermeiden.

Cu, Frank

[robvs]

Hey,

das wäre zu blöd von mir und zu schön im allgemeinen gewesen, aber die Query hat leider nicht die Eigenschaft CanEdit sondern CanModify.

Also bleibt die Frage weiter offen. Irgendwelche Ideen??

[SirThornberry]

meine Idee wäre einen Haltepunkt zu setzen und zu prüfen ob hinter dem "or" die Bedinung wirklich true ergibt. Als nächstes dann überprüfen ob nach ausführen der Anweisung (also im nächsten Step) wirklich nix zugewiesen wurde. Notfalls auch rein steppen versuchen um zu sehen ob es ein Property ist etc.
Auf jeden Fall ist "with-do" nicht fehlerhaft.

[robvs]

Diese Überprüfungen habe ich auch gemacht, sehr ausgiebig sogar. Deswegen konnte man mich heute Morgen mit einem großen Fragezeichen auf der Stirn duch die Gegend rennen sehen. ;)

Ich hatte bislang auch noch nie Probleme mit with-do Blöcken, allerdings hatten wir bis vor kurzem Delphi 5 als IDE.

Also, hat vielleicht noch jmd eine Idee?

[SirThornberry]

verwende mal anstelle von CanEdit eine zwischenvariable mit anderem namen

Delphi-Quellcode:

zwischenvariable := canedit;
//das bisherige aber mit "zwischenvariable" anstelle von "canedit"
canedit := zwischenvariable;

[robvs]

Auch das habe ich gemacht... wie gesagt, ich habe das schon sehr ausführlich untersucht.

Ach, eine Information, die ich vergessen habe, könnte noch hilfreich sein: Wenn ich der Var direkt TRUE zuweise, dann ist die auch true. Nur eben nicht, nach dem im Beispiel genannten boolschen Ausdruck, welcher übrigens ebenfalls wirklich 1000 %ig TRUE ergibt - da besteht kein Zweifel.

[SirThornberry]

wenn du direkt zuweist geht es? bist du dir wirklich sicher das es dein Ausdruck True zurück gibt?
Wie war das resultat als du mit zwischenvariable gearbeitet hast? wurde diese dann auf True gesetzt?

Ist sichergestellt das Owner immer vom Typ TfrmWSLieferscheinDruck ist?
und von welcher Klasse ist TfrmWSLieferscheinDruck sowie TfrmLieferscheinVerarbeite abgeleitet?

[Robert Marquardt]

Nenn doch mal den Parameter der Methode von canEdit zu ACanEdit um.

[Hawkeye219]

Hallo,

um Jens' Bemerkung noch zu ergänzen: die WITH-Anweisung bezieht sich auch die Eigenschaft Owner. Könnte das der Fehler sein?

Gruß Hawkeye

[IngoD7]

Zitat:

Zitat von Robert Marquardt

Nenn doch mal den Parameter der Methode von canEdit zu ACanEdit um.

Riesengroß unterschreib!

Zitat:

Zitat von Hawkeye219

die WITH-Anweisung bezieht sich auch die Eigenschaft Owner. Könnte das der Fehler sein?

Ebenso groß unterschreib!

[robvs]

Wie gesagt, ich hab das Ganze schon mit einer anderen Variable, die lokal in der Funktion deklariert war, versucht. bInternalCanEdit an gleicher Stelle, 1 Zeile drunter, unter dem original CanEdit, mit dem gleichen Ergebnis. Es gibt definitiv keine andere Var die CanEdit heißt.

[Phoenix]

Versuch mal Testweise den Ausdruck (ohne CanEdit) direkt im If zu evaluieren. Was passiert dann?

[Robert Marquardt]

Ist dir eigentlich klar worueber wir reden?

Wir vermuten das FDM.IBQ_Main sowohl eine Property CanEdit als auch Owner hat.
Der with-Block erzeugt einen neuen Scope, in dem die Namen von FDM.IBQ_Main natuerlich Vorrang vor den Parametern von TfrmLieferscheinVerarbeite.setAuData als auch der Namen von frmLieferscheinVerarbeite haben.
Es werden also vermutlich der Parameter CanEdit und die Property Owner von frmLieferscheinVerarbeite verdeckt.

[Phoenix]

Ich hatte sowas auch schonmal, und da wurde ein längerer If-Ausdruck, den ich zur Übersichtlichkeit in eine lokale Variable evaluiert habe, auch falsch ausgewertet. Als ich die Evaluation direkt in der If-Bedingungen eingesetzt habe gings seltsamerweise. Es könnte also tatsächlich ein Problem mit dem With-Block geben.

Wobei eine Überdeckung freilich nicht ausgeschlossen ist, aber nicht zwingend die einzige Möglichkeit für die Fehlerursache ist :)

[Robert Marquardt]

Ich wuerde trotzdem auf TfrmWSLieferscheinDruck(Owner) tippen. Vom Namen her ist bestimmt Owner von frmLieferscheinVerarbeite, aber FDM.IBQ_Main hat bestimmt eine Owner-Property, die natuerlich Vorrang hat. Da TfrmWSLieferscheinDruck(Owner).LSMode vermutlich in den Wald greift, kommt mit hoher Wahrscheinlichkeit False fuer den Gesamtausdruck heraus.
Die beiden Massnahmen zur Korrektur sind den Parameter CanEdit zu ACanEdit umzunennen (plus alle Stellen wo derParameter gemeint ist) und TfrmWSLieferscheinDruck(Owner).LSMode in TfrmWSLieferscheinDruck(Self.Owner).LSMode zu aendern.

[robvs]

FDM.IBQ_Main hat keine Property CanEdit, aber Owner. Von daher natürlich! MUSS es das wohl sein.
Der Laufzeitauswerter berücksichtigt ja keine With-Blöcke, deswegen war auch die Überprüfung immer positiv.

VIELEN DANK!

[Robert Marquardt]

Mach mal (Self.Owner as TfrmWSLieferscheinDruck).LSMode und gewoehn dir das statt harter Umtypungen an. as ueberprueft die Abstammung von Onwer ob sie TfrmWSLieferscheinDruck ist. Damit waere der Fehler aufgefallen.

[robvs]

Ja, kommt dann ein konkreter Fehler, dass die Klasse nicht passt oÄ?

Und noch mal danke.

[Robert Marquardt]

Genau. Der as Operator klettert die RTTI-Informationen der klassen entlang und schmeisst eine Exception wenns nicht passt.
Das kostet natuerlich Performance, aber ist zumindest bei der Entwicklung sehr hilfreich. Eine harte Umtypung kann man spaeter ja immer noch reinmachen.