The Visual Basic Team : Smart Devices

There’s No Such Thing As Too Much Euchre! (Matt Gertz)

VBTeam — Fri, 18 Dec 2009 14:26:00 GMT

“Oh, no!” I hear you cry, “not another blog about Euchre!”

Well, I do like the game, to be sure. But, more importantly, the Euchre scenario enables me to try out any new technologies on a reasonably complex problem (using Visual Basic, of course). It’s my way of checking out our product to make sure that it works before we ship it out to you guys.

For my app building this time around, I chose to focus my energies in two areas – WPF, and Windows Mobile. Porting my Euchre game to these platforms was challenging in several different ways, and I thought that I’d share what I’d learned with you. I won’t list out the code, most of which hasn’t changed, but you can find it at my Temple of VB site.

Porting VBEuchre to Windows Mobile

I actually hadn’t intended to do this one, actually. I mean, I’d always meant to do such a port so that I could play Euchre on my phone, but I’d kept putting it off since there were always other important things to do. Yesterday, however, I found myself sick at home and utterly bored, so I decided to tackle the port. It turned out to be easy (for the most part) – the hardest part is actually redoing the resources. But I’m getting ahead of myself…

I started out by creating a Windows Mobile application, and then adding the resources to the default form. The process of adding controls was nearly identical to creating the original game. The only differences were:

· I used PictureBoxes instead of Labels for the cards, since Labels don’t have images in the compact framework (I should have been using PictureBoxes in the original game, anyway).

· I didn’t bother with a Logo splash, the fancy graphical scoring, nor with the player names – real estate is at a premium on a smartphone.

· GroupBoxes don’t exist, so I use labels to indicate who the dealer is.

· I added a new button to launch the game, for reasons I’ll explain later.

· There are only two menu items in the strip (Restart Game and Exit).

· There is no tooltip control.

· The status area is now a label, and only shows the most recent action.

It took me about 30 minutes to set up the form. The two bid user controls were next, and were essentially identical to their desktop counterparts (though the text in them is abbreviated). I didn’t bother with a “Rules” dialog nor an “About” dialog, so that just left the options dialog. Speech isn’t easily available on a hand-held, and the player personality choices take up too much space as well, so that just left the rule variations to add into it (Stick the Dealer, SuperEuchre, Quiet Dealer, and Nine of Hearts) and the effects (Peek At Cards and Sound Effects).

I then copied the old code and resources over wholesale, and worked my way through the errors. There were darned few of them, actually. Here’s what I ran across:

· “My” support is limited in mobile applications. For some things (like My.Application.DoEvents), simply taking off the “My” is sufficient. For other things, such as playing sounds, I had to use the System.Media.SoundPlayer object directly.

· The Timer control uses “Enabled = True/False” instead of “Start/Stop”

· I ripped out or short-circuited all code relevant to tooltips, the F2 button, default buttons, and text-to-speech, since they have no meaning in this world.

· Images have no rotation methods, so I created some by hand so that cards would be oriented correctly.

· I shortened a lot of the text messages to fit into the available display space.

That was pretty much it – or so I thought. When I ran the game, everything seemed to work fine. However, “New Game” would only work once, and clicking on it again would do nothing. This is because (as I found out) events in the .NET Compact Framework do not support asynchronous events, and my game (as it existed) relied upon that functionality in order to process the “New Game” command in the middle of a game. Thus, I now use a button to start the initial game, and then “New Game” (now renamed “Restart Game”) simply sets a flag that the event loop catches to crawl back up the stack and restart, as before.

Side note: Reentrancy (essentially recursing into event or messagehandling) is dangerous, because you can easily get into a deadlock if you mess it up. DoEvents() is therefore a controversial method to use because it’s so easy to get it wrong, and many people even feel that it should be entirely ripped out of the framework. In my case, the requirement to drive the game and still allow the user to exit it makes it sort of a necessity (unless I were to implement some fairly significant threading and message handling, and that wasn’t the point of my exercise). I worked hard to make sure that I ran into no reentrancy problems when I developed the original program, but you should be very careful whenever you use it.

