Create multiple instances of tApplication with multiple MainThreads?

[microtronx 38]

Hi Folks,

 

is it possible to have multiple MainThreads with multiple tApplication instances within one application? Something like this:

 

procedure TForm2.bNewApplicationFormClick(Sender: TObject);
var
	vapplication:tApplication;
	vNewForm:tForm2;
begin
	IsMultiThread:=true;

    vApplication:=tApplication.Create(nil);
	vapplication.Initialize;
	vapplication.MainFormOnTaskbar := True;
	vapplication.CreateForm(TForm2, vnewform);
	vapplication.Run;
end;

I'm searching for a way, having multiple forms with different MainThreads in runtime instead of having multiple application-instances (exe files) started.

[Dalija Prasnikar 1396]

No.

[microtronx 38]

19 minutes ago, Dalija Prasnikar said:

No.

Since we're all crazy programmers ... is "No" acceptable? Any explanation of why No?

[programmerdelphi2k 237]

look, each "TApplication" represent a "application = process" on memory!

then, have many "TApplication" means have many process of same process (or be: clones)... but at end, all clones will be the same app!

what you can do is: many forms and changes one or other to be "the main-Form", but not all at same time!

-- because, you cannot have 2 or more "main-Forms" in the same application!

Edited December 2, 2022 by programmerdelphi2k

[shineworld 73]

TO BE very SIMPLE, TApplication, with Application instance, is or at least should be a Singleton, because manages the main events loop from Windows.

You can't have more than ONE...
It's the Windows structure of any application.

When you run a program Windows create a process with a main thread which call the delphi main code.
This main code create Application object which manage the messages loop (Windows is a messages-based OS) and on this
messages loop manager is implemented all VCL framework, etc...

Edited December 2, 2022 by shineworld

[Lars Fosdal 1792]

There can be only one main thread. It doesn't need to do anything else but to spawn n number of other threads, each of which can have their own purpose, and can spawn their own sub-threads.

 

[programmerdelphi2k 237]

I know about loop, I came form "Clipper summer87"  

the same "principle" is used in GUI app... a looping "REPEATing" until end message!

Edited December 2, 2022 by programmerdelphi2k

[microtronx 38]

@all Thanks for your clarifications. Now I accept "No."

[shineworld 73]

6 minutes ago, programmerdelphi2k said:

I know about loop, I came form "Clipper summer87"  

