Destroying Controls at Runtime
In uniGUI, it is possible to destroy a control at runtime by calling its Free() method. This will remove the control from its parent and destroy it and all associated resources. However, calling Free() manually is not recommended unless there is a good reason. It is generally better to allow uniGUI to manage when controls must be freed.
Normally, controls are destroyed when their owner form is closed. If the owner is a TUniFrame, its child controls will be destroyed when the owner form is closed. In some cases, controls or a TUniFrame may reside inside a tab page (TUniTabSheet) of a page control. If the tab page is closeable, it will be freed when the user closes it; all of its child controls will be freed as well.
You can create controls dynamically at runtime, but you should leave the destruction of those controls to uniGUI. As a general rule, controls should be freed by user actions such as closing forms, closing tab pages, ending a session, etc.
Avoid calling Destroy() or Free() on visual components at runtime except when absolutely necessary. The web's asynchronous nature can make manual freeing risky and lead to server exceptions.
Example scenario illustrating the problem
You have a UniDBGrid populated with data on the screen and you call its Free() in a button's OnClick handler:
procedure TMainForm.UniButton1Click(Sender: TObject);
begin
UniDBGrid1.Free;
end;Because communication between server and client is asynchronous, there can be a delay between the user pressing the button and the grid being freed and removed from the UI. During that interval the user may still interact with the grid, generating events sent to the server. Those events cannot be processed because the grid no longer exists on the server, which can raise exceptions.
This could be mitigated by showing a screen mask (blocking user interaction) until the grid is fully removed, but that approach increases complexity and is easy to forget — especially since the issue often only appears on slow internet connections and not on fast local networks.
Best practice: let the framework free controls through normal user-driven lifecycle events (closing forms, closing tab sheets, ending sessions, etc.) rather than manually calling Free() for visual controls at runtime.