Make control in thread

[Fungus]

The only way I can think of that MIGHT do the initialization in another thread is this:

Code: Pascal  [Select][+][-]

1. procedure TBThread.Give2Form;
2. begin
3.   Form1.bb := GLCtrl;
4.   GLCtrl.Owner:= Form1;
5.   GLCtrl.Parent := Form1;
6. end;
7.      
8. procedure TBThread.Execute;
9. begin
10.   //GLCtrl is private member of TBThread
11.   GLCtrl := TButton.Create(Nil);
12.   with  GLCtrl do
13.   begin
14.     Left := 0;
15.     Top := 0;
16.     Width := 100;
17.     Height := 100;
18.     Caption:='Button';
19.   end;
20.   Synchronize(Give2Form);
21. end;

The code is untested and I have no clue wheter it works or not.

[molly]

Thanks for your helps but "learn to live with it" is not a good answer, sorry.

Your problem. Buy yourself a better OS and faster hardware.

So please tell me "why" form wont show the control?

You are asking me to teach you how threads and sharing variables between threads work.

There a million of documents on that subject on the interwebs and Thaddy already explained the why as well as the links i showed you.

I'm done with this discussion.

[Fungus]

Thanks for your helps but "learn to live with it" is not a good answer, sorry.

No, but it might be the only true answer you'll get. Your control is not displayed because it's message queue probably is bound to the secondary thread.

[Okoba]

 

I like you Thaddy, an angry man.
molly it seems you need to learn more about making good stuff and also reading others questions better, I didnt want to teach me threads, but thank you very much for trying to help.
Fungus thanks for the code but it is not working and and it seems you didnt read the question carefully as molly, setting Parent property takes time so doing it with Synchronize doesnt make any changes.

And for the last point buy a new OS is a funny answer in such situations.

[Fungus]

Fungus thanks for the code but it is not working and and it seems you didnt read the question carefully as molly

And it seems like you do not read or understand the answers as carefully as you should. I'm out, waste of time to help the blind seeing the invisible.

[molly]

The joke is on you my friend but it seems that you are too hardheaded to realize that.

molly it seems you need to learn more about making good stuff and also reading others questions better,

Cat blaming the cattle 

.. I didnt want to teach me threads, but thank you very much for trying to help.

Contradictio in terminis

Fungus thanks for the code but it is not working and and it seems you didnt read the question carefully as molly, setting Parent property takes time so doing it with Synchronize doesnt make any changes.

At least fungus understood part of the problem, this in contrary to you.

And for the last point buy a new OS is a funny answer in such situations.

You do not even have the decency to quote me correctly. And you blame me for not reading properly ?

Now, i'm really gonna stop (unless i feel the need to defend) as this is heading towards personal grieve.

And it seems like you do not read or understand the answers as carefully as you should. I'm out, waste of time to help the blind seeing the invisible.

Exactly !

[Okoba]

Ok here is the temporary solution for OpenGL delay:

Code: Pascal  [Select][+][-]

1. unit Main;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, FileUtil, Forms, Controls, StdCtrls, Graphics, Dialogs, ExtCtrls,
9.   OpenGLContext;
10.  
11. type
12.  
13.   { TForm1 }
14.  
15.   TForm1 = class(TForm)
16.     Button1: TButton;
17.     Button2: TButton;
18.     procedure Button1Click(Sender: TObject);
19.     procedure Button2Click(Sender: TObject);
20.     procedure FormCreate(Sender: TObject);
21.   private
22.   public
23.     op: TOpenGLControl;
24.   end;
25.  
26.   TBThread = class(TThread)
27.     procedure Execute; override;
28.   end;
29.  
30. var
31.   Form1: TForm1;
32.  
33. implementation
34.  
35. {$R *.lfm}
36.  
37. procedure TBThread.Execute;
38. begin
39.   with TOpenGLControl.Create(nil) do
40.   begin
41.     Parent := Form1;
42.     Free;
43.   end;
44.   WriteLn('Done');
45. end;
46.  
47. { TForm1 }
48.  
49. procedure TForm1.Button1Click(Sender: TObject);
50. begin
51.   op:=TOpenGLControl.Create(Form1);
52.   with op do
53.   begin
54.     Parent := Form1;
55.     Left := 0;
56.     Top := 0;
57.     Width := 100;
58.     Height := 100;
59.     Caption := 'TOpenGLControl';
60.   end;
61. end;
62.  
63. procedure TForm1.Button2Click(Sender: TObject);
64. begin
65.   ShowMessage(IntToStr(ControlCount));
66. end;
67.  
68. procedure TForm1.FormCreate(Sender: TObject);
69. begin
70.   TBThread.Create(False);
71. end;
72.  
73. end.

