Make control in thread

[Akira1364]

Yes, I understand all that. I wasn't even really referring to the original poster with my second point. Moreso just the general "practice" that seems to exist of creating TOpenGLControls (and TForms, e.t.c, anything really) even in straight-forward desktop GUI applications where it makes no sense.

EDIT: I'm also quite curious as to what hardware "OkobaPatino" is in fact actually running, especially since they claim it is a Windows 10 machine. Perhaps some kind of no-name budget laptop with a low-end integrated graphics card? Even then, though, creating a TOpenGLControl should be a non-issue.

[engkin]

The code presented by OkobaPatino in the first post did show a button on the form for a very short period. 

While the thread lasted the button was visible. Add Sleep(1000) to the end of the thread procedure to get a chance to see the button on your fast computers.

Moreover, the message queue of the newly created thread was empty before and after creating the button. Tested using GetQueueStatus.

Changing the button's parent added messages to the queue.

Adding a simple message loop to the end of the thread procedure, made the button respond to mouse messages:

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

1. type
2.  
3.   { TForm1 }
4.  
5.   TForm1 = class(TForm)
6.     Button1: TButton;
7.     Button2: TButton;
8.     Memo1: TMemo;
9.     procedure Button1Click(Sender: TObject);
10.     procedure Button2Click(Sender: TObject);
11.   private
12.   public
13.     bb: TButton;
14.   end;
15.  
16.   { TBThread }
17.  
18.   TBThread = class(TThread)
19.     msg: string;
20.     procedure SyncMsg;
21.     procedure Execute; override;
22.   end;
23.  
24. var
25.   Form1: TForm1;
26.  
27. implementation
28. uses
29.   Windows;
30.  
31. {$R *.lfm}
32.  
33. procedure TBThread.SyncMsg;
34. begin
35.   Form1.Memo1.Lines.Add(msg);
36. end;
37.  
38. procedure TBThread.Execute;
39. var
40.   AMessage: TMsg;
41.   qs: DWORD;
42.   c: integer;
43.  
44.   procedure Chk;
45.   var
46.     bg: integer;
47.   begin
48.     inc(c);
49.     qs := GetQueueStatus(QS_ALLINPUT);
50.     msg := Format('%d-QStatus: %s',[c,IntToHex(qs,8)]);
51.     Synchronize(@SyncMsg);
52.   end;
53.  
54. begin
55.   c := 0;
56.   Chk;
57.   Form1.bb := TButton.Create(Form1);
58.   Chk;
59.   with  Form1.bb do
60.   begin
61.     Chk;
62.     Parent := Form1;
63.     Chk;
64.     Left := 0;
65.     Chk;
66.     Top := 0;
67.     Chk;
68.     Width := 100;
69.     Chk;
70.     Height := 100;
71.     Chk;
72.     Caption:='Button';
73.   end;
74.   Sleep(1000);
75.   Chk;
76.   while (not Terminated) do
77.   begin
78.     Chk;
79.     if qs<>0 then
80.     begin
81.       PeekMessage(AMessage, HWnd(nil), 0, 0, PM_REMOVE);
82.       if AMessage.message = WM_QUIT then
83.       begin
84.         PostQuitMessage(AMessage.wParam);
85.         break;
86.       end;
87.       TranslateMessage(@AMessage);
88.       DispatchMessage(@AMessage);
89.     end;
90.     sleep(100);
91.   end;
92. end;
93.  
94. { TForm1 }
95.  
96. procedure TForm1.Button1Click(Sender: TObject);
97. begin
98.   TBThread.Create(False);
99. end;
100.  
101. procedure TForm1.Button2Click(Sender: TObject);
102. begin
103.   Self.Caption := bb.Caption;
104.   ShowMessage(IntToStr(ControlCount));
105. end;

[molly]

The code presented by OkobaPatino in the first post did show a button on the form for a very short period.

Yes, i know

I am not aware that LCL is/was declared safe between threads (but perhaps i missed the memo on that one  ).

Your analyses and accompanied code is spot on and also explains/shows why Fungus's solution does work (for the button example at least).

[Okoba]

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.

No I have not but Windows 10 driver for OpenGL in my machine is slow even it is updated and also I saw this problem in two different machine that initializing OpenGL control take about 1 second so I wanted to do the init in a separate thread for avoiding a startup delay in a windows that need to be as fast as possible.

Dear Akira1364, I saw you works on porting DelD and Im sure I can use your experience. About hardware its an 2015 i7 CPU and an onboard GPU, it was good with Win8 and Im sure its a driver related problem for delaying but as I saw this delay in another laptop and PC with less delay but about 500ms I wanted to do a trick and solve it this way.

