Fragen zu TApplication

[mschnell]

1+ für Theo an dieser Stelle

Theo ist der Meister der voreiligen unzulässigen Vereinfachung. Ich bin als Advocatus Diaboli immer eher für vorsorgliche Verkomplizierung
-Michael

[mschnell]

Hängt davon ab, ob man unter "Neu" auf "Anwendung" oder "Programm" klickt, obwohl da im Code gar keine Ursache für ersichtlich ist. mse hat Recht, mit "{$apptype gui}" erscheint keine Konsole.

Durch "Anwendung" oder "Programm" und ähnliche Vorgaben sowie durch das aktuelle Betriebssystem beim Erzeugen des Projekts werden unterschiedliche "Widget Type" (aka "Interface") Einstellungen für das Projekt definiert und auch festgelegt,m ob überhaupt eine TApplication-Instanz angelegt wird.

-Michael

[mschnell]

Hängt davon ab, ob man unter "Neu" auf "Anwendung" oder "Programm" klickt, obwohl da im Code gar keine Ursache für ersichtlich ist. mse hat Recht, mit "{$apptype gui}" erscheint keine Konsole.

Durch "Anwendung" oder "Programm" und ähnliche Vorgaben sowie durch das aktuelle Betriebssystem beim Erzeugen des Projekts werden unterschiedliche "Widget Type" (aka "Interface") Einstellungen für das Projekt definiert und auch festgelegt,m ob überhaupt eine TApplication-Instanz angelegt wird.

Wenn Du das verstehen willst: Vorsicht: Die Begriffe "application", "Interface", "GUI", Widget ... im Code und in der Dokumentation werden teilweise ziemlich uneindeutig verwendet. Beispielsweise wird oft forusgesetzt, dass ohne GUI gar keine Event-Queue möglich wäre. Dass dass nicht stimmt, zeigt z.B. mse.

