@felix9, you don't post often enough. You really should start a tech blog for this stuff where you could make money on your scoops. I look forward to every time you post on here.
Such bad terminology used. What's meant by synchronous and asynchronous? Each of those calls are made asynchronously, but they are made one after the other in a synchronous fashion. Probably not necessary and you could improve things by not awaiting until all of the calls have been made. Regardless, nothing "blocks" here. We don't see the rest of the code, but I'd assume the View is displayed with no data until after the ViewModel is finally populated by all of these async calls. It would be far better to make these calls internally in the ViewModel. Regardless, one would hope that the UI is reporting we're busy during all of this.
Several bad practices all in a single statement. Gotta love it.
"There is no middle ground between devices that have the Modern UI and devices that have the desktop. You either have the desktop or you have the Modern UI, you cannot have both. As reported around a month ago, the Start Menu for desktop users in Windows Threshold can 'act' like a full screen Start Menu however, meaning if you want that functionality you can have it on the desktop. This will be helpful for devices like the Surface Pro 3."
Hugely stupid. It may make sense to remove the start screen for obviously desktop devices (though I do know a number of non-techie people who like the start screen on desktop computers). However, for hybrid devices it makes no sense to not support both. Full screen or not, a start menu desktop approach would stink when using a Surface Pro as a tablet/consumption device. I use my Pro for both scenarios, and appreciate Win8 as it is today for enabling me to efficiently do either. Make a hard distinction in the OS here will kill hybrid devices like the Surface Pro.
Aug 19, 2014 at 8:59 AM
I'm not trying to make excuses, because it is bad and there is a bunch of crap and worse that I wish Microsoft would weed out before ever accepting into the store, but, the article is also very slanted.
The very first thing they complain about is a search for VLC. I do the same in the Google Play Store and I get roughly 250 hits. Granted, some are only remotely related to VLC, but plenty of them are VLC apps. While most are free, there's definitely some you have to pay for. There's plenty of hits for Firefox as well, though I don't see any that charge you, and obviously none of them will be glorified desktop installers. 7-zip had tons of hits, including pay for apps. None of them will install desktop versions or include bloatware (I assume this claim means the app had to install a desktop application). That would be something unique to this platform, and is bad. That sort of thing absolutely has to be eliminated from the store. But there's claims (I've not substantiated) that the other stores suffer from similar issues such as malware apps.
I want a clean store. And it would be nice if Microsoft could do a better job than the others. But, claims that they are doing worse seem either unprovable or at least questionable to me. More importantly, the actual differences seem to be minor... all the stores are bad.
@kettch: Can you link any of these sites? I've not run across this rumor and I'd love to read about it. A quick search doesn't find anything for me.
Having 4 dialects of Xaml (WPF, Silverlight, Silverlight for Phone and WinRT), just on the UI side (Xaml is also used for other things), is crazy. What's crazier is the newer the dialect, the fewer features. We're going backwards. Fast. So, if we do unify, I hope we do so intelligently. Yeah, there are features, like triggers, that have simpler/better replacements, like VisualStateManager. I can live with "losing" those features. But no ICommandSource? No custom markup extensions? No binding validation? I could go on and on. :(
During Build 2014, I have addressed this question to the C++ panel. However, alas, no promising answer was given to me.
It would be really nice if Microsoft developed a rich UI framework for C++ to be used for desktop apps, and made it part of Visual Studio.
There are third party ones available, but them all lack the Microsoft quality. Also, as they are supposed to be IDE agnostic, they lack Windows specificity, making them too generic.
For store apps, it is possible to use WPF, which is a managed framework.
It would be a very good strategy for Microsoft to promote C++ development, if they wrote a decent UI framework. Let us be sincere, it should not be that difficult for them.
Minor correction: Windows Store apps are written using WinRT, not WPF, and WinRT is language agnostic, and in fact is mostly written in C++. You can write C++ apps in WinRT for the Windows Store, so Microsoft has in fact written a C++ UI framework. Obviously, though, you want a desktop framework, and that is something they've not done since MFC or WTL.
I'm way confused. The title of this thread says "Can't do nested styles in Universal Apps?" Which is true, because that property doesn't exist in WinRT and therefore Universal Apps. But you link to WPF documentation and now claim it works, both of which seem to indicate you're programming in WPF?
The MSDN page you're referencing is for WPF. Universal apps are not WPF apps, they are WinRT apps (MSDN). So, this isn't a bug, but is instead just one of the many differences between WinRT and WPF (or Silverlight). As for triggers, those only exist in WPF. They don't exist in either WinRT or Silverlight. The VisualStateManager concept replaces triggers, and was even added to WPF. BTW, Style.Resources is NOT an attached property in WPF.
Most everything you'd style has a Resources property you could use instead.
<Style x:Name="foo" TargetType="Button"> <Setter Property="Resources"> <Setter.Value> <!-- Your resources go here. --> </Setter.Value> </Setter> </Style>
This isn't a perfect solution... if the element you're applying the style to has specified any resources they will entirely replace any resources you've attempted to add with this technique. The other option: most of the time when you have resources you want to define locally it's for use within a template, and you can put the resources on the root element in that template. The template can still be replaced, but if that's being done then chances are you won't be reusing any of those resources anyway.
If you show us what you're actually trying to do I can provide a full workaround/solution for you.