My total elapsed time at this point, from the start of the project, was about one hour – not bad! I still wasn’t quite done, however. My card images, although beautiful on the desktop version, looked pretty crummy when scaled down to 31 x 24 boxes, and furthermore they were wasting memory and causing time delays due to the scaling and orientation required on each showing. I had to re-write all of my cards into the proper sizes, making them much simple looking in the process so that they were legible.

After a couple of hours of tweaking those images and adding the setup project to generate the CAB, I was almost done. One final gameplay experience encouraged me to decrease the timer interval to 100ms – that seemed to pace the game better on the phone. The final result (developed using VS2008) is available on the Temple of VB site.

Porting Euchre to WPF

As easy as porting the game to Windows Mobile was, porting it to WPF was another thing entirely. WPF and WinForms are really meant for different scenarios, and therefore they require different types of coding skills. (I actually did the WPF port before the Windows Mobile port, but since the WPF one was more complicated, I saved it for last in this blog.)

I used VS2010 Beta 2 for this port, since I was interested to see if I could find any bugs in the product. I’m happy to say that I didn’t run into any major bugs – what I did run into was a lack of knowledge on my part, and so it took me quite a bit longer (a couple of weeks, in fact) to do this port.

As in the case of the Windows Mobile port, I first started by recreating the forms in a WPF Windows Application. The WPF designer is pretty easy to use (even when dropping in 53 controls!), though I ran into a few necessary changes from what I’d done in WinForms:

· I had to be careful to position cards over the group boxes rather than in them. This is because group boxes will, when invisible, hide anything inside them. (I had to go into the XAML to do this change, because my cards kept snapping into the group box.)

· The cards became Images (the moral equivalent of a WinForms PictureBox) instead of Labels, which they really have ought to have been originally anyway. Labels in WPF don’t support background images, so this change was required. (I started out using Labels in this WPF version, and then when I realized that that wouldn’t work, I shifted them to PictureBoxes simply by replacing the class info in XAML – very cool!)

· Controls in WPF have a Z-order, but you can’t change it programmatically. Therefore, it’s important to lay down the controls in the correct order, and to make sure that you make liberal use of “IsHitTestVisible = False (or True)” to avoid inadvertently covering up a control which is supposed to be active and clickable.

· Because of the Z-order issue, it’s easier to work with user controls by simply laying them down rather than creating them dynamically. However, your user controls won’t appear in your toolbox until you’ve built them once. Additionally, accessing them programmatically requires prefixing them with a namespace, something you should keep in mind.

· The tooltip control doesn’t exist and isn’t required – each control has a tooltip, which actually makes things a lot easier.

· Controls don’t have a cursor setting, so I had to set this by hand whenever state changed.

· Timer controls don’t exist, but this is not a big deal, since you can just use the System.Timers.Timer object in the code, which works essentially identically.

· Image controls do not natively support images accessed by My.Resources – they instead prefer files (URIs, actually). To dynamically set these on-the-fly, I had to stream the bitmaps into an in-memory file, and then assign them to the image. I had to do something similar for the RichText edit control on the “rules” page.

· Menus were trickier to set up, since you can’t auto-populate them with standard items. Once you get the hang of it, they essentially work like those in WinForms.

· Font sizes in WPF refer to pixels and not points, which means you’ll likely see a font appear about 30% smaller than you expected if you’re used to WinForms – just something to be aware of. (My code doesn’t correct for this yet, incidentally, so the fonts will appear a bit smaller.)

· The windowing controls (minimize, maximize, etc) are not set individually – to have only a minimize and a close box, the window needs to have ResizeMode set to “CanMinimize,” for example.

· Other controls work as you’d expect, except that radio buttons and checkboxes have both a Checked and Unchecked event, unlike WinForms where both are handled in one event.

