Archiv August 2010

Bei einer kleinen selbstprogrammierten Anwendung stand ich vor dem Problem, dass ein Formular auf ein anderes Formular zugreifen muss, das andere Formular jedoch auch eine Aktion auf ersterem Formular ausführen muss.

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;
  

Heute habe ich erfolgreich meine bisherigen Entwicklungsergebnisse von Klebezettel 3.0 auf Delphi 2010 aktualisiert, was einfacher war, als gedacht. Nun kann es endlich losgehen mit der Entwicklung :-)

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.

Eine Chance für Delphi

22. August 2010

Nach langem Überlegen habe ich mich nun doch dazu entschlossen, mit Delphi weiterzuarbeiten.

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!

Eigentlich habe ich im März mit der Neuentwicklung von Klebezettel begonnen (kommende Version 3.0). Allerdings habe ich seit mehreren Monaten nicht mehr weitergemacht.

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…