159 votes9 comments · Universal Windows Platform » XAML/Controls/Composition · Flag idea as inappropriate… · Admin →
Thanks for this feedback, this is an area that is being discussed on how we might improve the overall XAML verbosity syntax as well as make this easier for customers of ISV controls.
Also added this suggestion to the XAML Standard, please also comment over there as well: https://github.com/Microsoft/xaml-standard/issues/141Morten Nielsen shared this idea ·
27 votes1 comment · Universal Windows Platform » Dev Center + Microsoft Store · Flag idea as inappropriate… · Admin →
55 votes10 comments · Universal Windows Platform » XAML/Controls/Composition · Flag idea as inappropriate… · Admin →
Tim Heuer did a quick write up. Keeping it open until the documentation is on Docs.
This is seriously hindering us in creating a Controls SDK that has meaningful type-safe properties, yet are easy to assign in XAML.
I second that. Would be very useful - simulating real GPS today is impossible. Playing back a real-world NMEA recording much better simulates in-accuracies and movement behavior.
For what it's worth, I have a library here that I also use for mocking (it supports NMEA playback as well as 'real' Serial/BT input) :
The trick is to wrap the geolocation APIs in a custom class implementing a common interface, and then create a another one for use when running in debug, that wraps this NMEA file parser. Another nice side-effect of this design is that it allows your app to add support for serial and bluetooth GPS devices.
182 voteson the backlog · 1 comment · Universal Windows Platform » Dev Center + Microsoft Store · Flag idea as inappropriate… · Admin →
Per the wonderful Mr. Torr: This should be supported now — if you use StoreRequestHelper.SendRequestAsync and pass 6 and an empty string as the parameters, you should get back a response. (Not documented yet…):
Will close this out once docs are out
I would be worried this would be misused to force people to rate the app, just so they can continue to use it.
Perhaps stating the obvious here, but you should always test performance and render critical things on real hardware. No emulation of the speed will be true to running on real hardware. To be honest I prefer having a fast emulator to speed dev time.
One nice thing about UWP apps is that you can run the same app package on the desktop, removing the need for an emulator. Really the only big difference is the screen size, but you could set your window size to match that of a phone, and ensure it looks ok. The only time this wouldn't work is if you need phone specific things like doing phone calls etc, but you can't do that on the emulator either.
This was actually supported in the early previews of WinRT 8.0, but was removed in final. We ended up building a .NET library rather than a Windows Runtime Component library, simply because this limitation forces a very ugly sdk to work against.
24 votes4 comments · Universal Windows Platform » XAML/Controls/Composition · Flag idea as inappropriate… · Admin →
I don't understand how this would work? A list doesn't have a top, so where would you be tapping? The top of the list is the first visible element - I usually want my users to get more details on that element when they tap it, rather than scrolling back to the top. If your list has a header title on top, just add a Tap event listener to it and call the scroll to top method.
23 votes4 comments · Universal Windows Platform » XAML/Controls/Composition · Flag idea as inappropriate… · Admin →
You can subclass observable collection, perform the sort against the protected 'Items' property and raise the 'Reset' even when done. Honestly wouldn't be much code.
Having said that, a default 'Move' would be useful (but again can be done using subclassing)
710 votes44 comments · Universal Windows Platform » Dev Center + Microsoft Store · Flag idea as inappropriate… · Admin →
Thanks for the suggestion; I’m marking this as under review for implementation in a future release of the Store.
Terrible terrible idea. This is what we have in-app purchases for. Make your app free-free, and use in-app purchases to remove the ads (this seem to be the main usecase people here blabber on about)
There still needs to be a destinction between "Reduced functionality" and "Trial app". Ie fully functional app with ads that gets removed with purchase is a free app in my mind, but a trial app that only allows you to play for instance the first level of a game is a pure trial app and shouldn't be listed as free.
D3DImage is a pain to work with, and doesn't work very well. I've found that SurfaceImageSource resolves all those issues, but I wish it was available in WPF as well.