As you can see making a temp control make all the initializing and after that whenever you make a new control it will be made instantly.
It helps me to make my own control when thread job is done without showing waiting or freezing my app.

@All I still like to know about why form doesn't show components that made in a thread? Again I know its wrong but I like to know technically why "it doesn't show them".

[Okoba]

Dear friends, please dont make it personal. Thank you very much for trying to help others, I just wanted more clarification about some stuff but you guys insist on this is wrong although Im fully aware of what was wrong, I just wanted better explanation than "Dont do that!" or "Buy a new machine!".

[serbod]

https://www.opengl.org/wiki/OpenGL_and_multithreading

[molly]

As you can see making a temp control make all the initializing and after that whenever you make a new control it will be made instantly.
It helps me to make my own control when thread job is done without showing waiting or freezing my app.

... and which can also be solved by directly creating the component in a (one time) onidle or (one time) timer event or even using QueueAsyncCall() 

[x2nie]

I agree with Molly in all of his/her post of this topic, except of let you to buy new machine.

It helps me to make my own control when thread job is done without showing waiting or freezing my app.

@All I still like to know about why form doesn't show components that made in a thread? Again I know its wrong but I like to know technically why "it doesn't show them".

While you creating controls without showing waiting or freezing your app, it mean that you really want to create them out of the box, right?
I think the wrong part is you need to tell the app that that "out of the box" work is done and it is now the time for app to take over that control, which it seem you didn't do that.


You need to "TELL THE APP" like synchronize(), or send message to form to refresh / repaint / whatever needed signal that mean: everything is back on track.


For comparison, I work on WinCE+WindowsMobile with C# and the concept is similar: Form has it's own thread and working on separated thread need to to tell the form to refresh, in the end.

[Okoba]

Thanks for the link.
Thanks molly, I tried QueueAsyncCall and it will freeze the app again but as you said and my last source shows run it in a separate thread will do the job for know.

x2nie, thanks for the input but I test synchronize refresh or invalidate but no Button Yes yes i know making Button in a separate thread is not a beautiful way but why form doesn't show it at all even its aware that it has a component? it is a question out of curiosity.

[molly]

I agree with Molly in all of his/her post of this topic, except of let you to buy new machine.

I already knew this from experience, but .. well .. you got me motivated enough to actually test this on an atom box (N270) with windows installed :-)

The example accompanied with lazarus, which creates a gl context, takes approx 0.01 seconds to start on that setup. And that example creates the gl context inside the formcreate event.

So either TS has a very slow machine/hardware/os, some faulty drivers/setup or (what i actually suspect) is perhaps not telling the complete story.

Another situation in which i can imagine such slowness being presented when creating a GL context is when using a software only gl implementation.

[Akira1364]

There's certainly a "language barrier" issue going on in here, but if I'm parsing the gist of things correctly, is "OkobaPatino" suggesting that simply creating a TOpenGLControl is somehow too resource intensive for his/her PC? Unless they haven't upgraded their hardware since the early 90s, I don't see how that's even possible. Also, on a related-but-somewhat-abstract note, what is with the insistence everyone has on creating TOpenGLControls "in code"? There's nothing to be gained from doing so. Unless you're a big fan of writing boilerplate code to assign the "OnMouse/OnKey/e.t.c" handlers, which I don't think anyone is. It's a design-time component. Just plop it on your form and be done with it!

[molly]

There's certainly a "language barrier" issue going on in here,

That's a bit of an open door ...   

Unless they haven't upgraded their hardware since the early 90s, I don't see how that's even possible.

Oh, i can imagine some scenario's. Perhaps Windows 10 should be read as Windows 10 IoT, and it is running on a raps_my_berry_until_it_is_blue-pi, using a software renderer driver.

Also, on a related-but-somewhat-abstract note, what is with the insistence everyone has on creating TOpenGLControls "in code"? There's nothing to be gained from doing so.

Plopping a control on a form, means that control is created when the form is created (there are also others that tend to forget that and 'plop' just about anything on their main form that they are able to get their hands on, including databases etc with connections and queries all set and ready = very very bad habit).

Since TS has an issues with the duration that it takes to create the context (assuming TS confirmed this was the root of the problem. This creation is 'blocking' his/her form in the process), TS was starting to search for alternatives.

When you create a gl context, things are (usually) cached so that a second context creation will appear to be instantaneous, hence the obsession of TS with using a thread to create that (very) first context.

One can prevent the 'blocking' by implementing a workaround as suggested (and yes, not all suggestions made by me might perhaps work as equally well under certain circumstances. Simply test and learn from it).