#318 DPFTabBarController Tabs not visible when placed on a DPFNavigationController

[Paul]

To test, simply drop a DPFNavigationController on a form, add a page then drop a DPFTabBarController on the page. Add a couple of tabs and run. The DPFTabBarController tabs never appear. Also, it seems that controls aligned in the tab pages are not aligned correctly i.e. they are too tall and extend beyond the bottom of the page.

[Paul]

Temporary solution: Drop the DPFTabBarController on a TDPFUIView then onto the DPFNavigationController.

[Sebastian Zierer]

I think this is because Babak uses the Loaded method for creating the native controls. Unfortunately the Loaded method is not always called in the order that is required. Changing/fixing this is not a trivial task because of the number of components.

[Paul]

What if AfterConstruction was used instead of Loaded?

[Sebastian Zierer]

I think this needs to be done in SetParent.

[Paul]

I notice that functions like setFrame and setHidden are sometimes called from several different places in a DPF control.

How about introduce a new virtual method (DoFMXControlChanged?) in the base control and call it whenever an event happens that needs the native control to be updated e.g.

Parent Changed
Visibility Changed
Position Changed

Each time the event is fired we update the properties of the native control. If an ancestor needs to know when such an event happens it can override the virtual method.

[Sebastian Zierer]

Yes, these 3 events should be implemented. But I wouldn't use DoFMXControlChanged for all of these. I'd prefer to have individual events in order to get good performance and avoid flickering.

Another trick is that some of the methods we need to override in order to do it right were introduced in XE6. So what I'd really like to do is drop support for XE4 and XE5 in order to move forward more easily. It's not possible to submit an XE4 app to the iOS appstore anymore.

There should also be events similar to CreateWindowHandle/DestroyWindowHandle in VCL. This is where the native control will be created and destroyed. That is what I use in my TOSXControl component.

[Paul]

I was thinking to add checks in DoFMXControlChanged so that only the properties that have changed are updated in the native control. This will allow us to add additional properties in the future without changing the overall logic.

I would be in favour of only supporting the latest versions of XE.

I guess we need Babak's input before we start making too many major alterations. Anybody seen him recently? I tried to contact him a few days ago, but no response so far.

[Sebastian Zierer]

I tried that before, but it was not a good approach. I have quite a bit of experience here. I've already done all this for native OSX controls.

• If one control needs different code for just one action, this is not possible. You have to make a copy of the entire
  event.
• You have to figure out what property has changed. Why not use the information that Delphi provides
• It might even be needed to have different events depending on the source of the action. For example a resize could mean that the native control needs to be updated, or that the native control has resized and the FMX control needs to be updated.
• Events could come from parent controls a few levels away. Moving a parent control also indirectly moves the children.
• You'd always have to check all properties. Not good at all. Even worse when loading a component from a form O(n²).
• ...

However I agree that it needs a function that creates the native control and assigns all the properties from the dpf control to the native control (when creating the native control).

[Paul]

I bow to your greater experience :) Are you willing to make the changes or do we need to wait for Babak to return again?

[Sebastian Zierer]

This is very likely going to break backward compatibility with older versions of Delphi. I'd prefer to have an "OK" from Babak first. I'd also be in favor of only supporting the latest version of Delphi.

[Sebastian Zierer]

I got the OK from Babak. We can drop support for older versions of Delphi (XE6 and less) and make the other changes.
I'll have a go at it, but it can take a while because I also have other todos :). I'll have to do it step by step.

[Babak Yaghoobi]

Hi Paul & Sebastian

Thank you for your good jobs