Access is denied. (OS error 16r5)

It’s a shot in the dark, but we had one bug that sounds similar to what you’re seeing.  The bug was almost certainly introduced by us, I don’t think it was inherent to the native ST image.  We had created our own subclass under Error called “UserInputError” where we had overridden “defaultAction”.  We were using it to display tooltips next to invalid data when dialogs were validated, which can happen when switching tabs, or when pressing Next on a wizard.  Notes from our defect database:

“The original intent of UserInputError was to allow dialogs to catch exceptions relating to input problems so they could display some feedback to the user. The design relies on the dialog having appropriate exception handling code. First you catch the exception; second you tell the exception to do its defaultAction (which displays the feedback); then you resume work from the point where you caught the exception.

This works fine if you catch the exception, but in cases where the UserInputError exception got generated but nobody was watching to handle it, the flow of execution would fall through to the default behavior of Exception class. Exceptions are non-resumable. Their defaultAction is to display a walkback window spawned in a new process. Later they kill the originating process, to prevent resumption. But UserInputError overrode this defaultAction method to only display the feedback (not display a walkback and launch a second process), so in cases where you didn't catch the exception, you could potentially kill the process in which the application was running. (Whether the process got killed depended on whether the #handle method got invoked.)

To fix the problem, we moved the feedback code from #defaultAction into a #displayFeedback method. When you catch the exception, you now have to invoke #displayFeedback. If you don't catch the exception, the default action will display a walkback and spawn a process. We also added an informative message to developers, telling them to catch the exception.

The bottom line is that before this change, failing to catch the exception could potentially kill your image. Now failing to catch the exception will display the same error message in a less friendly format, and then your GUI code may complete (closing the dialog, etc.).”

It seems so simple in retrospect, but was pretty annoying to solve at the time because of how random and rare it seemed.  It turned out to not be random at all.  I hope the story helps.

Now and then VSE will crash without error (just go away) when interacting with tab controls.  I used to think the problem was related to the use of RichEdit controls in a tabbed UI, but now it has also happened in tabbed UIs that have other controls in them.  This isn’t reproducible easily, but sometimes while using the mouse to switch from one tab to another the app will “just go away”.

I also wonder  if it’s the tooltip code that might be causing the problem.

Anyone else experience this?  Thanks.

-Carl

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Thanks Lorin.  We aren’t doing anything like that with tooltips but maybe this information will be helpful.  If I do manage to figure out why this is happening, I’ll be sure to share what I learn.

-Carl

It’s a shot in the dark, but we had one bug that sounds similar to what you’re seeing.  The bug was almost certainly introduced by us, I don’t think it was inherent to the native ST image.  We had created our own subclass under Error called “UserInputError” where we had overridden “defaultAction”.  We were using it to display tooltips next to invalid data when dialogs were validated, which can happen when switching tabs, or when pressing Next on a wizard.  Notes from our defect database:

“The original intent of UserInputError was to allow dialogs to catch exceptions relating to input problems so they could display some feedback to the user. The design relies on the dialog having appropriate exception handling code. First you catch the exception; second you tell the exception to do its defaultAction (which displays the feedback); then you resume work from the point where you caught the exception.

This works fine if you catch the exception, but in cases where the UserInputError exception got generated but nobody was watching to handle it, the flow of execution would fall through to the default behavior of Exception class. Exceptions are non-resumable. Their defaultAction is to display a walkback window spawned in a new process. Later they kill the originating process, to prevent resumption. But UserInputError overrode this defaultAction method to only display the feedback (not display a walkback and launch a second process), so in cases where you didn't catch the exception, you could potentially kill the process in which the application was running. (Whether the process got killed depended on whether the #handle method got invoked.)

To fix the problem, we moved the feedback code from #defaultAction into a #displayFeedback method. When you catch the exception, you now have to invoke #displayFeedback. If you don't catch the exception, the default action will display a walkback and spawn a process. We also added an informative message to developers, telling them to catch the exception.

The bottom line is that before this change, failing to catch the exception could potentially kill your image. Now failing to catch the exception will display the same error message in a less friendly format, and then your GUI code may complete (closing the dialog, etc.).”

It seems so simple in retrospect, but was pretty annoying to solve at the time because of how random and rare it seemed.  It turned out to not be random at all.  I hope the story helps.

Now and then VSE will crash without error (just go away) when interacting with tab controls.  I used to think the problem was related to the use of RichEdit controls in a tabbed UI, but now it has also happened in tabbed UIs that have other controls in them.  This isn’t reproducible easily, but sometimes while using the mouse to switch from one tab to another the app will “just go away”.

I also wonder  if it’s the tooltip code that might be causing the problem.

Anyone else experience this?  Thanks.

-Carl

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Hi Carl,

I don’t have an answer, but perhaps you can try:

1.       Using Spy++ to get a log of the windows messages that are being sent to the control and see what could be triggering it off?

2.       Run your application in a process from Visual Studio and see what exceptions or other issues are being raised?

-- Derek

Thanks Lorin.  We aren’t doing anything like that with tooltips but maybe this information will be helpful.  If I do manage to figure out why this is happening, I’ll be sure to share what I learn.

-Carl

It’s a shot in the dark, but we had one bug that sounds similar to what you’re seeing.  The bug was almost certainly introduced by us, I don’t think it was inherent to the native ST image.  We had created our own subclass under Error called “UserInputError” where we had overridden “defaultAction”.  We were using it to display tooltips next to invalid data when dialogs were validated, which can happen when switching tabs, or when pressing Next on a wizard.  Notes from our defect database:

“The original intent of UserInputError was to allow dialogs to catch exceptions relating to input problems so they could display some feedback to the user. The design relies on the dialog having appropriate exception handling code. First you catch the exception; second you tell the exception to do its defaultAction (which displays the feedback); then you resume work from the point where you caught the exception.

This works fine if you catch the exception, but in cases where the UserInputError exception got generated but nobody was watching to handle it, the flow of execution would fall through to the default behavior of Exception class. Exceptions are non-resumable. Their defaultAction is to display a walkback window spawned in a new process. Later they kill the originating process, to prevent resumption. But UserInputError overrode this defaultAction method to only display the feedback (not display a walkback and launch a second process), so in cases where you didn't catch the exception, you could potentially kill the process in which the application was running. (Whether the process got killed depended on whether the #handle method got invoked.)

To fix the problem, we moved the feedback code from #defaultAction into a #displayFeedback method. When you catch the exception, you now have to invoke #displayFeedback. If you don't catch the exception, the default action will display a walkback and spawn a process. We also added an informative message to developers, telling them to catch the exception.

The bottom line is that before this change, failing to catch the exception could potentially kill your image. Now failing to catch the exception will display the same error message in a less friendly format, and then your GUI code may complete (closing the dialog, etc.).”

It seems so simple in retrospect, but was pretty annoying to solve at the time because of how random and rare it seemed.  It turned out to not be random at all.  I hope the story helps.

Now and then VSE will crash without error (just go away) when interacting with tab controls.  I used to think the problem was related to the use of RichEdit controls in a tabbed UI, but now it has also happened in tabbed UIs that have other controls in them.  This isn’t reproducible easily, but sometimes while using the mouse to switch from one tab to another the app will “just go away”.

I also wonder  if it’s the tooltip code that might be causing the problem.

Anyone else experience this?  Thanks.

-Carl

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***