The code presented by OkobaPatino in the first post did show a button on the form for a very short period. 

Thanks engkin for reporting back your test, I wanted help like this in the first place as it was a question out of curiosity too.

I am not aware that LCL is/was declared safe between threads (but perhaps i missed the memo on that one  ).

Me too and I asked so maybe someone else can explain more about it.

[molly]

I am not aware that LCL is/was declared safe between threads (but perhaps i missed the memo on that one  ).

Me too and I asked so maybe someone else can explain more about it.

You have two threads 1) your application with the Form etc. 2) your tbThread

In threads you are not allowed to change a variable from another thread without taking precautions (as is normal for threads). Changing some of the properties of your dynamically created component creates a chain of changes (writing to variables actions) throughout the component tree of your form. That is not allowed to do from another thread but the form's thread.

The practical changes are listed by the code from engkin.

This is all standard/basic part of threads and sharing variables between threads, so any documentation on the subject is able to tell you this. If you really really want to know the why, then please study thread implementations.
(And before you ask: no, i am not an expert on threads, nor do i claim to have all the answers. I simply read the documentation and apply what is written.)

I doubt any of the other readers is willing to explain the concept of threads (and the implications) as there is already so many written on the subject.

Perhaps you could share what kind of answer you would like to receive ? (e.g. at what kind of technical level) Because right now it appears that you do not understand/like the concept of threads, yet you use them (and even claim to be experienced with the subject).

[Okoba]

Thanks molly, its now more clear for me.
About thread subject Im OK with threads but I never used them with GUI stuff and I never done such prevented task before but now that I done that I liked to know why form will not show the form but in some simpler cases changing GUI in thread will do the job although its not a good approach.

Thanks for the clearification

[Akira1364]

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.

No I have not but Windows 10 driver for OpenGL in my machine is slow even it is updated and also I saw this problem in two different machine that initializing OpenGL control take about 1 second so I wanted to do the init in a separate thread for avoiding a startup delay in a windows that need to be as fast as possible.

Dear Akira1364, I saw you works on porting DelD and Im sure I can use your experience. About hardware its an 2015 i7 CPU and an onboard GPU, it was good with Win8 and Im sure its a driver related problem for delaying but as I saw this delay in another laptop and PC with less delay but about 500ms I wanted to do a trick and solve it this way.

The code presented by OkobaPatino in the first post did show a button on the form for a very short period. 

Thanks engkin for reporting back your test, I wanted help like this in the first place as it was a question out of curiosity too.

I am not aware that LCL is/was declared safe between threads (but perhaps i missed the memo on that one  ).

Me too and I asked so maybe someone else can explain more about it.

Is what you're currently using the laptop or the PC? And do you know the model number of the i7? (like 4xxx, 5xxx, 6xxx, e.t.c.) Intel Graphics drivers can get a little confusing sometimes due to the sheer number of series variants, so it's quite possible you've installed the wrong one by accident.

[Okoba]

Take this machine I tested as example : i7 4790K.
I think not because Windows installed it automatically and for being sure I got the last official driver version for Win10 and tested it, nothing changed.

[Akira1364]

https://downloadcenter.intel.com/download/26079/Intel-Graphics-Driver-for-Windows-10-15-40-4th-Gen-?product=81496

Just to be sure, that's a link to the latest official Intel Windows 10 HD4600 graphics driver, which is what you want to be using with an i7-4790K. Is that what you have installed?

[Thaddy]

Anyway. This silly thread should be marked in RED even if there are answers that ultimately made stupidity work.
When somebody else reads it, he or she may think what's discussed here is actually a viable option.
IT IS NOT.

What we have here is a stupid, half-educated nitwit that tries to push his bad idea.
This should really be made private to not confuse proper programmers.

I am in bad mode/mood again! 

[engkin]

Thaddy, since you are/were in a bad mode/mood, I thought to ask you about passing True to IsGUIThread? 

[Thaddy]

Oh, Well. (Brlliant song by the real Fleedwood Mac)
I'd rather you review my write up on interfaces. Only Marco had decent informed critisicm.
Yours is higly appreciated.

[molly]

Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. 

[Thaddy]

Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. 

Mes quoi?, idiots savants? Toutes les imbelices ici? 

[JD]

Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. 

On se calme. Faut pas s'enflamé pour rien. En plus, on aura toujours des questions comme ça. Il faut savoir les gérer avec sagesse et pas la colère.