The game logic was, of course, identical to the WinForms version, except where I had to retool cursors, timers, and tooltips. Nevertheless, there were a few changes that had to be made to managing the controls and dialogs:

· Instead of using the speech SDK, I took advantage of the built-in speech APIs in the framework. This resulted in much more elegant code, and a smaller package as well.

· There is no equivalent to “DoEvents” in WPF. As I was unwilling to totally rewrite the project to use worker threads and coordination messages, I leveraged a trick using DispatcherFrames that I’d found on the Internet (this is attributed properly in the code sample).

· Modal dialogs cannot be reused, and since I needed to reuse the options dialog and wanted to persist state between uses, I hooked the “closing” event to cancel the Close and instead just hide the window – this necessitated a minor tweak to my “new game” logic as well to check for the state of the options dialog.

· Disabled visible controls do not grey out, which gave me the opportunity to play around with the opacity property, which was kind of fun.

· There were numerous little changes that had to be made due to slight variations in naming conventions – e.g., Enable vs. IsEnabled – and I had to make sure that the IsHitTestVisible property was used correctly as well wherever the visibility of a control changed, due to the aforementioned Z-order limitation.

· Unlike the WinForms “Visible” property, the WPF “Visibility” is not a Boolean but instead supports an enum. Furthermore, the “Visible” part of that enum maps to 0, and the “Hidden” to 1, so if you accidentally use Booleans as argument to Visibility, you’ll get things backwards. For code readability, I threw in some If() calls to disambiguate the situation.

That work got me to parity with the WinForms version, and it works great! I’m not quite finished with the port, though, and so you won’t find an installer package for this one from me yet – now that I’ve got things working, I want to add some of the WPF special effects to the game! However, I’ve posted the code on the Temple of VB site, and the solution also includes the old code so that you can more easily compare the two.

‘Til next time,

--Matt--*

M. G. Phone Home (Matt Gertz)

VBTeam — Wed, 10 Dec 2008 00:26:00 GMT

M. G. Phone Home (Matt Gertz)

I have a slight problem with my cell phone. It’s a smartphone; I love it, I use it all the time, and I don’t what I’d do without it, but I’ve been pretty aggravated with its support of Bluetooth. It will fail to pair with the Sync system in the car at random times, which drives me crazy as I’ll only notice the problem when I’m on the highway or something. Here in Washington State, it is (thankfully) illegal to drive and operate a hands-on cell phone at the same time, and so one of the whole points of getting a car with Sync was to be able to easily phone my wife simply by voice command and say “No, I’m still on the on-ramp for I-405N – well, I think I’ve moved 50 meters since I called you last.”

Toggling the Bluetooth on/off fixes the problem, so it seems to be an issue with the device itself. Unfortunately, toggling Bluetooth is not a good solution while driving, since to do that in Windows Mobile 6.1, I have to get out my stylus, click on a little icon, go to the second tab in the resulting dialog, click a check box to turn it off, dismiss the dialog, and then repeat the process a second later to turn it on. And that’s if I don’t have to unlock the phone first with my PIN!

So, for a while, I’ve been meaning to create a simple application that would toggle the setting for me, since I don’t really want to upgrade my phone at the moment. The idea would be to put the application on my Start menu on the phone so I could easily trigger the whole sequence of events. I finally got enough free time to look into this late last week, and while searching around on the Web for some pointers into how to code against the Bluetooth stack, I came across a neat little Microsoft library which wraps up common Bluetooth functionality – the Windows Embedded Source Tools. Some of you probably already know about it (it’s been out for over three years, which means there’s probably lots of other blog posts out there on this, but blithely pressing on…), but for those who haven’t heard about it, it’s great for trying out Bluetooth programming on a Windows Mobile 5 device or later.

First, you need to download the tools. You can get them from this link. After you’ve installed them, you can use them immediately – you don’t need to reboot Visual Studio or anything like that.

