Spurious error messages when using report listener to preview a report

[Mike Lewis]

This isn't really a question. I'm posting it partly for the benefit of others who might come up againt this problem, and partly in the hope that someone can explain it better than I can.

I've recently started to use a report listener for my app's report preview screen. To simplify, the code looks like this:

loWindow = NULL  
DO (_REPORTPREVIEW) WITH loWindow

* .... (customise loWindow in various ways)

this.oListener = NEWOBJECT("Reportlistener")
this.oListener.ListenerType = 1
this.oListener.PreviewContainer = loWindow

* ... more customisation and adjustments

REPORT FORM MyReport OBJECT this.oListener

It works fine on my development system, both within the FoxPro IDE and when run as an executable.

However, the first user to install the app reported various error messages at the point of opening the preview window.

I won't post the actual messages here, because they were several different errors, and they're not relevant to my story.

What is relevant is that the error were displayed in a message box that also included the words: Do you want to suspend exection?, with Yes / No / Cancel buttons.

If you click Yes, the program is presumably doing a SUSPEND, because you get a "feature not available" message. If you click No, the error is ignored and the program produces a correct preview. If you click Cancel, the program closes.

Because the app was working OK on my development system, my first assumption was that I had left one of the report-related components out of my build. But I checked the run-time requirements carefully, and came to the conclusion that I hand't. (Besides, if I had, it wouldn't have got as far as it did.)

For me, the issue here was the wording of the message. It is totally inappropriate to ask users if they want to "suspend execution", or to give them any choices when an error occurs, not to mention the "feature not available" message. This sort of error-handling should never be seen by an end user. It makes the application look unprofessional, to say the least.

My applications all include my own robust error-handler which logs any run-time errors and notifies the user in a friendly way. I suppose I resented Microsoft overriding my error-handler with their own sloppy code.

In the end, I decided to modify the source of FRXPREVIEW.PRG, which is the component of the Report Preview system that actually handles the errors. I fixed it so that the messagebox I've described here never appears, and any genuine errors are passed up to my own error-handler.

The app seems to be working fine again (after a few preliminary tests), but I don't understand why any of this was necessary. I stress that none of the errors I saw were genuine. They referred to methods that had no code in them, or to variables that weren't referenced anywhere in the app. In every case, ignoring the error caused no ill effects.

I can't believe I'm the first person to use the _REPORTPREVIEW -generated object in this way (my code is closely based on the example in the Help). Has no-one else ever seen this behaviour? What is the correct way to handle it?

I'd be interested in your comments.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[DSummZZZ]

By the Gods, I do wish Microsoft would sell VFP to ... someone so bug fixes, development, improvements could continue.

Nevertheless, I have only seen that error during testing but not in a release. Maybe because after getting it one too many times I opted for a plan 'B', whatever it was at the time.
But it sounds like that as with some of the other inherent shortcomings, you handled it the only way it could be handled - which was to fix the bad chunk of code.

From there though, did you ever determine what was actually happening internally to cause the message in the first place?


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[TamarGranor]

Wish I could offer some wisdom on why you saw the problems, but I don't have any. You might get in touch with Cathy Pountney, who seems to know more about ReportListeners than anyone else in the community.

Did you check the versions of the Reporting Apps in VFPX? Someone else might have already done this. If not, you ought to pass your changes along for the community.

Tamar

 

[Mike Lewis]

Dave,

Thanks for your comments. It's interesting that you've seen the problem in testing but not in the released version. My observation was the opposite, which is a pity because if I had seen it when testing I would never have let it go to release.

No, I never determined what was actually causing the errors. I know I should have done. It doesn't feel right to remove unwanted behaviour without discovering the underlying cause. I can only say that the preview is functioning properly now, and the user is happy.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Mike Lewis]

Tamar,

Thanks for your reply. Actually, the fact that you don't have any "wisdom" is itself wisdom. If you have said the offending code was there for a good reason and I shouldn't mess around with it, well that would really have discouraged me.

I'll take your advice and drop Cathy a note. I also thought of contacting Colin Nicholls - I think it was he who wrote preview app (not sure about that).

One small benefit of this experience is that it encouraged me to delve deeping into the preview class, and to make a few other changes, albeit mainly cosmetic. I'll certainly head over to VFPX to see if I can contribute any of this.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business