@bee:
I don't question your motives as i assume they are sincere, although i do agree with taazz.
But, i have a hard time understanding the how part, e.g. how you envision this to be implemented.
Object oriented programming requires a different mindset, hence the solutions provided that uses such mindset (and which don't seem to match your idea's).
What i seem to understand from your point of view, is that the user still uses procedural routines in order to create an GUI application.
This is possible to a certain extend, e.g. implementing events would then be out of the question.
But that's rather awkward, to use an object oriented class (such as application), that takes care of talking to the OS and divert incoming user input etc. A class like TApplication is meant to be used in a certain way as shown by the (already available) presented solution(s).
In principle it is possible to use only procedural code (except for the application/GUI creation parts) to create simple GUI applications, and the most useable approach would be that of something similar as shown by user FTurtle.
But, that can only be done in a sane way by either leaving out the separate project vs form units in which case your project file looks something like:
Type
TForm1 = class
...
end;
Var
Form1: TForm1;
Procedure CreateGUI;
begin
Application.CreateForm(TForm1, Form1);
AddLabel(...)
etc...
end;
begin
Application.Initialize;
CreateGUI()
Application.Run;
end.
As shown by user FTurtle.
Or by using a separate unit that declares the form and implements the CreateGUI() procedure, as also shown by user FTurtle.
This is simply how the Application class is intended to work:
- Intialize the application
- Add forms/modules/etc.
- Use either form/module create or other events to make adjustments
- make adjustments just before running the application.
- Call application's run method, effectively 'handing over control' to the application object, handling the user input
- return when application was terminated or all forms closed
Additionally you can use Form/Module/Application class events to handle particular events.
If that doesn't really suit your needs then i see no other way then to create your own custom application class to be able to do your bidding. In that case something like:
MyCustomApplication.ExecuteProceduralRoutineThatDoesThingsJustbeforeCallingRun(@CreateGUI)
comes to mind, although you could achieve the same with the code already shown.
Alternatively, it is always possible to create native GUI elements manually, but i guess that would be even more out of scope (as that renders things platform dependent).
Or to put it into other words, what is allowed (especially OOP-wise) to achieve your goal ?