@microsoft-github-policy-service agree

Love this! @pictos - Does this introduce any breaking changes to Popup?

Love this! @pictos - Does this introduce any breaking changes to Popup?

Nope. None so far. No method signature changes (e.g. parameters, return types).

Oh sorry. Just noticed that you tagged someone else

Love this! @pictos - Does this introduce any breaking changes to Popup?

From my review it doesn't have any break-change

Thanks for the PR @babenkovitaliy, I was thinking here... We know what's the Popup.Parent, and it should be a Page, can't we get the information on that Page instead of looking up all available ViewControllers? Since we have a loop inside a loop it could be a O(n²)

I tried doing that.

• The Popup.Parent is a "Virtual View" - meaning that it is not native to a specific platform - there are no properties that point it to an associated native UIView. So that makes this task impossible.
• IIRC, there was a method that was able to create a UIViewController from a View, but it created a new instance of it instead of referencing the one that is currently in runtime. So that makes this task impossible.
• That is when I had to go in reverse - I took a Virtual view from Popup.Parent and tried to see if the Native Window had a UIViewController that had a reference to the Virtual View. Thankfully, I found a property under UIWindow.RootViewController called CurrentView. That was the only place that referenced the Virtual View inside a Native View. That is the reason I went with this route.

TLDR: Virtual Windows, Views, ViewControllers etc. know nothing about Native UIWindows, UIViews and UIViewControllers. However, Native UIWindows, UIViews and UIViewControllers do reference that Virtual Windows, ViewControllers and Views.

@dotnet-policy-service agree

The Popup.Parent is a "Virtual View" - meaning that it is not native to a specific platform - there are no properties that point it to an associated native UIView. So that makes this task impossible.

You can do something like

var pagehandler = VirtualView.Parent.Handler as PageHandler;
var viewController = pagehandler.ViewController;

and we're sure it's a PageHandler because we force it to be on the SetElement method

The Popup.Parent is a "Virtual View" - meaning that it is not native to a specific platform - there are no properties that point it to an associated native UIView. So that makes this task impossible.

You can do something like

var pagehandler = VirtualView.Parent.Handler as PageHandler;
var viewController = pagehandler.ViewController;

and we're sure it's a PageHandler because we force it to be on the SetElement method

I'll try to look into this and update the PR if this indeed will work. This would be a much better solution. The small catch is that I may have to tackle this sometime this weekend.

Alright. I have made the changes. I have tested out in a separate app I built where I referenced the compiled DLL files. The Popups work nicely now.

Fun, but controversial sidenote: I never realized how much I got spoiled by Visual Studio for Windows IDE. The rebase process is so much more nicer when using the GUI vs the command line (when you are not familiar with the command line). Since I was using Visual Studio for Mac, the GUI rebase process is more painful, so I had to switch over to command line. Ashamed to admit that it took me longer than it should have.

@babenkovitaliy if I told you how many times I missed up my branches using rebase, on both GUI and command line, you would not believe it kkkkk.

Thanks for the update and glad that worked as expected (:

These changes look good. Thanks @babenkovitaliy and @pictos

Is it good to merge?

Yes, it's. Enabled the auto-merge

However, due to this change, the background color of the popup has become extremely light.

After：

Before：