In Visual Studio, create a new project via “File->New Project” (or “File->Add New Project” if you prefer), and under the Visual Basic node in the resulting window, select “Smart Device Project” and give it a name (in my case, I chose “ResetBluetooth”). Click “OK,” and you’ll be taken to a dialog where you get to choose the type of SD project you want to create. This application won’t need any UI, so just choose “Console Application” and click OK.

Once the editor has been set up and the solution explorer populated with the application, you’ll need to add a reference to the source tools you just downloaded. Right-click on the project and choose “Add Reference.” Switch to the “Browse” tab, and then navigate to “C:\Program Files\Windows Embedded Source Tools\Microsoft.WindowsMobile.SharedSource.Bluetooth.dll” – press OK to add the reference. (It actually took me a few tries to figure out this step, since I was trying to add services from the .NET tab – there *are* Bluetooth libraries there, just not the one I needed.)

Now, back in the editor, let’s make it cleaner to access the calls by adding the following line at the top of the file:

Imports Microsoft.WindowsMobile.SharedSource.Bluetooth

The rest of the code is pretty straightforward:

Module Module1

Sub Main()

Dim radio As New BluetoothRadio

If radio.BluetoothRadioMode = BluetoothRadioMode.On Then

radio.BluetoothRadioMode = BluetoothRadioMode.Off

End If

radio.BluetoothRadioMode = BluetoothRadioMode.On

End Sub

End Module

That almost doesn’t need any comments, but just for forms’ sake – by allocating a BluetoothRadio object, I’m connecting to my phone’s Bluetooth service. I’ll check to see if Bluetooth is on – if it is, I’ll turn it off. Then, regardless of whether it was on or off to begin with, I’ll turn it on. (This covers the case where my phone turns off Bluetooth for no good reason, which also happens sometimes.)

At this point, you could press F5 and test it against the emulator. Unfortunately, the emulator doesn’t support Bluetooth, alas (“No Bluetooth hardware is installed on this device” is listed in its system settings), and so all you can do is verify that it doesn’t crash. To really test it, you’ll need to deploy it to your bluetooth-supporting Windows Mobile phone when you F5 – a choice to do this will be offered to you. (Ironically, I haven’t really had a opportunity to test it “in crisis” – my phone is in one of those rare states where it behaves correctly, for a week or so… J)

According the Intellisense for the BluetoothRadio object, you can also enumerate the devices connected to Bluetooth, which is pretty handy, and then presumably interact with them directly. I may try some of those out later, as I’ve been trying to debug why my GPS receiver isn’t connecting to my phone…

‘Til next time,

--Matt--*

Visual Basic & Smart Devices (Matt Gertz)

VBTeam — Mon, 14 May 2007 21:46:00 GMT

Last week I talked a bit about operator overloading, and used the concept to support a library of matrix functions. This week, we’ll use those functions in a Smart Device application to create a matrix calculator.

Smart Device applications

It’s extremely easy to create an application for your Smart Device. Let’s start from the solution we created last week. Assuming that solution is loaded, choose “File,” “Add,” “New Project…” and then in the resulting dialog, expand the “Smart Device” node under the Visual Basic node. You’ll find 3 child nodes – one for Pocket PC 2003, one for Smartphone 2003, and one for Windows CE 5.0. For the work I’ll be doing today, the choice actually matters little, and mostly just affects the default size of the window and the colors in the form – I’ll be sticking to basic controls and so everything I’ll be doing will be common to all of the SD platforms. (Note that this is not always the case – there are device-specific differences.) I arbitrarily chose “Windows CE 5.0” and then selected “Device Application,” giving the application the name “MatrixMath.”

After you press “OK,” you’ll get a form designer, just like with a normal Windows application. By default, the form is sized for a WebPad, so the first thing I do is change the size to 240 x 320, which will work nicely for most devices on the market (except, alas, for my new Treo, which has a square 240 x 240 screen – but it should at least scroll automatically on that). The only reason I'm changing the size is to give me an idea as to how the layout will look on that size screen, which is the most common size -- as Daniel Moth reminded me, generally speaking "full screen" will always be an appropriate setting. I change the title bar text to be “MatrixMath” and set Menu to “none” – we won’t be doing menus today, but if you decide to design menus, it’s essentially the same as designing menus in Windows applications, which I touched on briefly in my earlier series on Euchre.

