Reply dropdown doesn’t fire event

[RPP]

1) We have Groupwise 6.5.3 and Formativ 2.0

I have added code to the startup of Windows to ensure the “Third Party” key is in place for the current user.

I have an applet that is attached to the Groupwise application level events for Forward and Reply.

If a user opens an email and then uses the dropdown to do their reply (either to sender/to sender with msg/to all/to all with msg) then my applet doesn’t get called.

If the user just opens the email and presses the Reply button that’s directly on the toolbar then the applet works (luckily this is what most of them do but not all and not everytime)

I have tried using the Mail level events for Reply / Forward but it doesn’t work with those either.

I am testing whether the applet gets called by puttig a Utilities.Trace line right at the top of the applet. The trace reports the GWEvent value. For a Reply it should be #271

When the dropdowns are used nothing goes to the trace viewer (DebugView) at all.

This does not happen on my PC – which has Creator on it – it only seems to affect the Runtime users.

I have tried various things to find out what’s wrong/fix it

a) Change the applet’s events to include Mail level Reply/Forward
b) Change the applet’s events to be only Mail level Reply/Forward
c) Add the Third Party key to the Local_Machine hive
d) Update to 2.0.1
e) Update to 2.0.1 and then reboot anyway

None of those worked. I figured that some other obscure event must be firing instead of the #271 one so I went looking for that.

What I did was create a new applet called Trace Events. All this applet does is send out a Utilities.Trace of the GWEvent value and any EventParam items in that collection.

I attached Trace Events to ALL the Groupwise application level events (except On Startup and On Message Arrival) and ALL the Mail level events

I then shutdown groupwise and put Trace Events (Flexalocked) onto my first test PC, restarted Groupwise and watched the events from DebugView.

Using the dropdown caused no events at all.

I restarted Groupwise a second time and tried again and the Reply dropdowns suddenly started working.

I shutdown Groupwise and removed the Trace Events applet, restarted and the Reply dropdowns still worked.

I rebooted and they were still fine afterwards.

—

It appears that my attempts to watch the events actually fixed it?

The two shutdowns of Groupwise to get it going seemed a bit weird but I did note that the first time I shutdown by the X top-right whereas the second time I did File Exit (does this make a difference – does Groupwise tidy up given a File Exit closedown?)

I tried another PC and this time didn’t actually use debugView, I just cycled Groupwise twice – again I did an X first (by mistake to be honest) and then a File Exit

All I can assume is that by having an applet that is attached to all possible groupwise events it changed the registry and caused Formativ to be aware of something it previously wasn’t aware of?

That might explain why it works for me, I have installed various solution pack applets in the past and maybe they in turn altered the registry.

Although I sort of have a solution I really don’t want to release my trace applet.

Can you please explain why Formativ wasn’t seeing events before but now is. If there are registry keys to add then I can do that

2) On a similar vein, I was trying to do a Reply from the right-click pop-up menu. Having highlighted my email, I right click and choose Reply.

Using the trace feature I get event #54 as the choose type of reply box appears (to sender/to all)

Then I get event #271 within my applet. Great so far.

However, I can’t seem to get hold of the message that was selected.

Calling to Client.ClientState.CommandMessage doesn’t work
Nor does oAcct.GetMessage(Groupwise.ItemMessageIDFromView())

This fails on all PCs – including the Creator one

Is there some other way to detect which message is selected but not opened?

I get the same problem if i do reply from the ‘item context’ toolbars on Groupwise’s main toolbar or the Quickviewer toolbar.

However if I use the dropdowns within these toolbars to select Reply To Sender or Reply to All then the code works – my applet behaves as expected.

The thing that the right-click menu and the ‘item context’ Reply buttons have in common is that they display the Choose Reply Type window (to sender/to all).

When this window displays, the indicator on my mailbox changes from a solid selection to an empty rectangle selection. In programming terms this sometimes means that focus has been lost and there is no longer a “current” message, therefore my code can’t tell which mail was being replied to.

Is that possible, if so how do I work around it?

I have tried allowing my applet to intercept event #54 – Choose Reply Type window (to sender/to all). However, having attached to the event OnItemCustomReplyDlg I found I still can’t get the current message using the above code so it didn’t help.

—

These two queries are directly related to Formativ and how it responds to Groupwise and although I realise you are not responsible for any failings Groupwise may have in terms of event generation, your software relies on the token system and I do feel I am justified in asking how to make Formativ do what I need it to.

Thanks

Simon

Topic

[MA]

quote:

---

2) On a similar vein, I was trying to do a Reply from the right-click pop-up menu. Having highlighted my email, I right click and choose Reply.

Using the trace feature I get event #54 as the choose type of reply box appears (to sender/to all)

Then I get event #271 within my applet. Great so far.

However, I can’t seem to get hold of the message that was selected.

Calling to Client.ClientState.CommandMessage doesn’t work
Nor does oAcct.GetMessage(Groupwise.ItemMessageIDFromView())

This fails on all PCs – including the Creator one

Is there some other way to detect which message is selected but not opened?

---

Hi Simon,

I could not reproduce the behaviour you described above. The following code shows the subject and message id when I select an email, right click and choose reply (sender/all).

——————
dim oMsg

set oMsg = Client.ClientState.CommandMessage
msgbox oMsg.subject & vbcrlf & oMsg.messageid

set oMsg = nothing
——————

I am using GroupWise version 6.5.5 (build date 24/09/2005). I recall there was some events issues with GW 6.5.3 or some other version. May be you need to upgrade the GroupWise client. Another thought may be not practical in your situation, you can also modify the OnReply event (Formativ IDE) to execute Before GroupWise Event.

Hope this helps
MA

[Support 1]

Thanks for your answer, MA.

Simon,

1) According to Novell, a defect prevented the On Reply event from firing when choosing an item from the Reply dropdown button. This was fixed in GroupWise 6.5 SP1 (and I believe also in 6.0x, retrospectively). However, I think the issue you have seen is probably related to the following.

In general when installing an applet which registers GroupWise integrations (eg. the On Reply event), GroupWise will need to be restarted twice. When GroupWise starts, Formativ checks each installed applet for integrations and registers them if not already registered. However, at this point GroupWise has completed its loading of integrations; only on the next start-up will the newly registered integrations be loaded. This issue is documented in the Formativ Developers Guide.

If Formativ Creator or Studio is used to change an applet’s integrations (ie. at design-time), GroupWise will need to be restarted just once. This is because the Formativ IDE registers changes to integrations whenever they are made.

Neither your Trace Events applet nor a specific way of closing GroupWise will make the integrations apply.

2) An alternative way to access the selected message (ie. a message which is not open for viewing/composing) is via the SelectedMessages collection. This might be required as a workaround for an earlier version of GroupWise than MA’s. Here is some sample code:

  set oMessageList = oClient.ClientState.SelectedMessages
  if oMessageList.Count > 0 then
    set oMsg = oMessageList.Item(1) ' this is a 1-based collection
    ' do stuff with oMsg...
  end if

I hope this helps.

Regards,
Advansys Support

[Author]

Replies