I began with pure C + Win32 SDK + Petzold book (https://www.charlespetzold.com/pw5/index.html) but 1st edition 🙂
when you have to manage manually the events loop...

Edited December 2, 2022 by shineworld

[Dalija Prasnikar 1396]

11 minutes ago, microtronx said:

Since we're all crazy programmers ... is "No" acceptable? Any explanation of why No?

It is complicated...

 

In theory you can have Windows application that has multiple GUI threads with each one holding own windows message loop.

 

The answer is no, because VCL is build on the premise of single main (GUI) thread (like many other frameworks as there is really no advantage of having such multithreaded GUI) and you would have to write your own framework to achieve such application and probably would have to rewrite significant parts of the RTL.

[programmerdelphi2k 237]

"A thread is the entity within a process that can be scheduled for execution. All threads of a process share its virtual address space and system resources. Each process is started with a single thread, but can create additional threads from any of its threads"...

https://learn.microsoft.com/en-us/windows/win32/procthread/multiple-threads

 

then, in fact, there is just one "main", the rest is co-adjuvant process

[Remy Lebeau 1398]

5 hours ago, microtronx said:

is it possible to have multiple MainThreads with multiple tApplication instances within one application?

No.

 

First, not even considering threads yet, TApplication is simply not designed to run multiple instances at a time.  There are globals that it uses internally which it assumes it has exclusive access to, and will not share well with other instances.  Also, there is plenty of code inside of the VCL that assumes there is only 1 global TApplication object, and won't even consider the existence of other instances.

 

Second, considering threads, the VCL is simply not thread-safe to begin with.  It is not designed to be used in multiple threads at a time.  VCL controls are expected to be used only in the main UI thread which runs the single global TApplication object.  Also, the VCL runs on top of the Win32 API, and API window handles have an affinity to the thread that creates them, which restricts which threads are allowed to access them. And VCL controls simply don't react well when those window handles get messed up when accessed across thread boundaries.

Quote

I'm searching for a way, having multiple forms with different MainThreads in runtime instead of having multiple application-instances (exe files) started.

Don't do it.  That is a very bad design choice.  Handle all of your UI needs in the default main UI thread only.  You can use multiple worker threads to handle your business logic however you want, and you can create a separate TForm to associate with each worker thread if that is what you need.  Just make sure that any data you share across threads is adequately protected from concurrent access, and that you have worker threads synchronize with the main UI thread whenever they need to access the UI.

Edited December 2, 2022 by Remy Lebeau

[Dave Nottage 557]

5 hours ago, microtronx said:

I'm searching for a way, having multiple forms with different MainThreads in runtime instead of having multiple application-instances (exe files) started.

What is it that you think this will achieve? 

[David Heffernan 2345]

On 12/2/2022 at 2:29 PM, shineworld said:

TO BE very SIMPLE, TApplication, with Application instance, is or at least should be a Singleton, because manages the main events loop from Windows.

You can't have more than ONE...
It's the Windows structure of any application.


This isn't really true. You can have multiple threads that serve multiple windows with different message loops. 

 

Windows supports that. 

 

What you can't do is do that in vcl. 

[shineworld 73]

Is Windows UI API SDK (WIN32) thread safe, eg EDIT, COMBOBOX, etc ? 

I missed that... Sorry

[David Heffernan 2345]

12 minutes ago, shineworld said:

Is Windows UI API SDK (WIN32) thread safe, eg EDIT, COMBOBOX, etc ? 

I missed that... Sorry

Yes. But of course you need to define what thread safe actually means in this context. It's a very general term. For win32 the threading model is that all operations on a window must be performed in the thread that created the window. Queued messages for that window are delivered to the meesage queue of that thread. Nonqueued messages are synchronised onto that thread. 

 

This is not a free for all thread safety where you can do anything you want from any thread. This is why the term thread safety is often not useful. It's more useful to describe and summarise the threading model. In this case I always say that windows have thread affinity. 

[microtronx 38]

On 12/2/2022 at 8:07 PM, Dave Nottage said:

What is it that you think this will achieve? 

Main reason is to have multiple forms not "blocking the whole app" i.e. when the cxgrid refreshes data ... This cannot be done in a background thread and we're working with a lot of tables / rows at the same time from different forms.

[programmerdelphi2k 237]

maybe be better review your "query" parameters to avoid excessive records on cxGrid, or send it in "batch" to screen! cxGrid can define how much records can be loaded by time!

[microtronx 38]

1 hour ago, programmerdelphi2k said:

maybe be better review your "query" parameters to avoid excessive records on cxGrid, or send it in "batch" to screen! cxGrid can define how much records can be loaded by time!

Yes cxgrid can be configured, but if you need the grid in GridMode=FALSE to use special functionality (filtering, grouping, sorting, etc) the grid needs to load all data ... and this makes it harder for us.

thanks for you suggestion.

[programmerdelphi2k 237]

maybe yes, maybe no!

you can use a specifc "query" to filter your data before bind it to cxGrid!

• the query-return will so quick than your system!
• you can works in "offline" mode (cache)

but I think that your better choice would be contact DevExpress for more details!

Edited December 5, 2022 by programmerdelphi2k

[Brian Evans 105]

cxGrid has Server Mode which gets you a lot of the benefits of Grid Mode without loading every record for large result sets. Has some limitations but overall works very well.

Server Mode | VCL | DevExpress Documentation

 

 

[Fr0sT.Brutal 900]

Quote

Our grid control's DataController is still populated with data in a single thread. However, now some operations (filtering, sorting) can be performed in secondary threads. Please review the "Multi-Threaded Data Processing" help topic for details.

https://supportcenter.devexpress.com/ticket/details/q267890/cxgrid-and-async-fetch

 

Maybe this will help? Googled it in 1 minute