Wenn ich nun jeweils die andere Unit in den Interface-Teil hinzufüge, meckert der Compiler (zirkuläre Referenz).

Eine mögliche Lösung wäre, die Referenz auf das erste Formular einem public Feld vom Typ “TCustomForm” des zweiten Formulars zuzuweisen, die Unit des ersten Formulars dem Implementation-Abschnitt der 2.Form bekannt zu machen und dann in der entsprechenden Prozedur auf die Klasse der ersten Form casten.

Beispiel:

Unit Form2;

interface

uses
  [...]

  type
    TForm2 = class(TForm)
	  [...]
	private
      Form1Ref: TControl;
	  procedure DoSomethingOnForm1;
	  [...]
    public
      [...]
   end;

implementation

 uses
   Form1;

[...]

procedure TForm2.DoSomethingOnForm1;
Var
  Form1: TForm1;
begin
  Form1 := TForm1(Form1Ref);
  Form1.MacheIrgendEtwasAufForm1;
end;

Funktioniert, ist aber hässlich™.

Etwas tippintensiver, aber wesentlich “hübscher” geht es mit einem Event:

Unit Form2;

interface

uses
  [...]

  type

  TForm2Event = procedure (Sender: TObject) of Object;

    TForm2 = class(TForm)
	  [...]
	private
      FForm2Event: TForm2Event;
	  procedure DoSomethingOnForm1;
	  [...]
    public
      property Form2Event: TForm2Event Read FForm2Event Write FForm2Event;
   end;

implementation

[...]

procedure TForm2.DoSomethingOnForm1;
begin
  // Auslösen des Events
  If Assigned(Form2Event)
    Form2Event(Sender);
end;   

_______________________________________________

Unit Form1;

interface

[...]

Type
  TForm1 = class(TForm)
  [...]
  public
    procedure Form2EventAusfuehren(Sender: TObject);
  end;

  [...]  

  implementation

  TForm1.FormCreate(Sender: TObject);
  begin
    [...]
	Form2.Form2Event := Form2EventAusfuehren;
  end;

  procedure Form1.Form2EventAusfuehren(Sender: TObject);
  begin
    // hier Code der auf Form1 ausgeführt werden soll
  end;
  

Sobald die erste Version verfügbar ist, die die grundlegendsten Funktionen implementiert hat (Notizen erstellen, speichern, laden) wird es wöchentliche Snapshots der aktuellen Entwicklungsversion geben.

Um auf dem aktuellen Stand der Technik zu sein, habe ich gestern das Update auf Delphi 2010 Professional erworben – und ich bin begeistert, denn es hat sich im Vergleich zu Delphi 2007 so viel getan (OK, das meiste davon kam mit Delphi 2009, aber trotzdem):

• PNG-Support
• Mehrere Button-Styles für Windows Vista und höher, z.B. SplitButton
• Natürlich Unicode (Erweiterter Zeichensatz, um z.B. auch exotische Anwendungen (Chinesisch etc.) erstellen zu können)
• ButtonedEdit-Control
• Hint-Text für Edit-und Combobox-Controls (finde ich ein Super-Feature!)
• Style “NumbersOnly” für das Edit-Control
• Gruppierung beim TListView
• Marquee Style für die ProgressBar
• themed Hints
• Windows 7 Features
• DirectX Support Headers
• TDirectory, TFile, TPath
• TStringBuilder
• Generics

Nun kann die Weiterentwicklung Neuentwicklung von Klebezettel endlich starten!

Der erste Grund: Zeitmangel. Seit Ende März habe ich eine seht zeitintensive neue Stelle, mit der ich meinen Lebensunterhalt für mich und meine Kinder verdiene.

der Zweite Grund: Unsicherheit, wie es um die Zukunft der verwendeten Entwicklungsumgebung “Delphi” steht.

Seit Anfang an wird Klebezettel in der Programmiersprache Delphi entwickelt. Diese Programmiersprache stammt ursprünglich von der Firma Borland und wird mittlerweile von der Firma Embarcadero vertrieben. Schon seit einigen Jahren geht es nicht richtig voran in neuen Versionen von Delphi. Die letzte Delphi-Version, die ich gekauft hatte, war Delphi 2007. Seitdem warte ich auf eine neue Delphi-Version, die auch 64bit-Programme erstellen kann. Leider hat Embarcadero die Delphi-Entwickler auch mit der neuen Roadmap erneut vertröstet, eine erste Preview eines 64bit Compilers wird es erst 2011 geben.

Nun stelle ich mir die Frage: ist es überhaupt noch sinnvoll, weiterhin mit Delphi Software zu entwickeln? Nun, einerseits habe ich einige sehr gute Komponenten lizensiert, mit denen man in kurzer Zeit ansprechende, produktive Anwendungen entwickeln kann. Aber mit der wachsenden Unsicherheit bezüglich Delphis Zukunft wächst auch die Unsicherheit, wie lange die Komponentenhersteller ihre Komponenten noch pflegen.

Ich bin schwer am überlegen, eine neue Klebezettelversion wenn überhaupt nur mit c# (.net Framework) zu entwickeln. Mittlerweile haben laut meinem Webserver 25% aller Klebezettel-Nutzer Windows 7, sowie 15% Windows Vista – dort ist das benötigte .net Framework bereits installiert. Auf Windows XP kann das .net Framework ohne Probleme nachinstalliert werden – allerdings wird es dort auch schon in vielen Fällen installiert sein.

Vielleicht kann mir ja jemand bei der Entscheidungsfindung helfen…

Die Hilfe brachte keinen Hinweis auf eine Alternativ-Funktion.

Eine Suche bei Google brachte den Hinweis: Die Alternativ-Funktion für FileAge ist… FileAge!
Die Funktion FileAge ist überladen. Die zweite Version wird wie folgt aufgerufen:


function FileAge(const FileName: string; out FileDateTime: TDateTime): Boolean;


Das Dateidatum wird hier über den Parameter FileDateTime zurückgegeben, die Funktion selbst gibt zurück, ob der Aufruf der Funktion erfolgreich war.

Die Klasse ist unter http://www.itwriting.com/blog/a-simple-delphi-wrapper-for-sqlite-3 zu finden.

Die Klasse ermöglicht nicht den Zugriff auf die Daten über Datensteuerungs-Komponenten (DBGrid etc.), sondern muss manuell im Quellcode angesprochen werden. Das ist aber nicht unbedingt ein Nachteil, denn dadurch kann die Klasse auch ohne in Delphi vorhandene Datenbankfunktionalität (z.B. Delphi 7 und Delphi 2005 PE) eingesetzt werden.