Immer Ärger... Nö, nicht mit Harry,sondern dem Synedit...

[Delbor]

Hi zusammen

Um in meinem aktuellen Projekt SQLite-Tabellen anzulegen, wollte ich in früheren Projekten nachsehen, wie ichs da gemacht habe. Eines dieser Projekte verwendet das Synedit. Und dieses widerum eine Klasse TBetterregistry, die von TRegistry abgeleitet ist.
Auf meiner Suche bin ich nun auf folgenden Code gestossen:

Delphi-Quellcode:

  {$IFNDEF SYN_COMPILER_4_UP}
  TBetterRegistry = class(TRegistry)
    function OpenKeyReadOnly(const Key: string): Boolean;
  end;
  {$ELSE}
  TBetterRegistry = TRegistry;
  {$ENDIF}

Der Witz daran ist: Das TRegistry in der Klassendeklaration (Zeile 1) wird nicht angemeckert, jenes zwischen {$ELSE} und {$ENDIF} aber schon, und der Compilierungsvorgang bricht mit einer Fehlermeldung ab ([dcc32 Fehler] SynEditMiscClasses.pas(388): E2003 Undeklarierter Bezeichner: 'TRegistry').
Was ist da falsch?

Gruss
Delbor

[mkinzler]

Dann scheint

Code:

SYN_COMPILER_4_UP

definiert zu sein.

[Luckie]

Und bitte das nächste mal einen aussagekräftigeren Titel!

[Delbor]

Hi mkinzler

Zitat:

Zitat von mkinzler (Beitrag 1446670)

Dann scheint

Code:

SYN_COMPILER_4_UP

definiert zu sein.

Und was bedeutet das? Das die nicht angemeckerte Zeile gar nicht abgearbeitet wird und somit auch nicht zu einem Comppilerfehler führen kann? Könnte ich so durchaus nachvollziehen.
Andrerseits - TRegistry ist eine gültige Klasse...

In diversen Uses-Abschnitten hab ich nun folgendes geändert:

Delphi-Quellcode:

  System.Win.Registry,
//  Registry,

Es gab noch einige andere Fehler - ich hatte einen Frame entfernt, aber offensichtlich die *.dcu nicht. Nun läuft das Programm wieder.

Zitat:

Zitat von Luckie (Beitrag 1446672)

Und bitte das nächste mal einen aussagekräftigeren Titel!

Sorry, Luckie, aber nachdem mir diese Betterregistry, bzw TRegistry, schon vor Jahren Probleme bereitete, deren Ursache ich lange nicht fand, blieb mir eigentlich nur noch, das ganze von der humoristischen Seite zu sehen. Ichwerde mich aber nach bestem Wissen und Gewissen bessern.

Gruss
Delbor

[TiGü]

Dir ist schon klar, dass die Problemursache die Unit-Präfixe waren?

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1446798)

Dir ist schon klar, dass die Problemursache die Unit-Präfixe waren?

In der Tat! Leider verwenden immer noch eine ganze Reihe von Bibliotheken die alten Non-Prefix Unit-Namen, vermutlich aus Kompatibilitätsgründen oder einfach aus Bequemlichkeit. Das hat allerdings den Nachteil, daß jedes Projekt, das diese Bibliotheken im Source verwendet, einen passenden Eintrag für die Unit-Gültigkeitsbereichsnamen braucht - obwohl das eigentliche Projekt diese gar nicht benötigen würde. Dummerweise kann das aber die Compilierzeiten und das CodeInsight verlangsamen.

[Delbor]

Hi Uwe Raabe

Zitat:

Zitat von Uwe Raabe (Beitrag 1446809)

Zitat:

Zitat von TiGü (Beitrag 1446798)

Dir ist schon klar, dass die Problemursache die Unit-Präfixe waren?

In der Tat! Leider verwenden immer noch eine ganze Reihe von Bibliotheken die alten Non-Prefix Unit-Namen, vermutlich aus Kompatibilitätsgründen oder einfach aus Bequemlichkeit. Das hat allerdings den Nachteil, daß jedes Projekt, das diese Bibliotheken im Source verwendet, einen passenden Eintrag für die Unit-Gültigkeitsbereichsnamen braucht - obwohl das eigentliche Projekt diese gar nicht benötigen würde. Dummerweise kann das aber die Compilierzeiten und das CodeInsight verlangsamen.

Das versteh ich jetzt so, dass ich diese Verlangsamung umgehen könnte, wenn ich sämtlich Uses-Listen mit den 'neuen' Unit-Präfixe ergänzen würde? Brr... Gerade beim Synedit eine Sysiphus-Arbeit, auch wnn ich mit einigen wenigen Highlitern auskomme(Pascal,HTML, CSS und Javascript ).

Gruss
Delbor

[Uwe Raabe]

Zitat:

Zitat von Delbor (Beitrag 1446852)

Brr... Gerade beim Synedit eine Sysiphus-Arbeit

Nicht, wenn man das angehängte Tool benutzt...