Access violation

[RPP]

I am getting the following message whenever I open an email that is in a shared folder. I am not the owner of this folder, I have Read and Add priviledges to it. The message I am trying to open was originally sent to me and I put it into the folder.

“Access violation at address 5213C190 in module ‘gwenv1.dll’.
Read of address 00000000″

The title of the messagebox is “Sorry, the applet could not be executed” which makes me assume it is a Formativ related problem.

I don’t have an applet that would be triggered by any of the various ‘open’ events. My PC has the Creator installed. The error does not occur if I go and log into another PC that only has Runtime.

The only applets attached to Creator/my PC are those I have written. There are no other add-ons or solution packs present.

We are on version 2.0 of Formativ

—

In what may or may not be a related issue. I get a “Catastrophic Failure” message from Groupwise sometimes when I try to send a message although the message still seems to send OK.

We have seen this message on one or two other PCs (where only Runtime is present) but it appears to affect my Creator PC the most.

Any ideas what might cause this. The message appears to be the same design as the issue above so I assume it is a Formativ message.

I do have an applet attached to the Send event(s) but the emails the error has occurred on are not of interest to the applet and it should be ignoring them

Thanks

Simon

Topic

[lp_irovetz]

Hi RPP

I’d got same ‘violation error’ with two ways
1°) an appplet with “utilities.Timer”
2°) sometime, when i closed a formativ form without put it, before closing, on front windows in studio/creator.

After this type of error, there are no way to run GroupWise even on other fonctionality.

Hope this help

L.P. Irovetz
ARCANE GroupWare

[Support 1]

Dear Simon,

Does this error appear for all folder types, or just for shared incoming folders? Does it always occur for this folder? Does it occur for other shared incoming folders?

You are correct in assuming that the message title “Sorry, the applet could not be executed” is related to Formativ. Given the steps you describe, this indicates that a Formativ applet was triggered by a GroupWise event. The specific error has occurred inside one of the GroupWise binary modules, “gwenv1.dll”.

The message “Catastrophic Failure” is most likely from GroupWise – it is definitely not from Formativ.

Both of these errors are likely to result from the GroupWise Object API state becoming unstable. This can arise due to a Formativ applet calling into the API in a sequence which leads to a memory leak or a dangling pointer. In fact, an applet may need to “manage” internal API resources. This applies to other C3PO Developers (eg. Delphi, VB, C++), as well as Formativ Developers.

Our experience with the GroupWise APIs has taught us that sometimes an obvious or intuitive approach is not feasible; that an applet must be redesigned to work around an API defect or to manage internal API resources. In rare cases we have never found a workaround. For example, given a message object reference, accessing its properties can provoke misleading GroupWise errors – where the message’s enclosing folder is a query folder or shared incoming folder.

The first thing, however, is to determine which, if any, applet leads to the “on open” error. This requires a process of elimination, as suggested by the following steps:

• For each applet, go to the Integrations tab in the Formativ IDE and uncheck the box at Enable integrations.
• Now that all applets are disabled, close the Formativ IDE and try to open your message in the shared folder. If no error appears then the problem is definitely related to one (or more) applets. But if an error appears then enable your applets’ integrations, restart GroupWise and send your Formativ configuration to support@advansyscorp.com (ignore the step below).
• Enable one applet and try to open your message in the shared folder. If it opens without error, enable another applet and try again. And so on.

If you find that the error appears when one of your applets is enabled, you may need to add some bullet-proofing to the applet. That is, change the source code to bypass processing if the enclosing folder of the active message is one of the usual suspects. You can also add Trace commands to your source code to get a real-time picture of the execution sequence. See the Developers Guide section Error Handling and Debugging for details.

I hope this helps.

Regards,
Advansys Support

[RPP]

Thanks for the replies. The information has proved very useful.

I removed/replaced the Integrations as described and the simple act of doing so reminded me that one of my applets does fire on the Open event. Doh! Haven’t changed this one in ages though which is why I was ignoring it. I guess it’s always been busted for shared folders (no other folders have caused problems) but it hasn’t been apparent until now.

