A blog about one man's journey through code… and some pictures of the Peak District

Monthly Archives: October 2013

I recently wrote a little application in WPF, which displayed a button. I thought it would be nice to have the button “burst” onto the screen, which is unlike me… normally the screen looks like it looks, or it looks like a command prompt (apparently not everything can be a console app).

When looking around on the web, I found very little information about this. What I did find was a mixture of code that didn’t work, wasn’t explained, or both. As you may have gathered from the previous paragraph; I’m no expert in this, but I’m going to try and collate my findings into a series of posts.

Button Animation using WPF with no code-behind

So here’s the code for creating a button in WPF (you might want to sit down, as the technical brilliance of this XAML may make you dizzy):

I know, and still no call from Microsoft to go there as a consultant! Anyway, believe it or not, there’s more. I want to make the button expand as it’s loaded; so an event trigger allows me to do this quite easily (this is inside the button definition):

<Button.Triggers>
<EventTrigger RoutedEvent ="Button.Loaded">

So, anything in this event should fire when the button is loaded. What I want to fire is an animation. In WPF terms, this is a storyboard; basically, that’s just a collection of animations. The storyboard definition is inside the trigger:

So what have I told it there? I’ve told it that I want to animate a double value (i.e. a floating point number) – DoubleAnimation; I’ve told it that I want to change a property within something called “MyAnimatedScaleTranform” (more on this in a minute); and that the property is called “ScaleTransform.ScaleX” (“ScaleTransform.ScaleY” for the second one). I’ve then told it what to change that property from and to, and how long to take.

Okay, so we now have a button, a storyboard and an animation that tells it what to do; but that’s not all – remember MyAnimatedScaleTranform from the last paragraph? The problem is that WPF doesn’t know what ScaleTransform is, and so inside the button definition we need to define that. Here’s the full code for the button:

The CentreX and CentreY properties tell it where to grow from (i.e. where the origin is). These values are relative, so you can place this button anywhere on a form and it will still grow from the middle.

So, that should do it… well, it should give you a button that grows into existence; try it. I wanted mine to “pop”, though. So I decided I needed it top grow a bit to big, and then correct itself. To make the button grow too big is easy-peasy:

From ="0" To ="1.2"

Now it grows too big. So it needs to get smaller; that’s “drink me” isn’t it:

Add those after the existing two `DoubleAnimation` elements and run again. At first glance, it would appear that they will execute in sequence; but of course if they did, you would have seen the X co-ordinate expand before the Y. What, in fact, happens, is the last animation wins and it just contracts.

With no small help from a well known site that allows programmers to ask questions of other programmers, with the intention of writing a blog post and passing the knowledge off as their own, I found this little trick. There is a `BeginTime` property of DoubleAnimation:

Now try it – good eh? You can play with the “pop”, make it grow bigger, or smaller. There’s even a repeat property.

Conclusion

I intend this to be the first in a few posts on animation. Next, I intend to write about how you would do the same thing using code; and later, I’ll look at how this all works in WinRT (I’ll give you a clue – it’s not the same!).

If, like me, you aren’t getting very many reviews for your Windows Store Apps, you might want to give people a nudge. Be careful with this approach, as there’s nothing more irritating than a constantly nagging textbox whining about reviewing an app. Don’t be surprised (or blame me) if you get a review saying: Stop nagging about reviews. But done correctly (in-frequently) you might just persuade a few extra people to review your app.

The process is relatively straightforward; you first need to store two additional roaming setting; mine look like this:

I’m not sure these need any explanation (but I’ll provide one): one to determine whether the product has ever been reviewed and one to say when.

Next, and it’s entirely your choice when but, you need to prompt the user. Having said that, at the start or end of using the app seems a sensible choice; whereas suspending the app mid way and interrupting the user, does not. I do this on load at the same time as reading the other roaming settings:

The MessageBoxHelper class is the subject of another post, which can be found here.

Obviously this does have its own problems; not the least of which is that it’s pretty difficult to unit test because it uses roamingSettings directly. At some point in the future, I may supplement this with a post on the abstraction of this, but if I don’t, then you definitely should (abstract it that is, not write a blog post – although if you do the latter then send me a link and I’ll amend this post to include it!).

Other problems with it are that the 5 day interval is hard coded and it doesn’t account for the user migrating across a time zone (or even changes their culture) with their profile. So, if any of this matters then be sure not to copy and paste the code verbatim!

Conclusion

You might find this approach to be counter productive. People tend not to want to give reviews, because it means spending time doing something that has nothing to do with the functionality of your app or game. If you’re feeling brave (and I have no idea if this is compliant with the Windows Store Police) you could have certain features that are enabled only after the user agrees to review your app. You could implement that by simply checking the roaming setting:

roamingSettings.Values[ "ReviewedProduct"]

With something like a game, you could give extra credits, or if your app uses any paid features then you could offer to provide them for a limited time period or something.

I imagine this will force people to either review your app or just uninstall it!

Also, keep in mind that once the user agrees to review your app, there’s no way to tell if they’ve actually done so using this approach; nor is there any way to detect they’ve done so via another method.

Believe it or not, the MessageBox.Show() function is unavailable for WinRT. Admittedly, you probably shouldn’t be using it too much. But when you do, it’s unavailable (so you can’t). The workaround is to build up a MessageDialog. Have a go – for a yes / no box, you’re looking at maybe 10 lines of code.

I found an article on the web about creating a helper class; modified it a little, and then felt obliged to re-post.

(Here’s the original article: http://www.reflectionit.nl/Blog/2012/messagebox-show-in-winrt)

What you’ll see if you read that is that he produces a very nice helper class; but what if you want cancel to be called something else (which I did)? Well, here’s my attempt:

I recently started using the MVVM Light framework to create an app. One of the first things that I found tripped me up was trying to link the ViewModel functionality with the visual interface. After a little more searching than should be necessary I came across the concept of commands. Basically, thos allows you to bind the functionality of your view model to an action on the screen. In the example below it’s the action of clicking a button.

First, create a new relay command (this is in the namespace GalaSoft.MvvmLight.Command):

You can also pass parameters, by simply providing the CommandParameter attribute and then using it. However, given that you’re already in the databound context (i.e. you’re function is in your ViewModel, which is bound to the DataContext) I didn’t find a need for this, as it’s possible to simply reference the property directly.

Conclusion

This ends up being quite a neat way to link the two. The screen is linked to the view model without having a chunk of code in the button click handler.

I recently completed by second game in Windows 8 (the first using the MonoGame framework). Given the MonoGame architecture, displaying a settings screen seemed a little more complicated than it should have been; obviously displaying this using native Windows controls will mean that I have some re-work should I ever try to port to Android.

This first thing with WIndows is always to hook up the Windows settings charm (don’t confuse this with your own settings page):

If you’re just copying this verbatum and now compile that, you’ll discover that you need Pages.SettingsPage. That’s basically a XAML page that actually displays the settings. Mine looks something like this:

That should be it. Inside the settings page itself, my suggestion would be that you use a instance of a class defined in App.Xaml.cs, and then use that elsewhere in your app / game to reference the setting. This means that you’re not constantly passing indiviual settings around.

Conclusion

As I said at the start, although this does work, if you’re using a cross platform framework for your game or app then this might not be the best approach; however, you do need to have your settings here if you intend to get into the Windows Store.