Error on obtaining CommandMessage

[Amy]

Hi all,

I have two users that are getting an error on the following line.

Set objMsg = Client.ClientState.CommandMessage

The error just gives the path to the applet and the line number.

I am not able to reproduce this error myself and there are many other users that use this applet and do not get this error.

The applet itself replaces the forward event and then creates a new (draft) message and sends it off.

Any Ideas?

Thanks

Amy

Topic

[Support 3]

We could not re-produce the behaviour in here. It may be the GroupWise client or some unknown issue on that user considering the code is working for most of the users. May be you need to run the GWCheck on that user or upgrade the GroupWise client.

You can also place the error handler on the code, so that when it fails to access the message object it prompt the user to some meaningful message. Please see below an example:

  
Sub Main(Client, GWEvent)
  dim objMsg

  if not GetMessage(objMsg, Client) then
    msgbox "Unable to access the message. Please try again"
  end if

  set objMsg = nothing
End Sub


' Access the message.
function GetMessage(byref abjMsg, Client)

  on error resume next
  GetMessage = false

  set abjMsg = nothing
  Set abjMsg = Client.ClientState.CommandMessage

  if not abjMsg is nothing then
    GetMessage = true
  end if

end function

Regards,
Advansys Support

[Support 1]

Are the users trying to forward attached messages? The CommandMessage property can only be expected to work reliably in GroupWise 7.0.3, which adds support for attached messages with CommandMessage.

In addition, here is an excerpt from the online documentation:

quote:

---

CommandMessage isn’t available for new messages. If you try to access Manager.ClientState.CommandMessage from a new message, GroupWise 6.5 throws an “Unspecified error” exception.

---

I hope this helps.

Regards,
Support

[Amy]

You solution isn’t feasible for us since this just prevents the applet from continuing on.

When the user tries again he just gets the same error.

We are using groupwise 6.5 but the user always chooses “Forward” never “Forward as Attachment”.

I will ask the IT dept. if they ran GW_CHECK. They actually rebuilt his workstation and the problem re-appeared.

Is there another method I could use to determine the current message when the Client.ClientState.CommandMessage fails?

Any help you can give is much appreciated. Thanks,

Amy

[Support 1]

quote:

---

We are using groupwise 6.5 but the user always chooses “Forward” never “Forward as Attachment”.

---

In my previous post I mentioned “attached messages”. By this I meant messages that the user has received as attachments. So the problem is in opening a message attachment and invoking CommandMessage with that message active. Here’s the relevant item in the change log for GroupWise 7.0.3:

quote:

---

Calling the CommandMessage property works on an attached message.

---

Regards,
Advansys Support

[Amy]

The user is not invoking the CommandMessage on an attached message either.

The IT dept did run the GW_CHECK and several other tests and did not find any problems.

The user has no problem with CommandMessage in other applets that run on that message class. (executed via a button on the toolbar).

I have given up trying to figure out why this happening and I’ve moved on to finding an acceptable solution.

Here is my applet code.

  

Sub Main (Client, GWEvent)

on error resume next

dim objMsg, objDraftMsg, g_acct, intMsgID, i, strSubject, strBody

Groupwise.CancelGroupwiseEvent = true
Groupwise.CloseWindow

Set g_acct = Groupwise.Account

Set objMsg = Nothing
Set objMsg = Client.ClientState.CommandMessage

if objMsg is Nothing then 

   msgbox "Message could not be found. Please try again"
   exit sub

end if 

'--- Class Name is GW.MESSAGE.MAIL.MyApp1 or GW.MESSAGE.MAIL.MyApp2
Set objDraftMessage = g_acct.Mailboxes.Messages.Add(objMsg.className) 

strBody = vbcrlf & " <<< " & g_acct.Owner.DisplayName & " " & now & " >>> &
strBody = strBody & vbcrlf & objMsg.BodyText

'--- I then loop through and add any attachments or fields
...

intMsg = objDraftMsg.MessageID
Groupwise.ItemOpen intMsgID, ""

Groupwise.TextSetSubject strSubject, false

objDraftMsg.Delete()

Set g_acct = Nothing
Set objMsg = Nothing

End Sub

I was thinking that I could move the CancelGroupwiseEvent to after I check if the message exists. Then I would exit the applet and not cancel the “Forward” when the message doesn’t exist but I would only want to do this if the user had chosen to “Forward as Attachment”. Otherwise my GW.MESSAGE.MAIL.MyApp1 would be sent as GW.MESSAGE.MAIL

Is there a way to differentiate if the user picked “Forward” or “Forward as Attachment”? There doesn’t seem to be anything in the EventParams object.

Thanks,

Amy

[Support 3]

quote:

---

Is there a way to differentiate if the user picked “Forward” or “Forward as Attachment”?

---

Sorry, not available at present.

quote:

---

Is there another method I could use to determine the current message when the Client.ClientState.CommandMessage fails?

---

You can try to access the message using the clientstate.SelectedMessages. This method will not work, if you run the code when message view is opened.
set oMessage = Client.clientstate.selectedmessages.item(1)

Not sure whether it will help, may be you can try to change the “OnForward” event order in Formativ. You can change the event execution order (i.e “Before GroupWise Event”, “After GroupWise Event”, “Replace GroupWise Event”). Open the Events dialog from the “Formativ Integrations” tab page, click small the drop-down arrow next to the “OnForward” event, change to “Before GroupWise Event” or “Replace GroupWise Event”.

Hope this helps.

Regards,
Advansys Support

[Amy]

I could never trap the error since as soon as the Client.ClientState.CommandMessage line was read then Groupwise would freeze. Even with on error resume next on.

After several software tests we’ve determined that it must be hardware problem and the two affected users are going to get new workstations.

Thanks for all your help.

[Support 3]

Thanks for keeping us informed.

Lets hope the work-station upgrade fix the strange behaviour. We are interested to know the results.

Regards,
Advansys Support

[Author]

Replies