The first thing I did after downloading BabySmash was to begin building an on-screen keyboard. I installed Microsoft Expressions, but quickly became frustrated. That was a surprise to me because I am a Photoshop pro!! (On portraits anyway). Despite the admonishing of many, I switched over to Visual Studio and began coding my keyboard by hand. Now I was on much more familiar territory! I do plan to return someday to Expressions when I have a more open mind. But for now, I want to build DrewbieSmash!
The following are my requirements for my keyboard:
1. Appears in the bottom right corner of the BabySmash main window when BabySmash is in "drewbie mode".
2. Is resizable.
3. Sends a key-click event to the main window when a key is clicked on. I wanted to reuse as much code as possible, and hook the on-screen keyboard right into where the real keyboard is hooked in.
I tried many things... first I made my keyboard a <Window />. Mainly because the sample xaml files I was working with were all <window /> s, and I was just trying to do some cut-and-paste development to get my feet wet with WPF. Getting my window to render inside the main window as I wanted it to appear was problematic - probably because I didn't know what I was doing. And probably because putting a window inside another window is probably a dumb idea.
Then there was this challenge... BabySmash is architected so that all logic is executed by a controller class. The controller class requires a FrameworkElement argument and uses this for where it performs the animation. The original BabySmash main window was both the input and the action window, so it just used "this". Since my events were coming from the KeyBoard window, I had to get a reference to the Main window before I could execute the animations in the MainWindow via the controller class. Furthermore, it was apparent to me that BabySmash was really architected around having a single main window, and by continuing down this path I would likely run into additional challenges when trying to work with a second window.
So I took a step back and realized that in a .NET application, I would make the keyboard a <usercontrol />, and give it a "KeyClicked" event.
Since the keyboard object doesn't know anything about the size and real-estate concerns of the containing object, the keyboard was coded to size itself relative to the parent window. There were no pixel values coded into the Keyboard xaml. So originally I thought that the Keyboard size could be entirely controlled by the parent window. However, I soon realized that I have to change the font size as the key board is resized. So I added a "size" property to the KeyBoard control. I didn't want to use explicit pixel values because we still don't know what is going on with the parent. So I made the KeyBoard accept 4 sizes: Large, Medium, Small, Standard. (Standard being the smallest and the size of the on-screen keyboard that ships with the Windows OS. If someone has a better name for that one, please let me know!!!!)
Now, even though I don't know what the actual size of the KeyBoard will be, I can make a guess as to the size the font should be. And this works very well.
Here is a screen shot of my Amazing BabySmash keyboard. You can see by the name of the control that this is my third attempt at creating a keyboard. The next blog post will be about how I coded the KeyClicked event and how I modified the BabySmash application to use it.
