Peter ~

 I think there is a problem with the SmsMessage.MoveTo function.  After upgrading to Version 3.3 from 3.2.1 my MoveTo procedure seems to move the message to the folder but when i go retrieve the message its blank.  There is no From, Date, or Body info after the move.  Can you confirm this bug?  Before the upgrade the MoveTo worked fine.  Below is the code used to intercept and move the message.

Try

  Dim strMsg As String = ""

Dim strCaption As String = ""

 'Move the message to the New SMS folder else move it to the Inbox...

Try

'newMessage.MoveTo(session.SmsAccount.Folders("ServerTXT"))  - DIDN'T WORK...

'newMessage.MoveTo(session.SmsAccount.Folders.Item("ServerTXT"))  -  DIDN'T WORK...

End Try

  If Not newMessage Is Nothing Then

    'Create the message and display it to the user....

    'A message is displayed to the user right here to either read or dismiss the message

End If

End Try

End Sub

Have you been able to reproduce this?  It seems to happen when you move any message whether it is to a custom folder or one of the standard mailboxes (inbox, draft, sent, etc.)

I'm running some tests on this. What type of device are you using?

Peter

I am using the At&t Tilt and i have also tested it on the Mogal and the 8525.  All running windows 6.0. or 5.0.  None of them worked properly after the update.

Any Updates?

 It is happening to me aswell :

 SmsMessageFolder inBox = session.SmsAccount.Inbox;

SmsMessage m = new SmsMessage("66622558", "Hello");
m.Read = true;
m.Update();
m.MoveTo(inBox);

Once in inbox there's no body message stored (it's blank), even when it is on draft folder it still has no body.

Any ideas ?

It has been several weeks, I had to go back to Version 3.2.1 because one of the main functions of my program is to move messages to specific folders.  I have tried it on serveral devices all with the same result.  Windows Mobile 5, 6, and 6.1 all have the same problem.  Have you been able to confirm this problem on your tests devices?

Definitely, there's a bug in 3.3, because I tried the same simple piece of code above, in 3.2 and works fine.

Let's hope that a fix will be released soon.

We were lucky LordFuzzy, because we could downgrade

These updats have really put a hold of my program launch.  I'm glad i keep backups of my code changes.  It was easy for me to go back but still a headache.  I really like this DLL but its gotta be fixed.  Peter are you going to be releasing a patch soon?

This is proving difficult to track down because the MoveTo code did not change between releases. However are you handling the MessagingItemMoved event (or any of the other messaging events) in your code?

Also I don't see you calling Update() on the message to save the contents before you call MoveTo()...

Peter

I do not use the MessagingItemMoved event or any other events yet.  And sorry i do call it, I just didn't include it in the post.  newMessage.Update() is called right before the MoveTo is called.

I have discovered there are two separate issues here. The first one is that a change in 3.3 means that we no longer try to determine the local phone number and set the From property on new messages - instead this information is added automatically by Windows Mobile when a message is sent. The reason for this change is that the security policy on some devices resticts access to the local phone number except for privileged code. This means that for messages created locally on the device which are not sent there will be no from recipient by default. You can set this manually using

sms.Properties(MessageProperty.SenderEmailAddress) = "12345"

or to have both name and number

sms.Properties(MessageProperty.SenderEmailAddress) = "John Doe <12345>"

The second issue is a bug with the way the body text is stored. There is however a simple workaround - you can set the property directly:-

sms.Properties(MessageProperty.Subject) = sms.Body

You will then find that after moving the message these properties are set as expected.

Peter

 I do not use MessagingItemMoved either.

As it turns out the issue is not related to the new events. I posted a workaround in my previous post in this thread.

Peter

Peter ~

        That fixed the problem thank you.

Fuzzy