Bedingte Kompilierung – Kniffliger Fall

[Andreas13]

Hallo Community,
in einem kniffligen Fall einer geplanten bedingten Kompilierung möchte ich Euch um Rat bitten.

Delphi-Quellcode:

Library ExcelDLL_1;  
// ExcelDLL wird über eine .xlam in Excel eingebunden.
uses
  Berechnung_1,
  Berechnung_2,
  Berechnung_3
;
...

exports
...

End;{ExcelDLL_1}
{--------------}

Unit Berechnung_1

Interface

Procedure A(..);
Procedure B(..);
...

Implementation

Procedure A(..);
Begin
...
  IF Bedingung_1 Then
  Begin
   Fehlermeldung; // weil Daten unvollständig oder nicht in Ordnung sind
   Exit;
  End; 
End;{A}
{.....}


Procedure B(..);
Begin
...
  IF Bedingung_2 Then
  Begin
   Fehlermeldung; // weil die Daten unvollständig oder nicht in Ordnung sind
   Exit;
  End; 
End;{B}
{.....}

....
Begin
...

End;{Berechnung_1}
{----------------}

Die Units Berechnung_1, Berechnung_2 etc. werden für zwei verschiedene Zwecke benutzt:
a): "normale" Programme: --> *.EXE
b): via DLL’s (ExcelDLL_1, ExcelDLL_2 etc.) werden sie zur Unterstützung von Excel verwendet.

Das Problem
sind die Fehlermeldungen in den Routinen wie Procedure A(..), Procedure B(..) etc.

In "normalen" Programmen (Fall a: ) sind sie erwünscht, innerhalb von Excel jedoch nicht.
Das hängt damit zusammen, daß Excel die Funktionen und Proceduren nur kleckerweise mit Daten füllt: Oft sind z. B. bei einer Funktion mit 5 Parametern bis zu 5 Anläufe notwendig, bevor gerechnet wird: In Tabellen-Kalkulationsprogrammen ist das "normal". Da die ersten 4 Aufrufe noch unvollständige Daten enthalten, darf keine Berechnung ausgeführt werden.
Daher ist die Fehlermeldung in regulären Programmen OK, in Excel ist sie störend und verwirrend.

Mein Ziel:
Ich möchte die Fehlermeldungen in den Units Berechnung_1, Berechnung_2 etc. beim Kompilieren für die DLL’s auf einen Schlag irgendwie per Conditional Defines deaktivieren und gar nicht in die DLL linken. Für eine reguläre EXE müssen sie jedoch drinbleiben.
Bisher habe ich in den fraglichen Routinen die Fehlermeldungen einfach auskommentiert. Weil die Units Berechnung_1, Berechnung_2 etc. recht umfangreich sind (je 50 tausend bis 100 tausend Zeilen Code mit vielen potentiellen Fehlermeldungen) ist es nicht sehr produktiv.

Wie könnte ich beim Kompilieren von der DLL aus den Units Berechnung_1, Berechnung_2 etc. mitteilen, daß ich die Fehlermeldungen im Moment nicht benötige.

Hätte jemand von Euch eine praktikable Idee dafür?

Herzlichen Dank für Eure Hilfe und Mühe im Voraus!

Viele Grüße
Andreas

[Uwe Raabe]

Dafür braucht es gar keine bedingte Compilierung. Mit IsLibrary kannst du prüfen, ob der Code in einer DLL oder EXE läuft.

[Andreas13]

Danke Uwe,
Du bist (wie immer) Spitze!
Grüße
Andreas

[himitsu]

Ansonsten kann man auch noch mit Defines arbeiten.

{$IFDEF MitFehlermeldungen}

Und dann in den Projektoptionen des DLL-Projektes das "MitFehlermeldungen" hinzufügen.
Optionen > Erzeugen > Delphi-Compiler > Bedingungen
Da, wo z.B DEBUG und RELEASE steht, aber am Besten das hier in die "Basis"-Config (Alle Konfigurationen - Alle Plattformen) eintragen.

Diese Standard-Bedingungen sind auch dafür verantwortlich, dass man {$IFDEF DEBUG} und {$IFDEF RELEASE} machen kann,

