Appointment ListChanged Event

It appears as though the ListChanged event in PocketOutlook for the AppointmentCollection does not work correctly--at least I couldn't get it to work. Not too much on the web about this but I found a related post on the microsoft.public.dotnet.framework.compactframework newsgroup:

Has anyone been able to receive an event when you've registered to receive events from ListChanged?

Here is the code I'm using (I'm using VS 2005 RC1 with CF 1.0):

OutlookSession outlook = new OutlookSession();
outlook.Appointments.Items.ListChanged += new
ListChangedEventHandler(Items_ListChanged);

This code runs just fine, but changing the calendar doesn't fire this event in my application. I've searched the net, but haven't found anyone who appears to have used it.

Peter Foot, from InTheHand fame, then responded:

I haven't checked, but it's possible that the events in Microsoft.WindowsMobile.PocketOutlook only fire when the changes are made through these APIs not when changed from another application...

The original poster, however, corrected Peter with information from the MSDN docs:

Here's what the docs say:

"Occurs when either the collection changes, or when an individual PIM item in the collection changes."

Additionally, the MSDN article "What's New for Developers in Windows Mobile 5.0" says that you can track changes made to Pocket Outlook folders using managed code and gives an example, so it sounds like it should show changes made by other applications. As far as I can tell, that's the whole idea, in fact.

But I can't get it to trigger any events.

SystemState CalendarAppointment Events Seem Very Broken

I posted the following to microsoft.public.dotnet.framework.compactframework about the CalendarAppointment related system states (direct link):

For the most part, I've had good experiences with the new Microsoft.WindowsMobile.Status.SystemState infrastructure in .NET CF 2.0. However, recently I've run up against numerous issues with the CalendarAppointment* and CalendarNextAppointment* events. Incidentally, I've tested this on the I-Mate KJAM Pocket PC Phone as well as the Cingular 2125, T-Mobile SDA, and the I-Mate SP5m SmartPhones. It shouldn't be too hard to repo what I'm describing on your own device.

I will describe the problems in descending importance:

1. The SystemState calendar related events do not properly notify subscribers when the calendar appointment state changes. My impression of these system states is that an event will be fired throughout the day as a user's calendar appointments occur. I would say that in more than 90% of the cases, no event is triggered. I haven't been able to diagnose exactly why this is. The problem I'm describing here seems relevant for all calendar related events. For example,

private SystemState _stateCalendarAppointmentBusyStatus;

private void Init()
{
_stateCalendarAppointmentBusyStatus = new
SystemState(SystemProperty.CalendarAppointmentBusyStatus, true);
_stateCalendarAppointmentBusyStatus.Changed += new
ChangeEventHandler(OnStateCalendarAppointmentBusyStatusChanged);

}

private void OnStateCalendarAppointmentBusyStatusChanged(object sender,
ChangeEventArgs args)
{
AppendText(SystemProperty.CalendarAppointmentBusyStatus,
(BusyStatus)args.NewValue);

}

private void AppendText(SystemProperty systemProperty, object newValue)
{
_textBox.Text += systemProperty + ": " + newValue + "\r\n";

}

Just to add a little more feedback on this (at the risk of muddling my point). I do actually tend to see events fire if I go in and modify the _current_ calendar entry. For example, if it's 4:15PM and I change my current calendar appointment (which occurs from 4-5:00PM) from "Busy" to "Out of Office", a calendar related event (e.g., CalendarAppointment or CalendarAppointmentBusyStatus) will fire. However, if it's 3:59PM and my current calendar entry says that I am "Free" then at 4:00PM, when you would expect my 4 o'clock appointment event to trigger an event, nothing happens :(

2. At this point, I thought perhaps I misunderstood what the current calendar appointment events did particularly because I seemed to get events when I would go into the calendar and modify the current appointment. However, this isn't the issue. I setup a polling sensor that would, instead of relying on the events, constantly poll the calendar related system states. You can do this because calling SystemState.CalendarAppointment, for example, returns the current value of that system state. However, what I found through polling was that this system state was not actually changing. To test this out, setup a "refresh" button in your GUI or run a windows Timer object to spit out the current state of the CalendarAppointment* system states. Then, add 5 or 6 test appointments to your calendar that will occur over the course of the next 10 minutes. You'll note that the states don't actually change with the calendar appointments. I've found that the CalendarAppointment* and CalendarNextAppointment* seem to be particularly troublesome while CalendarHomeScreenAppointment* stuff works a little more frequently (though these events are much less useful to us).