The extra information about the Trace facility is very handy, I have been ruing Formativ for a lack of runtime debugging and using message boxes instead – which sometimes ruins the test in itself. I shall get the third party tool at once!

For this test msgboxes worked fine, the suspect code is as follows

Dim oMsg
Dim oAcct

msgbox “s1”

Set oAcct = Client.ClientState.CurrentAccount

msgbox “s2”

On Error Resume Next
Set oMsg = Client.ClientState.CommandMessage
On Error Goto 0
If Not IsObject(oMsg) Then
On Error Resume Next
Set oMsg = oAcct.GetMessage(Groupwise.ItemMessageIDFromView())
On Error Goto 0
End If

msgbox “s3”

If IsObject(oMsg) Then

msgbox “s4”

< code within the loop isn’t relevant at this point >

End If

—

My applet is triggered by the Groupwise application level event of ItemRead

The event fires twice.

The first time I get messages for S1, S2, S3 and no error. I don’t get S4 but I know why.

The second time I get messages for S1, S2 and then the error message.

A few extra message boxes seems to indicate the problem is with this part of the code …

On Error Resume Next
Set oMsg = Client.ClientState.CommandMessage
On Error Goto 0

Specifically the “Set oMsg = Client.ClientState.CommandMessage” call

Am at a bit of a loss in how to code around this. I don’t really want the second call to fire at all, especially since it then crashes!

This problem only occurs on my PC (where Creator is) and only for emails in Shared folders so I can live with it but I suspect it leads to the Catastrophic Failure message eventually.

I’ll experiment a little more and see if I can get around it.

Thanks for your help so far

Simon

[RPP]

Having altered my coding a little I now have …

Set oAcct = Client.ClientState.CurrentAccount

On Error Resume Next
Set oMsg = Client.ClientState.CommandMessage
On Error Goto 0

If Not IsObject(oMsg) Then
‘Check to see if the message is actually in a shared folder owned by someone else
‘If not then …
If Client.ClientState.SelectedFolder.Owner.DisplayName = oAcct.Owner.DisplayName Then
On Error Resume Next
Set oMsg = oAcct.GetMessage(Groupwise.ItemMessageIDFromView())
On Error Goto 0
‘If so, get the message from the folder itself
Else
On Error Resume Next
Set oMsg = Client.ClientState.SelectedFolder.Messages(Groupwise.ItemMessageIDFromView())
On Error Goto 0
End If
End If

If IsObject(oMsg) Then

MsgBox “S4”

< code inside loop goes here >

End If

—

I can’t do anything about the ‘memory leak’ so am just trying to get msgbox S4 to fire.

If the chosen email is in a Shared folder I don’t own then I would expect my oAcct.GetMessage to fail since the message isn’t strictly speaking in my mailbox anymore.

What I am doing above is testing ownership of the folder and reacting accordingly.

Not shared means use GetMessage, shared means get the message from the folder itself.

However, although this makes S4 appear OK any attempted use of the oMsg variable then causes a ‘standard’ Formativ error of “Object required: ‘oMsg’ at line 38, column 6”

Line 38 is the next line to use oMsg after the IsObject(oMsg) test.

Further investigation tells me that the line

Set oMsg = Client.ClientState.SelectedFolder.Messages(Groupwise.ItemMessageIDFromView())

is failing in a weird way. The Groupwise.ItemMessageIDFromView() part errors, creating a ‘token execution failed’ message but the oMsg object is at least partially created to pass the IsObject test?

The Groupwise.ItemMessageIDFromView() call works fine when the message is in my mailbox and I’ve used this same technique in another applet and it worked fine so I don’t get how it’s going wrong here.

How do I get the message if I can’t tell which message has been opened?

This problem is affecting several PCs, not just my Creator one. The applet is meant to test an opened email to see if the user has an action against them but currently it doesn’t get that far.

Thanks

Simon

[RPP]

OK. Some further testing has thrown up the following …

1) The line that fails is

Set oMsg = Client.ClientState.CommandMessage

