Alarm Clock Sample -- Part 1

The Calculator Demo I visited previously is far too complex for now so I've decided to try to understand the Alarm Clock Sample instead. It is a much simpler application though still written for WPF and as such is using XAML.

Upon downloading the source, I first built the project. This time, there were no problems. The build succeeded and I opened the app. Just as I suspected, it was very simple--just a picture of an old school alarm clock with animated hands, opacity set as to not be opaque, and draggable whilst showing the outline of an outrageously large rectangle. I was surprised, however, that it was taking 50% of my processing power which, on a dual core processor, means it's maxing out probably because of some infinite loop.

Ok, so now that I see what the program is all about, it's time to dive into the code. I went straight for myapp.xaml to find Startup. Thanks to the WPF Application Management Overview, I know now that this is used to define the handler for the Application.Startup Event which "Occurs when the Run method of the Application object is called."

I now understand the syntax of void AppStartup(object sender, StartupEventArgs e) in app.xaml.cs.

• void means this method will not return anything (basic knowledge from any strongly typed programming language)
• AppStartup defines the name of the method which will be called on activation of the Application.Startup Event.
• object sender is a reference to the object which raised the event
• StartupEventArgs e gives access to the properties of the event in question

Cool, but the Startup event "Occurs when the Run method of the Application object is called." Doesn't that mean the application needs a "Run method"? Usually the Run method gets put into the Main method but it doesn't exist in the Alarm Clock Sample just as it didn't exist in the Calculator Demo. No such luck finding Run either. The answer lies in the background. What we don't see in the application nor during the build process is that the entry point Main and the all-important Run get inserted automagically. I felt lucky searching for "wpf main()" and I was. Someone asked How can I provide my own Main() method in my WPF application? (I'll have to look further into that website sometime) and the answer was

At compile-time WPF generates the real entry point method using the classic static void Main() method signature in C#, or Public Shared Sub Main() in VB.NET. Inside the Main() method WPF creates an instance of one of your classes which derive from System.Windows.Application, and calls the blocking Run() method on this Application-derived class which keeps the process "alive".

Perfect. Now, I can figure out how the app is actually put together rather than how it can exist in the first place.