Nadav and the wonders of the web

Thinking about how to run a program on the Smart Phone’s boot sequence got me searching and I did find the answer but it was not as easy and as clear to find as I hoped. That is the reason that i came to write this post.

The very simple and easy way to do this is to add a shortcut to the program we want to run under \Windows\StartUp

Yes its that simple.

There might be a different way to do this using the registry, but i couldn’t find one and quite frankly, I don’t see the need for it.

What you might want to do is add your created shortcut to the your installation CAB[I will try and have a different post regarding this one, it is a big subject.] under this folder so it will be done on installment and you won’t have to do it programmatically in a later phase. On the other hand, doing it programmatically leaves you the option to have this as a setting in your application that the user can set. I will leave the choice down to you. =]

Hope this was helpful!

Nadav

When we come to write unit tests we stumble upon many different problems with many different parts of our code, because no matter how hard you try, your code is never as simple as the examples around the web. If it’s singletons, static methods, private members that need mocking, or even events that need to be checked.

lately I spent some time writing unit tests and fumbled around with many of this problems. There are many articles around the web telling you the problem is not that you don’t know how to test this parts, it is that it shouldn’t exist in the first place. I really don’t like this answer, saying I shouldn’t write my code this way because there is a better one is a valid argument, but telling me I HAVE to change my code in order for it to work is usually not true. Some places don’t say this but still, most don’t give you a solution.

After this brief intro I will go into saying that I will try in a few different posts to clear up some of the problems in unit testing, mainly the ways to overcome them.

Lets start =]

As the title states, in this post I will show how to unit test events.

What we are going to do here is use an Anonymous delegate in order to catch the event inside our test.

The code: (look afterwards for the explanation and break down)

[TestFixture]
public class SettingsFixture
{
    [Test]
    public void ChangeSettingFiresSettingsChangedEvent()
    {
        // success variable
        bool success = false;

        // new setting
        string key = "SomeKey";
        string value = "SomeValue";

        // set a new instance
        SettingsManager settingsManager = new SettingsManager();

        // register to the event
        settingsManager.SettingsChanged += delegate(object sender,
          EventArgs e)
        {
            // event raise, test successfull
            success = true;
        };

        // update a setting to raise the event
        settingsManager.UpdateSetting(key,value);

        Assert.True(success);
    }
}

So what we have here?

We have a TestFixture with a single Test called:

ChangeSettingFiresSettingsChangedEvent

Change Setting Fires SettingsChanged Event.

First, we setup the success variable which we will commit later as the test’s result.

Second, set up our "new" setting, if we would use a special Type to submit to the UpdateSetting method, ISetting lets say, this will be the place to Mock(Mocking will be discussed in a future post, I will link to it then) it.

Third, setup a new instance of our SettingsManager.

Fourth, register to the SettingsChanged event as we usually will, with one big difference. instead of using a new instance of the right delegate we use an Anonymous delegate, look at the code for the syntax, it is very simple.

Fifth, call UpdateSetting with our "new" setting so the event will be raised.

Sixth, commit the result, hoping that it all went as planned ;].

Seventh, show off to your friends and go home, it’s late! (somewhere in the world…)

Hope it was clear enough.

A nice post about this:

Just to clarify: I am using C#(if you haven’t noticed yet) with NUnit.

See you next time =].

Nadav

Sometimes we want to be notified of different events that happen in the operating system, even when we are not “looking”. the State and Notification broker is built especially for this.

I will give an example of how to be notified when the current active application changes and how to handle it.

First create the correct SystemState member:

SystemState _activeProgram = new SystemState(SystemProperty.ActiveApplication);

Now set the event handler on your program initiation:

_activeProgram.Changed += new ChangeEventHandler(_activeProgram_Changed);

Now handle it ;]:

void _activeProgram_Changed(object sender, ChangeEventArgs args)
{
    MessageBox.Show(((string)args.NewValue));
}

You would want to know a few interesting things:

1. The NewValue string is formatted in this way:

   PreviousActiveProgramNameCurrentActiveProgramName

   So, you might want to use StartsWith\EndsWith methods in order to check them ;].

2. It seams that every UI involved action(MessageBox, Form, etc.) causes your own application to come back from the background(if it was there) and show itself ;]. while other non-UI related actions does not cause this. This only a major “feeling” i got from my little workings with this so far, i checked this with a Thread.Sleep that did not cause my application to come to the foreground.

Hope this helps.

Nadav