[Andreas13]

Danke Himitsu,
werde auch Deine Lösung ausprobieren!
Grüße, Andreas

[Andreas13]

Hallo,
noch einmal herzlichen Dank für Eure tollen Tipps!
Ich kann beide Möglichkeiten sehr gut verwenden:

Delphi-Quellcode:

IF IsLibrary Then
 ...
End;

{$IFDEF MitFehlermeldungen}
  Fehlermeldung('...');
{$ENDIF}

Habe wieder etwas dazugelernt!
Grüße, Andreas

[himitsu]

Zu bedenken ist nur, dass Beides natürlich etwas "unterschiedlich" funktioniert.

IsLibrary wird zur Laufzeit ausgewertet und das IFDEF schon im Compiler.
Also bei IsLibrary ist dann immer auch der ungenutzte Code mit im Compilat.

Aber so lange es nicht stört, ist es ja fast Egal.
Und dat bissl mehr Speicher kostet ja och nix mehr.
https://www.computerbase.de/2020-07/...-tb-ssd-preis/

[Andreas13]

Ja natürlich, Himitsu! Ich verwende Eure Vorschläge unterschiedlich:
1):
Zum Debuggen von Multipräzisions-Strukturen (MPA) brauche ich an sehr vielen Stellen diverse Print-Anweisungen für MPA-Variablen, MPA-Vektoren und MPA-Matrizen. Wenn ich auch nur eine vergesse auszukommentieren, stürzt die Excel-DLL ab: Excel ist ja keine Console-Anwendung und kennt kein WriteLn(...‘); . Dafür ist IsLibrary als "Lebensversicherung" hervorragend geeignet: z.B.

Delphi-Quellcode:

Print_MPA_Matrix(..)
  IF IsLibrary Then
    Exit;
  End;
  ...
  WriteLn(…);
  ...
End;

2):
Deinen ursprünglichen Vorschlag zur Unterdrückung der Fehlermeldungen in Excel:

Delphi-Quellcode:

{$IFDEF MitFehlermeldungen}
  Fehlermeldung('...');
{$ENDIF}

konnte ich für meine Zwecke etwas modifiziert leichter einsetzen:

Delphi-Quellcode:

{$IFDEF OhneFehlermeldungen}
  // ---> Nur für die Excel-DLL‘s
{$ELSE}
   Fehlermeldung('...');
{$ENDIF}

So hatte ich lediglich in 8 DLL's die Projektoption "OhneFehlermeldungen" einzustellen gehabt. Das war in meinem Fall zweckmäßiger, sonst hätte ich die Projekt-Optionen in sehr vielen Berechnungs-Units ändern müssen.
Dein Vorschlag hat für mich den Vorteil, daß der Text der Fehlermeldungen gar nicht in die DLL gelinkt wird.
Danke nochmal!
Ich habe die Möglichkeit der von Dir genannten globalen vererbbaren Projektoption "Alle Konfigurationen - Alle Plattformen" zu meiner Schande nicht gekannt.

Viele Grüße
Andreas

[himitsu]

IsConsole ?

Bzw. {$IFDEF CONSOLE} , wenn die Anwendung als Console {$APPTYPE CONSOLE} kompiliert wird.



Für WriteLn einfach die Fehlerbehandlung deaktivieren, also {$I-} oder verständlicher {$IOCHECKS OFF} ,
oder ohne jegliche Fehlerprüfung selber schreiben.

Delphi-Quellcode:

program Project9;

{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  Winapi.Windows;

type
  OEMString = type AnsiString(CP_OEMCP);  // wenn es nur ASCII ist, dann geht auch AnsiString;
var
  S: OEMString;
  H: THandle;
  X: Cardinal;
begin
  H := GetStdHandle(STD_OUTPUT_HANDLE);
  S := 'hallo'#10;
  WriteFile(H, S[1], Length(S), X, nil);
  WriteFile(H, S[1], Length(S), X, nil);
  Sleep(5000);
end.

[Andreas13]

Danke Himitsu. Bis gestern habe ich weder System.IsLibrary noch  System.IsConsole gekannt.
Grüße, Andreas