Now, I’ll create a layout for my form. I’ve decided to go with a 4x4 matrix, since that’s the most useful one when doing robotics (and for smaller square matrices, you can still make the various functions work as they normally would – just set the elements in the extra columns and rows to 0 except for the diagonals, which should be set to 1). I’ll add the appropriate number of text boxes to the form to account for the elements, and give them the names “M00,” “M01,” etc. I’ll also add a label & text box (set to read-only in the properties) to display the determinant – in my calculator, this value will be updated automatically when the matrix changes. Finally, I’ll add buttons for the following: Inverse, Transpose, Scale, +, -, *, =, CE (clear entry), and AC accumulator clear). The resulting form is shown in “MatrixMath-form.jpg” attached in the ZIP file.

Now, I have to start hooking up the various events. First, though, I’ll need to reference the class library we created last week. However, SD applications can’t use “normal” class libraries (which target the .NET 2.0 framework), so once again I choose “Add New Project,” navigate to the Windows CE 5.0 node, and select “Class Library,” giving it an appropriate name. I copy and paste my class into that new class library (replacing the default class that got auto-generated). Note that I could have avoided this problem if I had created the class library as a smart device class library last week -- .NET projects can reference SD projects, but not vice-versa! (Thanks again to Daniel for reminding me that I hadn't made this clear when I'd first posted this.) I do need to build the class library (right-click the class library project in the Solution Explorer and choose “Build”), and then add the reference to MatrixMath in the usual way (right-click MatrixMath in the Solution Explorer, choose “Add Reference…”, navigate to the Projects tab and select the new class library).

I also choose the “Set as Startup Project” command on Matrix Math in order to make sure we can debug it correctly later on.

Now, we start leveraging the class library code. Right-click the form in the Solution Explorer and choose “View Code.” In the resulting editor, I’ll add “Imports Matrices” at the top, so that I don’t have to fully qualify my usage of the Matrix class. I’ll also add the following class members:

Enum operations

opNull = 0

opAdd = 1

opSub = 2

opMul = 3

End Enum

Dim lastOp As operations = operations.opNull

Dim Accumulator As New Matrix(4, 4)

Dim ScratchPad As New Matrix(4, 4)

Dim map(3, 3) As TextBox

The TextBox array held in “map” will just make it easier for me to map textboxes to coordinates, and I will initialize it in the Load event handler.

Private Sub MatrixForm_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

' Yecch...

map(0, 0) = M00

map(0, 1) = M01

' Etc...

The Accumulator will hold the current value of the matrix, the ScratchPad will hold the matrix that the user is currently defining, and the “operations” enum will help me define & remember what the previous operation was, so that when “=” is pressed, I can apply it. (This calculator is a simple accumulator calculator, with no implemented stack to nest operations – i.e., there is no operator precedence. I’ve left that as an exercise for the reader… J)

Now, we’ll need methods to clear a matrix and also to push a matrix into the edit boxes. These are just business as usual:

Private Sub PushMatrix(ByVal m As Matrix)

For i As Integer = 0 To 3

For j As Integer = 0 To 3

map(i, j).Text = m.data(i, j)

End Sub

Private Sub ClearMatrix(ByVal m As Matrix)

For i As Integer = 0 To 3

For j As Integer = 0 To 3

m.data(i, j) = 0.0

End Sub