3. Going back to using the system state events. Interestingly, the following code will sometimes throw a NullReferenceException because the args object passed in is null. Perhaps this makes sense--if the current appointment is deleted the BusyStatus switches from a known state to a null state--however, this is underdocumented. An unsavvy programmer could easily fail to null check the ChangeEventArgs argument.

private void OnStateCalendarAppointmentBusyStatusChanged(object sender,
ChangeEventArgs args)
{
AppendText(SystemProperty.CalendarAppointmentBusyStatus,
(BusyStatus)args.NewValue);

}

Hopefully someone at MS has the patience to read through this whole post and respond. If you made it this far, thanks!

UPDATE 09/11/2007: I received word from Microsoft today that this is indeed a bug in WM 5.0. Direct quote from the Microsoft employee, "I’ve confirmed the bug on WM 5.0, but it seems to be fixed in WM 6.0. That is, that the Notification Broker (and associated registry settings) don’t update properly when the calendar changes."

Issues with SystemState.Date

The SystemState functionality on Windows Mobile 5.0 phones provides a straightforward facility for tracking certain device states and events (e.g., power, signal strength, sms and phone calls). See this link for a listing of all (144?) individual system states that one can easily track with the .NET event model. However, we've identified a few problems with this framework in my lab.

The first relates to SystemProperty.Date. Subscribing to the SystemProperty.Date results in a ChangedEventArgs object with the wrong value type, or, at least a value type that is inconsistent with documentation. Even the SystemState.Date type (which is of type System.DateTime) would leave you to believe that the ChangedEventArgs.NewValue object would be of type DateTime. In this case, however, it's actually a byte array of length 8. We believe this represents milliseconds in UTC time (8 bytes in C# is a long type). See this Date and Time article at MSDN for more on working with date and time. This typing issue results in a InvalidCastException in the following code.


private SystemState _stateDate;

cstr(){
_stateDate = new SystemState(SystemProperty.Date);
stateDate.Changed += new ChangeEventHandler(OnStateDateChanged);
}

private void OnStateDateChanged(object sender, ChangeEventArgs args){
//The code below will throw an exception as the args.NewValue type is actually
//a byte array of size 8! This is undocumented and unexplained.
DateTime date = ((DateTime)args.NewValue);
}

I have not comprehensively explored this issue. Other than the fact that the arg.NewValue is a byte array of length 8, I cannot elaborate. It is only conjecture that args.NewValue here is a timestamp in milliseconds at UTC. Regardless, it seems to contradict documentation and go against the paradigm established by other SystemState functions.

One final note about this state. The SystemState.Date docs say:

Gets the current date. This Date/Time value changes once per day. Monitor this property to perform actions on a daily basis. Do not use Date to get an accurate clock time; instead, use Time.

The documentation does not explicitly point out the strategy or time of day that SystemState.Date changes, only that it changes daily. I had hoped that it would change at midnight each and every day; however, what we found was that SystemState.Date appeared to change at midnight GMT (or 5PM PST). So, even if you were to schedule a daily routine with this property, it wouldn't necessarily be at the beginning of the day. Given this limitation, we decided to roll our own SystemState.Date event class that fires at midnight each day.

If I get a chance this weekend, I'd like to follow up this post with the problems we've experienced at my lab with the SystemState.CalendarAppointment* properties. They don't appear to change at all no matter what the calendar/appointment structure is like on the phone.

Update February 9th, 3:15AM: My suspicions about the 8-byte array were somewhat correct. It is a representation of DateTime. This is how you properly convert the byte array to a DateTime object:

byte[] rawValue = SystemState.GetValue (SystemProperty.Time) as byte[];
long value = BitConverter.ToInt64 (rawValue, 0);
DateTime time = DateTime.FromFileTime (value);

VS2005 Debugging Problem, Breakpoints AutoDisabling Themselves

I posted today to microsoft.public.dotnet.languages.csharp about a VS2005 debugging problem that my colleague is experiencing (direct link).

