I like Delphi very much since 1.0. But I cannot understand why nobody speaks about the biggest feature of Delphi: The component based architecture. A Delphi program should always be some component developement. Components are a big architectural feat
You can use the Dde-Client and -Server components.
You can share memory: docwiki.embarcadero.com/CodeExamples/Tok...impleShareMem_Sample
You can use named pipes: cc.embarcadero.com/Item/21893
nsoftware has components for interprocess communication
15 years ago I solved a similar problem with Dde-client and Dde-server components. I've just looked the components still exist.
There is also an article about named pipes.
and an example about shared memory:
Look also at the component tsharing contract.
There are components from nsoftware for named pipes
If you have many similar objects which have subobjects (like e.g. in a particle emitter), it could be useful to have an exemplar object and all the other objects have the same values except for certain subobjects.
There comes my idea for a use of weak references:
All copies of the exemplar object have weak references from their subobjects to the corresponding subojects of the exemplar object.
Only if a subobject of a copy has different values than the exemplar object the weak reference is transformed to a hard reference (by creating a new subobject to a private variable and assigning the weak reference to the private subobject).
(The same is done for the subobjects of the subobjects in the tree of subobjects).
Each object and subobject must have a variable indicating the exemplar object.
Is this an abuse of the mechanism of ARC and weak references?
Will this idea also be possible in future versions of modern programming?
Is this program style acceptable?
Or is there anything better?
For the moment the highest elements of a Delphi application are Forms, Datamodules and Units. I think that it could be a high architectural enrichment if we could add a Storyboard module.
In this module all the forms would be represented by non-visible components and could be connected by actions of the actionlists on the different forms.
At the transition from one form to the other could also be transmitted a result string. Also visual effects could be defined, depending on the action and the resultstring. The transition to another form could be made dependend on the resultstring.
Processes of form transitions could be defined to achieve a desired state of an object or a property of a component.
Intermediary dialogs and messages could be defined and integrity checks.
Forms could be connected to data modules.
If the program finds a storyboard module forms are not managed by the main application unit but by the storyboard manager.
Yes, nice nostalgic games from the last millenium. Emabarcadero shows with those examples that it isn't ripe for actual games. Today we work with prebuilt actors, motions, environments in 3d. Actors and their faces can be morphed and have a reallike
Once Delphi was much powerful than today. There was a 3d-Environment for Delphi. It was able to load full rigged Genesis figures and develop games. Now this framework is lost. With firemonkey this would be the gaming framework number one on many diff