Werte unter Delphi XE2 zuweisen !?

[roga]

Ich wünsche euch allen FROHE OSTERN und recht fleißige Osterhasen und -häsinnen :-D

Bei der Umstellung auf Delphi XE2 treten in meinen Komponenten immer wieder Probleme bei Zuweisungen auf, die es unter Delphi 2007 nicht gab.

Beispiel:

Delphi-Quellcode:

    // unter Delphi 2007 

    with ARect do
    begin
      Left := 4;
      Right := Width - 4;
      Top := Height - 20;
      Bottom := Height;
    end;

    // NUR so klappt es unter XE2

    ARect.Left := 4;
    ARect.Right := Width - 4;
    ARect.Top := Height - 20;
    ARect.Bottom := Height;

Auch bei Zeichenaktionen vergisst Delphi XE2 irgenwann die Beziehung zum Canvas, obwohl nirgends eine Ableitung erfolgte.

Delphi-Quellcode:

    with Canvas do
    begin
      ...
    end;

Liegt der Fehler nun an Embarcadero oder muss ich zukünftig die umständlichere Variante anwenden?

Viel Spaß beim Ostereier suchen
roga

[zeras]

Was sind das für Probleme?

[jaenicke]

Das ist kein Fehler, sondern ist typisch für die Verwendung von with.

Mit XE2 hat TRect diverse Erweiterungen bekommen, unter anderem Width und Height als Eigenschaften. Deshalb bezieht sich das eben nicht mehr auf das Formular außen, sondern auf das Rechteck.

In der VirtualTreeView war ähnlicher Code, nur mit Offset (das es nun auch in TRect gibt). Ohne with hätte sich auch der problemlos unter XE2 einfach wieder kompilieren lassen. :roll:

Deshalb verwende ich selbst with nie. Es gibt damit immer nur unnötige Probleme, schwer zu findende Fehler und debuggen ist damit auch nicht sinnvoll möglich (weil man bei Auswertungen mit Strg + F7 usw. immer erst manuell den Inhalt des with dazuschreiben muss und andere Sachen gleich gar nicht gehen). Refactoring funktioniert auch nicht wirklich. Und übersichtlich ist das ganze auch nicht, weil man ständig rätseln muss worauf sich denn nun was bezieht. Eben weil die dann viel kürzeren Bezeichner oft nicht eindeutig sind. Wie du ja hier gerade selbst feststellen musstest.

Deshalb verstehe ich immer nicht weshalb man sich das alles zumutet nur um ein paar Zeichen zu tippen zu sparen... :wall:

[roga]

Zitat:

Mit XE2 hat TRect diverse Erweiterungen bekommen, unter anderem Width und Height als Eigenschaften.

Das erklärt natürlich alles. Ich danke Dir für den Hinweis, Sebastian! Das mit der Übersichtlichkeit ist sicherlich Ansichtssache und hat seine Vor- und Nachteile (wie man ja hier sieht).

roga

[Bummi]

@roga

Die Nachteile überwiegen definitiv, nicht nur wegen der Probleme beim Umstieg auf neuere Versionen, der häufig mühsamen Fehlersuche bei komplexeren Passagen mit derartigem Code, sondern auch weil so etwas einfach nicht "debugbar" ist.

[himitsu]

Es ist für die Abwärtskompatibilität nicht unbedingt optimal, aber es betrifft auch ausschließlich die Verwendung von WITH.
PS: Ich hab bisher zufällig intuitiv vorwiegend immer nur eine Seite über das With geregelt und die andere Seite nicht, womit es damit nun auch fast keine Probleme durch derartige Erweiterungen gibt.
Nicht unbedinbt bei TRect, TPoint und Co., aber vorallem bei Objekten war es absehbar, daß diese irgendwann auch mal erweitert werden.
Wer das WITH gedankenlos nutzt, ist MBMN selbst dran Schuld.

Für neue Projekte ist es definitiv eine Vereinfachung des Codes und beim Suchen nach Funktionen, denn die gammeln nun nicht mehr unbekannt irgendwo rum, sondern hängen direkt dran.



Und was die Abwärtskompatibilität angeht: Bis D2006/TDE hinunter kann man das neue XE2-Verhalten nachrüsten.

[Bernhard Geyer]

Zitat:

Zitat von Bummi (Beitrag 1160708)

Die Nachteile überwiegen definitiv, nicht nur wegen der Probleme beim Umstieg auf neuere Versionen, der häufig mühsamen Fehlersuche bei komplexeren Passagen mit derartigem Code, sondern auch weil so etwas einfach nicht "debugbar" ist.

Kann ich bestätigen. Wenn ein Code überarbeitet werden muss und ein With drin ist fliegt das raus.

[himitsu]

Zitat:

sondern auch weil so etwas einfach nicht "debugbar" ist.

