There it is. No time to write about it or make it pretty, but you forced me to publish it, CodePlex, so there it is….
There it is. No time to write about it or make it pretty, but you forced me to publish it, CodePlex, so there it is….
About ten years ago I started my first full time programming job. I was working on some business software written in C/C++. I say C/C++ instead of just C++ because it was written mostly in C with classes – with perhaps a few cases of inheritance or actually even only few classes – it used structs in many places to group some methods together the same way you would use classes today. The code was fairly complicated and it was just aging. The standard C libraries it used were not very rich, so if you wanted to code up something fairly straightforward – you had to dig through a lot of documentation looking for something basic only to end up implementing that list class yourself. We were using a Watcom compiler at that time and trying out Borland C++ Builder for some side projects showed it was a great improvement in that VCL provided a lot of great wrapper classes for Windows APIs making things easier. Two years later we were looking into rewriting our application or at least starting a new version and considering which tools to use – basically trying to choose between Borland C++ and C#. I was on the C++ side – it was a fairly known language, more predictable and providing intuitively higher performance, while C# was at version 1.1 and had lots of great libraries, but a bit foreign and why would anyone want to go away from the fun of using pointers, managing object lifetimes and relying on some garbage (collector)? Well, I lost – Microsoft seemed to be focusing on supporting C# and in the end it turned out to be a lot more productive than C++.
Fast forward 8 years and Microsoft says – in Windows 8 you can code using C#/VB, JavaScript or C++. Well, the word on the street is that it is so that programmers fluent in any of these languages will be able to code applications for Windows, so I guess I will stick with C#. Maybe I will look at HTML5, JS and CSS, since these seem to be getting most traction, I thought. Now, having found some limitations in the .NET/WinRT stack I have a feeling like the C++/DirectX route is the most attractive. The .NET stack might make you more productive than the JS or C++ – especially if you have been coding in C# for the last eight years and perhaps HTML5 has better graphics performance or some other interesting features, but it feels like learning C++/DirectX on top of C#/WinRT is what would allow me to cover most scenarios for writing Metro Style Apps™, so especially with some experience working on the test team for the DirectX wrappers in the Windows API Code Pack – I am hoping to have an easier start in diversifying my skills.
This is a reblog of my article from http://labs.vectorform.com
C# 5.0 comes with the new async/await keywords that make asynchronous code easier to write, read and maintain. This is very nice if you have properly declared methods that support this pattern and Windows Runtime (or WinRT – the API for Windows 8 Metro Style Apps) comes with a lot of these methods for long running tasks or ones of nondeterministic duration – especially in I/O or web calls. It is however completely lacking in support for asynchronous UI development, even though one of the main goals of these new keywords was support for responsive UI.
Interactive coding often introduces the need to start an operation, like an animation or a dialog box and then wait for an event before switching the state of the UI, for example: running another animation or removing a dialog. Reading this article you will learn how to do it better using the upcoming features of C# 5.0, regardless of whether you develop in WinRT, Silverlight, WPF, Windows Forms or even Web Forms. The source code that comes with this article contains a library you can use to cut the amount of code you need to write by half!
Yesterday I got one of those XamlParseExceptions that do not seem to make sense. It happened after I moved most of the code from my Windows Phone application to a class library. In fact the only things I left in the application project were the App class, the Properties folder and some resources that differentiate different applications that share the library. If you want to do something similar – you can have your MainPage class defined in a library and just need to update the WMAppManifest.xml to point at its new location, eg: NavigationPage=”MyClassLibrary;component/Pages/MainPage.xaml”.
Everything worked fine except for this bit:
<i:Interaction.Triggers> <ic:PropertyChangedTrigger Binding="{Binding PageNumber}"> <im:ControlStoryboardAction ControlStoryboardOption="Play"> <im:ControlStoryboardAction.Storyboard> <Storyboard> <DoubleAnimation ...
It kept throwing an exception:
I was looking at the controls available in WinRT () and I’ve stumbled upon this control called – CaptureElement. What it does is it “Represents a media capture from a capture device, for example recorded video content.” I thought I’d give it a go and see if I can display the output from the webcam on screen – which could be useful for AR (Augmented Reality) applications or even just for fun. This is how you do a preview then…
This is just a short post that I will likely update in the future. A where to start/how to ramp up sort of link list on WinRT development.
Main Reference Resources
News & Blogs
So I got my wife an HTC Titan for Christmas and I loved the way it vibrates compared to my Focus. It just feels nice with much lower frequency, while the vibrations on the Focus are a bit like an electric shock. This got me thinking that it would be nice to have the same sort of haptic feedback you get on the 3 hardware buttons on the regular Silverlight buttons. While you could just handle the touch events on every button you choose – it is a lot of code that just gets duplicated all over your app and it is hard to update it globally – e.g. if you want to allow the user to switch it off everywhere or automatically preconfigure it when the app first runs based on the device used. The best solution for it seems to be to create a Behavior that you can easily attach to any button, so that is what I had set off to create.
Occasionally I see people searching for how to move the GridSplitter with code behind…
This is not the right question. You can in theory move the GridSplitter itself with code – it is just a control that is hosted in a Grid (if used correctly), so by adjusting the Margins or ~Alignment properties – you can change its position, but what you really want is to resize the associated column/row – which will also incidentally move the GridSplitter.