My colleague is having problems debugging in VS2005. When he sets
breakpoints in his code and launches his application via Debug->Start
New Instance, the breakpoints autodisable themselves and the
"breakpoint icon" switches from being filled in to outlined with a
warning glyph on the bottom right hand corner. When moused-over, the
icon reads "The breakpoint will not currently be hit. The specified
module is not being loaded." I checked the loaded modules list via the
Debug->Windows->Modules interface and the specified module was, indeed
loaded, with a pointer to a valid pdb (as far as I can tell).

I even started a brand new Form application from scratch and ran it in
debug mode without adding any new code. I set a breakpoint at the first
line in Program.cs but this too was autodisabled with the same "module
is not being loaded" warning.

I Googled around the newsgroups/web for a while but did not find
anything that directly related.

I should note also that: setting a breakpoint via
System.Diagnostics.Debugger.Breakpoint() works as does Debug->Step Into
new instance.

Installation Error, Support Info: 4

I had problems deploying and running .NET CF 2.0 applications on my i-mate K-JAM (running Windows Mobile 5.0--OS 5.1.70). I posted this message to Google Groups:

I've been unable to successfully load a small test app I've written in VS2005 and .NET CF 2.0 (C#) for the i-mate K-Jam PocketPC Phone Edition.

The error that pops up on the K-JAM when deploying and debugging from VS2005, "Installation error. Stop all applications and processes and maximize available storage space, and run installation again. Support info: 4."

If I attempt to run the app by clicking on it in the file explorer on the K-JAM, I get the error, "This application (TestPocket.exe) requires a newer version of the Microsoft .NET Compact Framework than the version installed on this device." When I click details, I get:

TestPocket.exe
InvalidProgramException

I've tried this with the target device selected as both "Windows Mobile 5.0 Pocket PC Device" and "Windows Mobile 5.0 SmartPhone Device." I receive the same error in both cases.

Has anyone run into this before? I can successfully deploy my test app to the PocketPC and SmartPhone emulators as well as to the Cingular 2125 SmartPhones.

Mark Prentice replied with a pointer to a working solution at his blog:

I’m happy to report the workaround for the system failure, which will be included in SP1, has now also been slipstreamed into the current download. If .NET Compact Framework v2 CAB installation on a Windows Mobile 5.0 device fails with error #4 then this fix is for you. Just re-download the NETCFv2 package and re-install!

Here's a link to the .NET CF 2.0 download.

MenuItem.MenuItems.Clear NotSupportedException

When I call myMenuItem.MenuItems.Clear() during runtime, I get a

"An unhandled exception of type 'System.NotSupportedException' occurred in System.Windows.Forms.dll

Additional information: NotSupportedException"

This same error occurs if I call myMenuItem.MenuItems.Remove(menu_i) in a for loop at the point when myMenuItem.MenuItems.Count is down to 1. I can remove all menu items up until that point successfully.

I posted to forums.microsoft.com here.

Connect to Device Failed

I have been unable to get the SmartPhone 2003 Device Emulator to work on my laptop. This is particularly frustrating because I have successfully run the device emulator on two different desktop machines at work. My laptop is a corporate system and, therefore, may have some firewall software or strange setting unbeknownest to me.

The error I get is identical to this thread on forums.microsoft.com. Basically, I try debugging a simple test application with the SmartPhone 2003 SE Emulator and I have to suffer through a long pause before I get an error dialog that reads, "There were deployment errors. Continue?" I have the option of selecting Yes or No... neither of which helps. In the Error List in Visual Studio I get "Connect to Device Failed - Conman HelpText System."

According to the help thread mentioned above, this connection error is most likely due to a problem with the ip of the emulator. By default VS2005 beta 2 uses TCP/IP as the transport to the emulator. Unfortunately there is no easy way to determine the ip of the SmartPhone 2003 emulator (though there is a way to do it in the PocketPC 2003 emulator). I then installed the Microsoft Loopback Adapter solution, instructions found here. This did not solve my problem either -- in fact, I get the exact same error.

Beyond this, I've tried just about every setting in Tools->Options->Devices->SmartPhone 2003 SE Emulator->Properties but to no avail. In addition, I foundthat the easiest way to test the connection setting was to employ the "Device Emulator Manager" found in VS2005 (Tools->Device Emulator Manager) rather than to attempt a debug execution on the emulator.

I'm going to give up for now and debug straight off the cell phone itself. This, however, was not a possible solution this past week because I did not have my cord with me.