Der Witz daran ist, daß es meiner Erfahrung nach gut debugbar ist.
Jedenfalls hat der Debugger das WITH meistens gut auflösen können. (wenn der Debugger nicht durch andere Dinge behindert wurde, wie BPLs, DLL/EXE-Modulgrenzen, Generics und andere Debugger-/Compilerfehler)

[Bummi]

@himitsu

Ich habe die gegenteilige Erfahrung gemacht, ein Kollege von mir setzt exzessiv With Statements ein, auch mehrfach verschachtelt, in der Art

Delphi-Quellcode:

   With MyAdodatset do
     begin
        For ....
          Fields[i].irendwas ....
          With aCanvas do ...
     end;

Wenn man hier etwas debuggen will muss man immer den wieder zusammengesetzten Ausdruck in die Überwachung nehmen, bei einem Mouseover läuft gar nichts, außer dass sich der Debugger bisweilen aufhängt und die ganze IDE mitnimmt

[Sir Rufo]

Wenn man unbedingt

Delphi-Quellcode:

with

benutzen möchte, dann sollte man sich entweder ausschließlich auf dieses Objekt beschränken oder eben alles direkt referenzieren.

Das genannte Beispiel sollte so reibungslos funktionieren:

Delphi-Quellcode:

// unter Delphi 2007 und XE2

  with ARect do
    begin
      Left := 4;
      Right := Self.Width - 4;
      Top := Self.Height - 20;
      Bottom := Self.Height;
    end;

Allerdings habe ich so den Verdacht, dass hier von einer Form der innere Bereich ohne den Rand ermittelt werden soll, und das geht natürlich erheblich einfacher (und vor allem funktioniert das bei jedem Theme und jeder Darstellungsart) mit TForm.ClientRect

[Popov]

Zitat:

Zitat von Bummi (Beitrag 1160708)

Die Nachteile überwiegen definitiv

Das ist übertrieben. Ich verwende

Delphi-Quellcode:

with

excesiv. Manchmal ertappe ich mich dabei, dass ich mich selbst über mich ärgere, denn manchmal gehe auch ich für mich zu weit. Kaum kann ich zwei Bezeichner abkürzen, schon steht ein

Delphi-Quellcode:

with

dort. Manchmal sind

Delphi-Quellcode:

with do begin end;

mehr Schreibarbeit als was ich mir mit with spare. So sehr liegt mir das inzwischen im Blut. Was ich damit sagen will ist - ich verwende es nicht gelegentlich, sondern extrem viel. Deshalb kann ich gut überblicken ob die Vor- oder Nachteile überwiegen.

Wenn man meine ganzen Probleme mit with in den Jahren hoch rechnet, dann kann ich sie im wahrsten Sinne an einer Hand abzählen.

Das mit dem Debuger ist eine andere Sache, aber auch hier ist es nur eine Frage der Technik und schon klappt es wieder.

Ok, wer with nur gelegentlich anwendet, für den überwiegen die Nachteile wahrscheinlich. Aber nicht für den der sehr viel damit arbeitet.

Allerdings gebe ich zu, dass das mit Rect und Left tatsächlich unglücklich ist.

[roga]

Die Ursache war einfach die neue und auch sinnvolle Erweiterung des TRect um Width und Height, die gab es halt zum Zeitpunkt der Erstellung noch nicht. Mal sehen, was die weitere Umstellung auf XE2 noch an Überraschungen bringt, die meisten Sachen laufen aber ohne Probleme. Anders sieht es bei Fremdkomponenten aus wie z.B. die DLLLoader.pas (BASS), die ich in älteren Spielen für die mp3-Wiedergabe nutze. Hier schmiert das Programm direkt beim Start ab, bleibt aber noch im Task-Manager drin.

Delphi-Quellcode:

IF ASSIGNED(Stream) THEN BEGIN
  Stream.Seek(0, soFromBeginning);
  IF Stream.Size>0 THEN BEGIN
   IF ReadImageHeaders THEN BEGIN
    IF InitializeImage THEN BEGIN
     IF ReadSections THEN BEGIN
      IF ProcessRelocations THEN BEGIN
       IF ProcessImports THEN BEGIN
        IF ProtectSections THEN BEGIN
         IF InitializeLibrary THEN BEGIN // Exception
          IF ProcessExports THEN BEGIN
           RESULT:=TRUE;
          END;
         END;
        END;
  ...

Hier die entsprechende Function:

Delphi-Quellcode:

FUNCTION InitializeLibrary:BOOLEAN;
 BEGIN
  RESULT:=FALSE;
  @DLLProc:=ConvertPointer(ImageNTHeaders.OptionalHeader.AddressOfEntryPoint);
  IF DLLProc(CARDINAL(ImageBase),DLL_PROCESS_ATTACH,NIL) THEN BEGIN
   RESULT:=TRUE;
  END;
 END;

Aber das wäre nicht ganz so gravierend, da die Spiele nicht weiterentwickelt werden.

[himitsu]

Die Frage ist eher, warum dort jemand versucht die DLL manuell zu laden und nicht die vorhandenen APIs nutzt?