How do I provide "modify reports" to end users? (step-by-step)

[stanlyn]

Hi, I need to include the "modify reports" functionality in my app and have search and have found little to add this.

1. What code do I put in the command button's click event that calls the modify report command.

2. I used the command "modify report '.\reports.myreport.frx'" and it appears to have loaded some of the elements into the small 480x640 top level (2) form. This app contains a main startup prg and the ui form, plus some reports. No menus, or vfp desktop.

3. Do I need to create a new window or large form to contain the designer?

4. Any ideas, whitepapers, suggestions articles that covers this in-depth is greatly appreciated...

Thanks, Stanley

 

[Olaf Doschke]

The help topic on MODIFY REPORT covers the basics, see PROTECTED clause and WINDOW clause(s).

Actually you answered 1) with 2) yourself, besides PROTECTED the only thing to add is the functionality must be deployed via ReportBuilder.App

3. see the IN WINDOW clause, also you're better off with IN SCREEN, which is the default, if the _screen is visible.

4. The "See Also" section of the help topic on MODIFY REPORT also links to the start page of a rather elaborate help chapter "Working with Reports".

If that's not enough, perhaps check out Whats New In 9 from Hentzenwerke.

Bye, Olaf.

 

[Dan Freeman]

This is one of the very few places where one must resort to using the deprecated DEFINE WINDOW command. The report writer must "live" inside something, and it will only live in a window created by DEFINE WINDOW if the _Screen isn't available.

DEFINE WINDOW mywindow AT 0,0 to Srows(),Scols() In Desktop
Activate Window myWindow
Modify Report (whatever) In Window myWindow

If you add other clauses to DEFINE WINDOW (Float, Grow, Zoom, Closable, etc.) you can then use

Modify Report (whatever) Window myWindow In Window myWindow

We used to give these instructions for BROWSE WINDOW ... IN WINDOW. The WINDOW clause tells the new window (browse or report) to take on the attributes of the mothership window. The IN WINDOW clause tells the new window (browse or report) to be "in" the mothership window.

It's one of the least clear command syntax pairings they ever gave us, and it's harder to explain than it is to do. But it's completely clear once you've tried every possible combination. LOL

 

[stanlyn]

I've got it working now that I show the screen and immediately hide it afterwards, as in,

Show Window Screen
Modify Report (lcReportName)
Hide Window Screen

Thanks so much!
Stanley

 

[Olaf Doschke]

Actually something like this also works:

o = createobject("form")
o.name = "test"
MODIFY REPORT your.frx IN test
o.Show()

The look is a window inside a window, but you might define a form with borderstyle 0 and some other settings making it as lightweight as a window created by DEFINE WINDOW / SHOW WINDOW. So if you want, you can do without any legacy code. The advantage is questionable.

Bye, Olaf.

 

[Dan Freeman]

The result is as questionable as the advantage since it isn't documented.

They left a lot up in the air with DEFINE WINDOW and forms, and the NAME clause on various commands, and how that clause turns a "Window" into a "Form" but not always all the way, and, and, and....

The old doesn't always overlap with the new, except when it does, or doesn't, and then not always. <crazy cackle>

 

[JRB-Bldr]

The big problem of providing MODIFY REPORTS to end users is that only VERY INFORMED users are capable of using it without messing things up.

That is why I have been extremely cautious when clients ask for Report Builders in their applications.

If a typical user should go in and start messing with fields, etc expecting to get the results they want without understanding what fields are available from which tables, how multiple available tables might be related and how table fields and memory variables are directly related to the report output, etc. they can cause more havoc than good.

Sure changing the report text somewhat or making small adjustments to positioning - fine. But trying to create new Report Forms and getting them implemented into an existing application or attempting to make dramatic changes to existing report forms should be well beyond most user's realistic expectation.

Regardless, I hope you get what you need.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Just to add to JRB-Bldr's comments ....

There is a also a security implication in giving users access to the report designer. It allows users to access any informaion in your database, even if you have taken steps to restrict access within your application. A malicious user can even overwrite records or delete entire tables.

Stanley, I'm not suggesting that your own users are that untrustworthy. But it is a point that we all need to keep in mind when users ask for access to the report designer.

I would prefer to steer them towards a third-party product, such as Crystal Reports, R&R or Stonefield Query, all of which work well with VFP data and are much more secure.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

Users have a right to access their own data. They own it. In a vertical market application you almost have to give access to reports.

What we always found is that users were so intimidated by the RW they'd pay us by the hour to do report customizations.

If there is a security constraint, you'll have that built into the application and what the individual user can access.

 

[JRB-Bldr]

Dan - Users have a right to access their own data.

You are correct, BUT in many cases not ALL users should have access to ALL of their application's data.

For example a company's Accounting dept (even in small companies) typically does not want ALL users to have access to their application's data to see other employee's earnings, etc. and the Upper Management often does not always want ALL users to have access to some of their specialized data.

And no one in the company wants their own users to bring everything crashing down around their ears through a user's incompetent messing with data tables and/or Report Forms.

So like Mike suggests above - Allowing access any information in your database, even if you have taken steps to restrict access within your application is a very RISKY proposition and should not be granted lightly.

And, also like Mike suggests above, a malicious employee could really bring things to a crashing halt quickly or just mess up things pretty royally.

Intimidation is a good thing to prevent 'snoopers' from tip-toeing through the data tables, but Curiosity or Revenge are sometimes an even more powerful forces.

Stanley - just be aware of the possible risks and complications involved with something that seems totally 'innocent' like allowing the users the ability to modify the VFP Report Forms.

Good Luck,
JRB-Bldr

 

[Dan Freeman]

Sorry, but I've never run into situations where salary data was visible to all employees. I probably wouldn't want to work there.

If a user has access to the data on the network, they have access to ALL of the data. They can use MS Access or Excel and prowl around at will. You can waste a lot of time building in ways to keep them out of parts of the data, but it's fruitless.

And I fail to see how reports can be destructive. The reports they create may have wrong results, but yours might too. ;-)

 

[stanlyn]

I know and understand the risks of modi reports in an app. In all the apps I've built in the past, I've never added this functionality, however in my current app, I really need an easy way for the users to move objects around so they fit pre-printed forms and its important that they fit the forms as they are marriage licenses. And to complicate things there is are hundreds of different printers that could possible be printing these forms.

I've also run into problems in the past where part of the margins are missing, and it would be such a simple fix if I could quickly adjust the positions on some of the objects.

 

[Dan Freeman]

You probably need this book more than you can appreciate how much you need it:

http://www.hentzenwerke.com/catalog/vfprwext.htm

Also, use Google to find all of the article about the report writer written by Doug Hennig, Cathy Pountney, and Lisa Nicholls.

The information is out there.

 

[TamarGranor]

If you're using VFP 9 SP2 (and I hope you are for this), you'll also want

http://www.hentzenwerke.com/catalog/makingsos.htm,

which covers the changes to the Report Designer in detail. You can actually protect some items from being changed by end-users.

Tamar

 

[stanlyn]

Thanks Dan and Tamor,

I did get the modi reports into the hands of my users. I also have both books from Whil...

Thanks, Stanley