Everything else is just event handling. First, we need to handle the event where the data in the scratchpad is changed by the user, so that (a) we can update our internal representation of that matrix and (b) update the determinant. When I first coded this, I decided that I would handle the TextChanged event, but that was a poor decision because it would fire on every keystroke – very non-performant, and also ambiguous if you’d just entered a “-“ or “.” or other partial number. So, instead I went with “LostFocus,” which would fire when the user clicked away from the cell (and before any subsequent event would fire. The code is similar for all of the edit boxes, and I’ve consolidated them into one handler to save space, although again we have the problem with mapping a control to an array (this time in the opposite direction):

Private Sub Matrix_LostFocus(ByVal sender As System.Object, ByVal e As System.EventArgs) _

Handles M00.LostFocus, M01.LostFocus, M02.LostFocus, M02.LostFocus, _

M10.LostFocus, M11.LostFocus, M12.LostFocus, M13.LostFocus, _

M20.LostFocus, M21.LostFocus, M22.LostFocus, M23.LostFocus, _

M30.LostFocus, M31.LostFocus, M32.LostFocus, M33.LostFocus

Dim value As Double = 0

Try

value = CDbl(CType(sender, TextBox).Text)

Catch ex As Exception

' If junk got put in the text box, compensate

value = 0

CType(sender, TextBox).Text = value

End Try

If sender Is M00 Then

ScratchPad.data(0, 0) = value

ElseIf sender Is M01 Then

ScratchPad.data(0, 1) = value

' Etc…

End If

Dim det As Double = ScratchPad.Determinant

Me.DeterminantBox.Text = CStr(det)

End Sub

Now, I’ve decided that there are three special functions that operate on the scratchpad matrix in place, but don’t modify the accumulator – Inverse, Transpose, and Scale. (These are similar in nature to the Sine, Inverse, etc. functions that you’d find on any calculator, which just operate on the most recent thing you typed in.) With our previously defined functions, the first two are very simple. For example, here’s the Inverse handler:

Private Sub InvertBtn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles InvertBtn.Click

ScratchPad = ScratchPad.Inverse()

PushMatrix(ScratchPad)

End Sub

The Scale function is slightly more complicated because we need a value to scale the scratchpad, and the screen is too cramped to add much more functionality. Instead, I’m going to use a modal dialog. These work identically to their Windows application counterparts. To create on, right-click on the MatrixMath project in the Solution Explorer and choose “Add” then “Windows Form,” giving it an appropriate name like “Scalar” before pressing OK. In the resulting window, I’ll resize the form to be 200 x 100, and add a label, text box, and “OK” button as shown in Scalar-form.jpg in the attached ZIP file. (Don’t forget to set the return Dialog Result property of the OK button to be “OK,” as shown in that same JPG.) I will also get rid of the default menu, as with the other form. There’s only one event handler in the dialog, which is for the OK button click – it just calls the following:

Public Class ScalarDlg

Private Sub OKBtn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles OKBtn.Click

Me.Close()

End Sub

End Class

And using the dialog is just as simple:

Private Sub ScaleBtn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ScaleBtn.Click

Static scalar As Double = 1.0

Dim dlg As New ScalarDlg

dlg.scalarEdt.Text = scalar.ToString

If dlg.ShowDialog() = Windows.Forms.DialogResult.OK Then

Try

scalar = CDbl(dlg.scalarEdt.Text)

Catch ex As Exception

scalar = 1.0 ' User put in junk; ignore and scale by 1

End Try

If scalar <> 1.0 Then ' No point if wasting time if nothing will change

ScratchPad = scalar * ScratchPad

PushMatrix(ScratchPad)

End If

End Sub

Note that I’ve chosen to make “scalar” a static, so that the last choice will be the default the next time the matrix is scaled.

Next are the operations that do affect the accumulator. The general “infix” plan for those is:

1) The user types in a scratchpad matrix and then presses +, -, or *.

2) The scratchpad gets pushed to the accumulator and the last operation type is cached.

a. Note that, like a normal calculator, the scratchpad doesn’t get cleared after being pushed, so that it is essentially the default value for the next operation.

