Detecting and reporting errors in the layout of a report

[AndrewMozley]

An application allows the user to modify a report layout (within reason). The user may provide his own (.frx/frt) report layout, or he may modify the report layout, via the MODIFY REPORT command.

If there are errors in the report layout, they need to be reported back to the user. To that end, part of the sequence of instructions is - broadly --

Variable Thisform.sReport contains the name of the report being modified.

     TRY
      MODIFY REPORT .sReport
      CATCH TO loError
         . . . .
     ENDTRY

An error is then created in the report layout: perhaps specifying that the value of a field is ABCD rather than “ABCD”.

When this code is running in the development environment, and the user asks for ‘Report Preview’ the error is trapped in the CATCH clause, and (among other things) the value of loError.message is “Variable ‘ABCD’ is not found”. This is helpful.

However, if the same report and preview is being run as part of an .exe file, not in the development environment, the error is detected, but the value of loError.message is “Syntax error”. Still a true message, but not so helpful.

I would like to know why this is. The same difference between messages happens if the error is trapped by the routine called from an ON ERROR statement. Is there a way of ensuring that the more descriptive error message can be displayed when the layout error is detected when running the .exe program?

Thanks. Andrew

 

[Olaf Doschke]

I tried that and even in the IDE got mixed results at best. Nothing working stable/reliable so I spare the details.

I see the idea, and indeed, it would be a great thing to have perhaps even user-friendlier than normal error messages about non-working changes added to the possibility of protected mode report designing. So I can only point out the obvious things, which besides the protected mode is the ability to create your own report builder app.

On a more global perspective: It's obviously much easier when customers/employees/colleagues have the VFP IDE and can simply design reports.

If you want to go in the direction of giving them this ability without having the IDE, the runtime capabilities of MODIFY REPORT are too weak, I fear. and creating a new full-blown report builder with any features you like.

The best working scenario for me was compiling an EXE with a MODIFY REPORT without general ON ERROR handler, without TRY.CATCH handling and without protection, that gave about the same experience as the IDE, although then also the same system error messages, that might be too technical and misleading, sometimes. Just as "Variable" is misleading here (not the only instance of that) when an expression in a report is rarely about a variable at all, but about table fields.

But I, for example, never got to the point of only having a syntax error.

You also can't squeeze something out of COMPILE REPORT, which actually also is available at runtime. Unfortunately, any expression not valid in the context of modification will not cause an error, there always is the chance you have set procedure, declared variables, tables, and cursors that have a name now unknown. So the preview is the only context, in which such errors are revealed when you yourself also make the restriction that a report has to work self-contained without any preparation of data before it's previewed/printed.

So also your idea of using the preview as a test run finding errors is alright backed with a policy of self-contained reports.

In essence, my 2 cents about this is a simple separate EXE just doing MODIFY REPORT, and establishing no specific error handler will at least reliable display system errors as you also get them in the IDE. I'd look forward to achieving better results this way. It's clear the official way of creating your own builder is the reportbuilder.app you can replace with your own not only at runtime, but Foxypreviewer may also be a template or learning material for how that's done, though in itself it only changes the _reportpreview and _reportoutput system variables and leaves the report builder untouched.

That needs much more effort to change for your needs. The only good news is, that the source code of the native VFP9 report apps including the reportbuiolder.app is available with XSource, the sources of many tools of the IDE. If you don't have that in the Tools directory of the VFP HOME() directory, xsource is still available as an official download:

https://www.microsoft.com/en-us/download/details.aspx?id=2309,

besides the Github home of such components:

https://github.com/VFPX/XSource

Establishing specific error handling within the scope of the reportbuilder.app might get better results than just the global error handler and last not least, no surprise for this situation of indirectly DOing an APP, the reportbuilder.app, wrapped in TRY..CATCH that structured error handling works less good.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[GriffMG]

For my own pennyworth, I don't let end users create their own reports at all. If they want a change, or a new report, they can ask for it.

Most take less than an hour including delivery, so I don't charge, and if they do take longer than that, I offer a capped price and live with the consequences.

Sometimes, not often, if the user has had a stroke of genius and it is going to be a day or two I'll take that on the chin and let all users have it for free.

I have access to components within my systems that they do not, and I know the data structures better than anyone and that means I can do in a short time what they
cannot, perhaps ever, complete accurately. Also I can add fields and tables that the end users cannot.

I guess a customer could use Crystal Reports (other report writers do also exist), but I am not aware of anyone doing that.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[AndrewMozley]

Thanks Olaf. I really appreciate the time you have spent investigating this; Also, thank you Griff.

In fact the modifications to the report layout are usually done by me, the developer, as is your practice, Griff. I noticed the difference when (by mistake) I installed an old report layout (.frx,frt) with a later version of the accounting package.

The installed software on a customer’s site includes, as well as the .exe file, several .dll files, and also 3 files : ReportBuilder.app, ReportOutput.app, ReportPreview.app. I wonder whether there is some difference in capabilities between these apps and the capabilities of vfp9.exe when I am developing programs . . .

Or perhaps I need to include more files in the installation on the customer’s site.

It’s not a major problem!

Best wishes. Andrew.

 

[Mike Lewis]

I partly agree with Griff. I never give end-users access to the VFP report writer, basically because I don't consider it an end-user tool. I also worry that end-users won't understand the subtleties of the design of the database.

But I don't agree that if users want a new report they only have to ask for it. Once I have developed an application and handed it over to the client, I don't want them to be locked into using my services. And I don't want to have to be available at short notice to deal with this type of request.

My solution is to advise the client to purchase a reporting tool specifically aimed at end users. That usually means either ReportSmith or Crystal Reports (but there are others, of course). If necessary, I give them some training in the chosen product.

And, importantly, I give them a way of accessing a subset of the data in a way that it makes sense to them. Typically that means creating a separate DBC, containing local views which expose just the data the users need, often with the data denormalised, or with summary data rather than details. A sort of poor man's data warehouse.

I accept that this approach won't suit all developers. I don't know anything about Andrew's clients. It could be that the VFP report writer is the correct approach for them.

(EDIT: I wrote this before I saw Andrew's latest post.)

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The three apps you found are part of the VFP runtime, they are just the standard capabilities for report modification (reportbuilder.app), report preview (reportpreview.app) and report printing (reportoutput.app). That's not new, that's the way the report engine is working in VFP9. Previous VFP versions have the standard report engine for all 3 functionalities within their vfpNr.dll runtime DLL. And indeed, the old report mode you can use with SET REPORTBEHAVIOR 80 is still in the vfp9r.dll main Foxpro runtime DLL, so you only need the apps when running reports in the new enginebehavior 90.

There are a few versions of them, yes, for the different service pack levels of VFP. But I doubt you find differences in their error behavior. This is very fundamental an ON ERROR handler always acts and I don't see the sources of any report app changing ON ERROR handling. In short, aside of TRY..CATCH usage within the report apps I don't see a temporary redirection of error handling that hinders your general handler to get triggered.

But as said the sources are available and that might be an option to make this happen. Just from within, not from outside.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name