It would, for me, be something I would use sparingly. Where two operating systems were very different in a given feature. For example, if we had to create message dialogs ourselves and windows require a long short window and mac now use the tall narrow ones. It could be done with a lot of code moving items around at runtime or a feature like this could be used to do it.
I’m fully aware that it isn’t required for message dialogs, it was just an example. I don’t see it being required for XAML in the future either. When the stock controls are build in using XAML you should just be able to use them exactly as you do now. It would show as a Mac button on Mac and a Windows XAML button on Windows. If enough people wanted to be able to reconfigure the XAML under the hood a feature request needs to be generated in order to allow a method for that to work (on Windows only).
It has already been stated that the current XAML control can be placed on a window and you would still be able to compile for Mac, where it would simply ignore that control at compile time.
I still like my idea for other purposes though. For example if we are able to indicate a window for Mobile and a Window for desktop you could have a universal project type that could compile for either platform.
The XAML controls (once delivered), may be a switch for the whole app.
A lot of things are yet to be defined.
The XAML island concept allows you to bridge the worlds and get such a new style control on an existing window in Win32.
And until all regular controls switch to XAML, you have the container as a playground in one of the next versions. You may never need the #if unless you do something Windows specific here.
People use it. Because people from different OSs may demand different UI experiences, iconography (SF Symbols is a Mac only thing for example), split window for one, tabs for another, Cancel + OK button on the right for a LTR window, OK+Cancel on the left for RTL, etc. and you may have lots of different options not matching 1:1 between platforms the native kit of those OSs offer and having separated views would let the dev use it as they wish.
I understand that. I did explicitly say “for me”. Anyhow, I have created a feature request for such an item, as I couldn’t find one. I’ll post information in the correct area of the forum. to keep the discussions in one place.
Not sure if one already exists. I asked one years ago and it was ignored, maybe “too advanced” for that phase? We were discussing those subjects in a beta phase. Right now, with different UI kits floating around, it may not be ignored anymore. Make a link there pointing this discussion for more context.
Here is the place for noise. The feedback is the place for talks with engineers. Engineers can come here for insights and observe reasoning amongst the noise.
Long term yes, but if you wanted to start using these right away when only the container was available, it would certainly give someone a path forward.
Which would be why I created a topic here on the forum for that noise. Currently we are cluttering the discussion about XAML, rather than Window personalities.
I understand, but a premature introduction of a incomplete feature would start to create “legacy code” right away. Engineers should take a time planing ahead a little bit more to avoid it.
The change for all controls will be pretty much the same as it was for the change from Carbon to Cocoa, which made no difference to Linux or Windows. Perhaps it is a language problem but I am not understanding the issue with this.
I may have missed something - this was years ago - but I long since wrote off any hope of using an OCX in a windows build of an app for which I also wanted a Mac version.
I certainly remember that you had to add your own “#if Target” tags around the code it produced, but it’s been a long time since I used OCX, are they even a thing anymore?
Dunno. As I say, I long since wrote from scratch all the things I used to use OCX for, (or used MBS plugins.)
But it was a bit of a show stopper back in the day… if I put one on a form, I couldnt build a Mac app.