3) The user modifies the scratchpad as normal and then presses +, -, *, or =. The accumulator and the scratch pad are acted upon by the previously cached operation request, the result is placed in the accumulator and presented on the scratchpad, and the new operation request is cached. (In the case of “=”, the last operation is Null, the operation of which will be essentially a “no-op.”

The code then is just:

Private Sub OpBtn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _

Handles AddBtn.Click, SubtractBtn.Click, MultBtn.Click, EqualBtn.Click

Select Case lastOp

Case operations.opAdd

Accumulator = Accumulator + ScratchPad

ScratchPad.Copy(Accumulator)

PushMatrix(ScratchPad)

Case operations.opMul

Accumulator = Accumulator * ScratchPad

ScratchPad.Copy(Accumulator)

PushMatrix(ScratchPad)

Case operations.opSub

Accumulator = Accumulator - ScratchPad

ScratchPad.Copy(Accumulator)

PushMatrix(ScratchPad)

Case operations.opNull

' We haven't done any ops yet, so just push it into the accumulator.

Accumulator.Copy(ScratchPad)

End Select

If sender Is AddBtn Then

lastOp = operations.opAdd

ElseIf sender Is SubtractBtn Then

lastOp = operations.opSub

ElseIf sender Is MultBtn Then

lastOp = operations.opMul

ElseIf sender Is EqualBtn Then

lastOp = operations.opNull

End If

End Sub

In the class library for the matrices, you’ll note that I added a “Copy” method which simply copies the contents of one matrix to another if they are the same size, in order to make the above operations easier. This wasn’t strictly necessary – I could have simply said ScratchPad = 1.0 * Accumulator, but that’s lame and poor use of memory (since a new matrix would be created). What I couldn’t do would be to say “ScratchPad = Accumulator,” since that would not copy the data but instead would copy the reference to that data, so that both Accumulator and ScratchPad would be pointing to the same object instance – that would be very bad unless I subsequently assigned Accumulator to point to a different matrix. Nor is there any way to do operating overloading on “=” as an assignment, because that would block the very referencing assignment I just mentioned. Thus, a “Copy” routine is required.

Finally, I need to support the CE and AC buttons, but these just leverage the “ClearMatrix” and “PushMatrix” methods. AC resets everything:

Private Sub ACBtn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ACBtn.Click

ClearMatrix(Accumulator)

ClearMatrix(ScratchPad)

PushMatrix(ScratchPad)

Me.DeterminantBox.Text = CStr(0)

lastOp = operations.opNull

End Sub

While CE just clears the scratch pad matrix, but not the accumulator or last operation:

Private Sub CEBtn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles CEBtn.Click

ClearMatrix(ScratchPad)

PushMatrix(ScratchPad)

Me.DeterminantBox.Text = CStr(0)

End Sub

Debugging and execution

At some point you’ll want to start debugging your code, and copying it over to a Windows app to do this would be wasteful. Fortunately, you don’t have to do that; Visual Studio comes with useful smart device emulators. Assuming you’ve set the MatrixMath project to be the startup project as described above, then simply hit F5. You’ll be presented with a list of choices for debugging. You can deploy the app to a connected device and run it “for real” on there, debugging as usual, or you can choose one of the emulators presented. I have an attached device, but I prefer not to deploy any application to it until I know that it’s bug free, so I always choose “Pocket PC 2003 SE Emulator.” The emulator has identical functionality to an actual device of that type. When you deploy to it, it will take a minute to get it onto the emulated device because it really is “installing” it there. You can then set breakpoints in your code and debug as usual, even checking values. (Note that I created the project as a Windows CE 5.0 project, but am debugging it using the Pocket PC emulator. Both can use .NET CF 2.0; I’ve stuck to basic functionality, and so there’s no problem here.)

There’s something else cool that you can do, though. Note that .NET CF is an almost perfect subset of .NET, and so you can actually run your application right on your desktop machine! Just dig down to the EXE that got built below your project directory, and double-click it – the application should run like it would on the handheld, provided that you didn’t write any code specific to the various buttons on the handheld.

That about wraps it up for this week. The final code is attached in the ZIP file, as usual. Next week I'm hoping to write a mercifully shorter post which discusses snippets and error correction. ‘Til then…

--Matt--*