Mit WidgetSet ist im Allgemeinen die vom "Betriebssystem" und seinen Erweiterungen zur Verfügung gestellte Infrastruktur zum GUI-Handling gemeint. (Bei Windows wird auch die hierin (also Prorgamm-extern) implementierte Message-Queue als einzige Event-Queue des Programms verwendet. Bei anderen Betriebssystemen gibt es im "Interface" Teil der LCL eigene Queue Implementierungen, die teilweise gleichzeitig parallel aktiv sind. Mit "WidgetType" ist der so benannte Build-Mode Macro gemeint, der beim Kompilieren bestimmt welche Art "Interface" von TApplication angesprochen werden soll. Der kann möglicherweise mit GUI-Widgets überhaupt nichts zu tun haben und möglicherweise gar keine GUI zulassen.

-Michael

[theo]

Theo ist der Meister der voreiligen unzulässigen Vereinfachung.

Vereinfachung? Ja, unbedingt. Wo immer es möglich ist.
Voreilig und unzulässig? Das ist Polemik, das sehe ich nicht so.

In diesem konkreten Thread habe ich ja eigentlich nur - nachdem die Frage von mse und dir schon ausführlichst beantwortet wurde - noch eingeworfen, dass die Kenntnis über den Aufbau der Lazarus Projekt Datei für den Einstieg nicht zentral ist.
Ich habe ursprünglich die bestehenden Antworten überhaupt nicht kritisiert.
Deshalb verstehe ich diesen Aufruhr hier eigentlich gar nicht. (Es muss wohl der nahende Weltuntergang sein, der die Menschen nervös macht. )

Ich bin als Advocatus Diaboli immer eher für vorsorgliche Verkomplizierung

Das scheint mir auch so.

[Aries]

Was bewirkt "Application.Free;"?

[mse]

Was bewirkt "Application.Free;"?

Nun scheint es tatsächlich notwendig, dass du dir etwas Grundwissen über Object Pascal aneignest. Wie Theo schon schrieb, können dazu auch für Delphi geschriebene Texte verwendet werden. Auch FPC hat eine umfangreiche Dokumentation. Hier nochmals ein link:
http://www.freepascal.org/docs.var

Martin

[mschnell]

Was bewirkt "Application.Free;"?

Ich vermute, dass Application.Free Application.Terminate aufruft und wartet, bis das Queue-Event, dass die Event-Queue stoppt bearbeitet wurde und erst dann die TApplicastion Instanz wirklich freigibt. Sicher bin ich da aber nicht.

Application.Free würde man benutzen, wenn man aus einer "Application" während des Ablaufs ein "Program" machen möchte.

Ich glaiube nicht, dass das irgendeinen Sinn hat.

-Michael

[Socke]

Was bewirkt "Application.Free;"?

Ich vermute, dass Application.Free Application.Terminate aufruft und wartet, bis das Queue-Event, dass die Event-Queue stoppt bearbeitet wurde und erst dann die TApplicastion Instanz wirklich freigibt. Sicher bin ich da aber nicht.

Application.Free würde man benutzen, wenn man aus einer "Application" während des Ablaufs ein "Program" machen möchte.

Die Methode Free macht das gleich wie bei allen anderen Objekten: Wenn die Objektvariable nil ist, passiert gar nichts, ansonsten (man hat ein gültiges Objekt) wird der Destruktor aufgerufen und das Objekt (hier Application) wird freigegeben.

Danach kann man freilich keine Fenster mehr anzeigen. Deshalb wird es in der Unit Forms auch im finalization-Abschnitt aufgerufen. Dieser wird abgearbeitet, wenn das Programm beendet wird (zu diesem Zeitpunkt werden alle finalization-Abschnitte aller Units nacheinander aufgerufen). Eine "Umwandlung" in ein Programm ohne grafische Oberfläche dürfte jedoch nicht das Ziel sein (diese erstellt eher man als separates Programm).

[Christian]

Das macht in dem fall Sinn, wenn man ne eigene Application Klasse erstellen will. Da man die Default Klasse leider nicht vorgeben kann muss man sie erst freen und kann dann seine eigene zuweisen.

[mschnell]

Da man die Default Klasse leider nicht vorgeben kann muss man sie erst freen und kann dann seine eigene zuweisen.

Verstehe ich nicht. Ich habe in früheren Tests schonmal mit einer eigenen TApplication Klasse experimentiert und bin auf so ein Problem nicht gestoßen.

Außerdem passieren die wichtigen Sachen auch nicht in der Unit, die die TApplication Klasse als solche definiert, sondern in den mit §Include und anderen Methoden verwendeten Dateien, die sich mit dem Build-Macro "WidgetType" auswählen lassen. Die "korrekte" Methode für eine alternative TApplication ist also einen neuen WidgetType zu definierenund die Passenden include- und andere Dateien zum Kompilieren zur Verfügung zu stellen.

Dann kann man die neue Application - Art in der IDE mit den Projekt Optionen auswählen.

-Michael

[Socke]

Außerdem passieren die wichtigen Sachen auch nicht in der Unit, die die TApplication Klasse als solche definiert, sondern in den mit §Include und anderen Methoden verwendeten Dateien, die sich mit dem Build-Macro "WidgetType" auswählen lassen. Die "korrekte" Methode für eine alternative TApplication ist also einen neuen WidgetType zu definierenund die Passenden include- und andere Dateien zum Kompilieren zur Verfügung zu stellen.

Dann kann man die neue Application - Art in der IDE mit den Projekt Optionen auswählen.

Ja, das mag vielleicht die "korrekte" Herangehensweise sein, damit kein unnötiger Code im Programm vorliegt oder ausgeführt wird. Nur ist der Weg ein neues Widgetset zu erstellen nicht gerade trivial -- auch wenn fast alles von einem vorhandenen Widgetset übernommen werden kann. Bei vielen Projekten die darauf aufbauen, kann der Aufwand gerechtfertigt sein. Für alles anderes erstelle ich meine eigene Klasse und ersetze das bereits instantiierte Objekt.

Da man die Default Klasse leider nicht vorgeben kann muss man sie erst freen und kann dann seine eigene zuweisen.

Verstehe ich nicht. Ich habe in früheren Tests schonmal mit einer eigenen TApplication Klasse experimentiert und bin auf so ein Problem nicht gestoßen.

In der Unit Forms wird immer ein Objekt der Klasse TApplication erstellt und in der Variablen Application abgelegt. Will man dieses Objekt austauschen sollte man wie folgt vorgehen:

Code: Alles auswählen

uses Forms;
 
type TMyApplication = class(TApplication)
function myfunc(); // Was man auch immer haben möchte
end;
 
begin
  Application.Free; // Objekt freigeben
  Application := TMyApplication.Create(nil);
end.

Wenn man die Zeile Application.Free; auslässt, kann das ursprüngliche Objekt nicht mehr freigegeben werden und belegt weiterhin Speicher. Glücklicherweise wird er am Programmende von modernen Betriebssystemen wieder verwendet (früher war das nicht so).

[mschnell]

Ah, Du willst eine erweiterte Application (type TMyApplication = class(TApplication) ) und keine neuartige Application
( type TMyApplication = class(TCustomApplication) ).

Alles klar.

Könnte das (bereits instanziierte Klasse um neue Eigenschaften erweitern) nicht auch mit einem "Class Helper" o. ä. gehen ?

-Michael

[Socke]

Könnte das (bereits instanziierte Klasse um neue Eigenschaften erweitern) nicht auch mit einem "Class Helper" o. ä. gehen?

Als ich das ausprobiert hatte, gab es die noch nicht. Prinzipiell sind sie aber auch für solche Dinge geeignet (mit den bekannten Einschränkungen).