qzmpal / dcef3

Automatically exported from code.google.com/p/dcef3
0 stars 0 forks source link

TChromium messes up the order of TForm.onActivate, TForm.onCreate and TForm.Create #37

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem:
1. Put a TChromium on a Form

What is the expected behaviour:
1. TForm.Create begins
2. TForm.Create ends
3. TForm.onCreate happens
4. TForm.onShow happens
5. TForm.onActivate happens

What do you see instead:
1. TForm.Create begins
2. TForm.onActivate happens
3. TForm.Create ends
4. TForm.onCreate happens
5. TForm.onShow happens

Environment:
DCEF3 public master branch of today (Commit hash: 
24038bd3a600df2feb349cd0cffd68a8da40bd12)
Delphi XE2
Windows 7 x86_64
Building an x86 Application using VCL Forms

Seems to known for some time now: 
https://groups.google.com/forum/#!msg/delphichromiumembedded/skxrZBdFwQM/jBbHIsk
mVPIJ

I added a workaround that kinda suppresses the problem.

Original issue reported on code.google.com by stefan.s...@hasomed.de on 16 May 2014 at 11:29

Attachments:

GoogleCodeExporter commented 9 years ago
CEF's LoadUrl() method calls SetFocus. And if that happens before the TChromium 
control is actually visible (IsWindowVisible), the events fire in the wrong 
order.

This can be prevented by implementing the OnSetFocus event and skipping the 
default "SetFocus" by setting Handled:=True

procedure TForm1.BrowserSetFocus(Sender: TObject; const browser: ICefBrowser; 
source: TCefFocusSource; out Result: Boolean);
begin
  if not Showing then
    Result := True; // Handled, don't call "SetFocus" if the control isn't actually visible
end;

Original comment by Andreas....@gmail.com on 22 Aug 2014 at 11:43