Why form.show is called before form.create in firemonkey?

Question

Everyone know tell me why Form.show is called before that Form.create if property Form.visible = true.

I tested in Delphi XE7 and Delphi 10 Seattle (Fmx form compiled for windows)

Ex:

    procedure TForm1.FormCreate(Sender: TObject);
    var
      i : integer;
    begin
      //break point here is called before if form.visible = false
      i := 0;
    end;

procedure TForm1.FormShow(Sender: TObject);
var
  i : integer;
begin
  //break point here is called before if form.visible = true
  i := 0;
end;

Edaedacious

Probably because OnCreate is called after the form is constructed, and the form is constructed visible when visible is true. – Danicadanice

Answer 1

If the main form is not set to be visible in the designer then the call to CreateMainForm() will force the form to be visible after construction is complete (and therefore after OnCreate has fired).

procedure TApplication.CreateMainForm;
var
  I: Integer;
begin
  if FMainForm = nil then
  begin
     // here creating form...
  end;

  if FMainForm <> nil then
    FMainForm.Visible := True;  //** force visible here
end;

Otherwise, the form's Visible property is set during the call to TCommonCustomForm.Loaded(), which is called by the DFM streaming system during form construction, and thus triggers OnShow when the form becomes visible. OnCreate is not called until after construction is complete, after the DFM is streamed.

The bottom line is that you should not be making assumptions about when these events will be executed. If you need to control the order in which things happen, you'll need to do it explicitly.

Noisette

My form created is not the mainForm, is a secondary form. So, the construction is called by TCommonCustomForm.Create(AOwner: TComponent). I think that this problem ocurred on "NotifyGlobalLoading" in this constructor – Edaedacious

@MaycollTrevezani If the form is not the main form then the case for Visible=true is still the same. – Noisette

It's not an assumption that something must exist (be created) before it can be shown. It's a simple truth. The VCL form events reflect this (and are documented - no need to assume). The FMX form behaves differently because.. reasons. The documentation states that OnCreate occurs first and does so when the form is created, not after. The documented event order neglects to even mention OnShow. Almost as if they are embarrassed about what I would consider a bug. – Justiciar

I'm with Deltics on this. It is a reasonable assumption, I would also consider it a bug on that basis alone. – Lawford

@Justiciar The VCL documentation states that OnShow happens after OnCreate. The FMX documentation only states that OnActivate happens after OnCreate (if Visible is true, in both cases). Being cross-platform, you have to expect that certainty about the order of events occurring is lower than for a single-platform framework. It's not a bug unless it does something other than what the documentation says it should. – Noisette

@JasperSchellingerhout - I disagree strongly. When coding platform-natively you have to take such things into account, but not when using something like FireMonkey. Being a cross-platform abstraction specifically intended to facilitate single-source multi-platform development you would reasonably expect that FMX ensures consistency of it's behaviour across platforms. These are FMX events, not surfaced platform events. If that cannot be provided then the variances should be documented precisely so that flawed assumptions are avoided. The lack of doc in this case is very bad smell imho. – Justiciar

@Deltics. I agree with you. I think you meant J... I meant a bug in FMX – Lawford

@JasperSchellingerhout - oops, yes. Apologies. Damn you auto-complete. :) – Justiciar

@Justiciar I don't believe there is any inconsistency within FMX about when these events fire - it is simply different than the VCL. My point was that, being a cross-platform abstraction, there are fewer commonalities between platforms and therefore fewer common certainties about the order of events within an encapsulated operation. In this case, we have an order-of-operation guarantee (FMX) for two events instead of four (VCL). – Noisette

@Noisette you're muddying the waters to excuse a ridiculous line of reasoning. Either platform variations are involved or they are not. In this case they are not so that's entirely irrelevant. Then we have OOp guarantees, which can legitimately be different between frameworks, but the real issue here is that the documented OOp clearly states one thing when the observed OOp is different (irrespective of platform). That's either a defect in the implementation or a defect in the documentation. But it's definitely a defect. – Justiciar

@Justiciar I don't see what this difference is. You said The documentation states that OnCreate occurs first and does so when the form is created, not after. The documentation does not state this at all - it says OnCreate is invoked by the constructor, meaning that it will fire at some point during the many steps involved in the form's creation. There is no such thing as "when it is created" - it's a process and the event happens during that process at some point. The only guarantee is that OnActivate will happen after OnCreate, not that OnCreate will be the very first event fired. – Noisette