It fails despite the On Error arround it. Since it never seems to get the message from this line I have removed it. The ‘Groupwise.ItemMessageIDFromView()’ is now used as the source of the opening email.

2) The application level event of OnItemRead causes Groupwise.ItemMessageIDFromView() to fail when used against the Shared Folder’s messages collection.

Using the email level event of OnOpen doesn’t seem to suffer from this problem.

3) The Catastrophic Failure message has the same title as the access violation – Sorry, the applet could not be executed. The message is from Formativ, or at least passed through by Formativ.

—

Now I know what to avoid doing I can probably do so, hopefully it won’t limit the actual development.

A few questions …

A) Is it better (faster) to get a message using the GetMessage( <id> ) function at Account level or by using the SelectedFolder.Messages( <id> ) function.

Some of our users will happily harbour thousands of emails in any one folder so I need to know which method is least likely to be affected by numbers of emails. Logically I feel it ought to be the Account level one but am not sure.

B) Is there any difference between the OnItemRead and OnOpen events?

What happens if someone is using the Quickviewer. Do they still get an event?

C) Is it possible to integrate my Applets with the toolbar in the QuickViewer. They get the standard Reply/Forward buttons but not my additional ones.

Thanks

Simon

[MA]

quote:

---

A) Is it better (faster) to get a message using the GetMessage( <id> ) function at Account level or by using the SelectedFolder.Messages( <id> ) function.

---

I will recommend to use the Account.GetMessage(MessageID) method instead of Folder.Messages(MessageID). I did a simple test of these two methods. GetMessage() method retrieve the message faster then Folder.Messages(). In my test the GetMessage() took .00350285 Milliseconds where the Folder.Messages took .26625061 Milliseconds.

quote:

---

C) Is it possible to integrate my Applets with the toolbar in the QuickViewer. They get the standard Reply/Forward buttons but not my additional ones.

---

Try the GroupWise Main Window Toolbar integrations.

Hope this helps.
MA

[Support 1]

Thanks for your replies L.P. and MA.

Simon:

Formativ also displays error messages which originate from GroupWise and the Windows Script Host. This is why you see a dialog titled “Sorry, the applet could not be executed” with a message like “Catastrophic Failure” or “Object required…”

Another way to determine whether a folder is shared incoming is to check its Shared property, as in:

  if oFolder.Shared = fgwSharedIncoming then
    ...
  end if

Given a Message object reference, you can obtain its enclosing folder from the property EnclosingFolders.

To find out how a given GroupWise event works, try this. Create a simple applet that displays a message box, associate it with the appropriate event(s) and see when it gets executed. The behavior you see will dictate when to use one event over another.

It’s often worthwhile posting questions about the GroupWise APIs to the appropriate Novell Developer Support Forums. While we always try to respond where possible, time constraints may prevent us from fully answering enquiries about issues that are specific to the GroupWise APIs.

I hope this helps.

Regards,
Advansys Support

[RPP]

Thanks for all your replies

MA:
That test was very helpful and something I should have done myself – thanks!

Integration with the main toolbar I’d tried and although the button does appear down on the Quickviewer’s toolbar it’s also on the Groupwise Main toolbar which I don’t really want.

I was hoping to get the button to appear on the ‘item context’ toolbar of the Quickviewer which is over to the right by default. Doesn’t look like Formativ can do that so I’ll just have to disappoint Quickviewer users.

Support:
The test for Shared status is tidier than mine, thanks, missed that one in the API help.

I do realise the API isn’t your responsibility but in this case it was the connection between Formativ’s events and the current folder/message I was struggling with.

Once I have got the object I want; be it message, folder, or whatever; I am usually OK with following the API through. Its getting to them in the first place and being sure I have the right one!

Still, by a combination of randomly changing things, helpful input from yourselves/others on this site, and coffee I now have an applet that is mostly behaving and can cope with various shared folder scenarios.

Thanks again

Simon

[Support 2]

Good news and thanks for the feedback.

Regards,

Advansys Support

[Author]

Replies