Printing reports, designing at run-time 2

[AndrewMozley]

I have a form class, anmprint which prints a report based on a cursor and a .frx file which the user supplies.

I offer the user a "Development" mode, which lets the user modify the report before printing. So I execute these two lines of code in my anmprint class

MODIFY REPORT MyReport
REPORT FORM MyReport TO PRINTER PROMPT NOCONSOLE

So the user sees the layout of the report, which he may modify. He may also right-click and preview the report. When he completes or abandons this modification, the 2nd line is executed: the standard printer dialogue appears, and he gets the report.

I notice however that I get a warning message while modifying the report, if I right-click and select 'Preview report'

SET REPORTBEHAVIOR is set to 80. Draft mode preview may not show dynamic behavior

I have tried to suppress this by including this command :

SET REPORTBEHAVIOR 90

This does indeed suppress the warning message. However if I right-click on the report design, and select Print preview to see a sample, it does not work as it used to. A preview is indeed displayed on screen, but I am then no longer in the report designer. Control passes to my next (REPORT FORM) instruction. I wanted to remain in the report designer, and this is what used to happen.

Is there a way that, with REPORTBEHAVIOR SET to 90, I can let the user preview a report and modify it until he is satisfied, and then save it?

Thanks. Andrew

 

[Olaf Doschke]

I don't know for sure, as I don't give users this option, but we have the PROTECTED option now, to protect some portions.
MODIFY REPORT ... PROTECTED

Also you need to redistribute the REPORTBUILDER.APP on top of the REPORTPREVIEW.APP and REPORTOUTPUT.APP to run reports in 90 mode.

If your reports are not using any 90 features you better keep it at REORTBEHAVIOR 80, though. Many reports don't work in 90 mode because GDI+ renders text slightly wider, which can often lead to overflow,, resizing and therefore glitched looks of the report output.

I would rather live with the warning message or make he report editing the exception, not the rule, and use foxypreviewer.

Bye, Olaf.

 

[Mike Lewis]

Andrew, I'm sorry I can't answer your question.

Personally, I would never give users the ability to modify a report in a distributed app, for two reasons:

- The report designer interface is baffling to most end-users, unless you give them special training or a highly-detailed tutorial. Even if you train existing users, the same problem will arise with new users in the future.

- It is too easy for a user to mess up your data unless you take care to prevent it. If you don't, and if the user is at all knowledgeable, they could deliberately screw up the database. If they are not knowledgeable, they could still screw up the database by accident.

There are alternative approaches. If you want to allow users to use, say, their own invoice layout, consider providing four or five packaged layouts for them to choose from. Alternatively, allow the user to make limited changes to an existing report layout, but give them your own form for doing so.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AndrewMozley]

Thanks Mike

I take your point about needing to be careful about the changes that a user can make to the system. I restrict the facility to users logged in to my application with administrator rights, and that is usually myself, because I find it convenient to check out changes to (say) a sales invoice using live data.

For what it is worth, the same approach is adopted by a fairly widely used commercial accounting package, Pegasus OPERA.

Andrew

 

[vgulielmus]

I tried a solution based on :
- WINDOW and SAVE parameters of MODIFY REPORT command
- a modal form used in the WINDOW parameter of MODIFY REPORT command
- a timer for querying the existence of the Report Designer window
- a flag on the calling form with the associated assign method, which contains the code that normally follows the MODIFY REPORT command

PUBLIC ofrm
ofrm=CREATEOBJECT("MyForm")
ofrm.Show()

DEFINE CLASS MyForm as Form
	*** This is the calling form with at least three elements
	lFlag=.F. && become .T. when the report designer is closed
	ofrmrepo=.Null. && the modal form used in MODIFY REPORT ... WINDOW
	ADD OBJECT otim as timer WITH enabled=.F.,interval=50 && the timer which queries if the Report Designer was closed
	****
	ADD OBJECT cmd as commandbutton WITH caption="Modi repo"
	PROCEDURE Load
		LOCAL lni
		RAND(-1)
		CREATE CURSOR cc (nc I DEFAULT INT(1000000*RAND()))
		FOR lni=1 TO 10000
			APPEND BLANK
		NEXT
		GO top
		CREATE REPORT cc FROM cc
	ENDPROC

	PROCEDURE cmd.click
		****** 
		ThisForm.lFlag=.F.
		ThisForm.ofrmrepo=CREATEOBJECT("MyRepoForm")
		SET REPORTBEHAVIOR 90
		ThisForm.otim.enabled=.T.
		MODIFY REPORT cc WINDOW (ThisForm.ofrmrepo.Name) SAVE
		******
		** The code which normally follows is placed int the lFlag_assign method
		*****
	ENDPROC
	
	PROCEDURE lFlag_assign
		LPARAMETERS vnewval
		This.lFlag=m.vNewVal
		IF m.vNewVal
			ThisForm.otim.enabled=.F.
			*******
			**** This is the code that follows the MODIFY REPORT command
			******
			MESSAGEBOX("This is the code that follows the MODIFY REPORT command")
		ENDIF
	ENDPROC
	
	PROCEDURE otim.timer
		ThisForm.lFlag=!WEXIST(ThisForm.ofrmrepo.caption) 
	ENDPROC
ENDDEFINE

DEFINE CLASS MyRepoForm as Form
	***** The modal form used in MODIFY REPORT ... WINDOW
	windowtype=1
	showwindow=1
	name=SYS(2015)
	caption=SYS(2015) &&"Report Designer"
ENDDEFINE

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[AndrewMozley]

Thanks Vilhelm

I have run your form and I believe that it is a way of getting round the problem (it may be a feature!) that with REPORTBEHAVIOR set to 90 the program continues execution.

I am inclined to stick with REPORTBEHAVIOR set to 80. However it is difficult to determine in what circumstances (when I Right-Click and ask for Report Preview) it gives the warning message about not reporting dynamic behaviour.

I would prefer not to have that message displayed, but it is not the end of the world!

Andrew

 

[vgulielmus]

My fault, I misunderstood you. Please excuse me.
I guess you are looking for the
DO (_REPORTBUILDER) WITH 4, iHandleMode
command
Help topic:
How to: Configure the Report Builder's Event Handling

Please try:

CLEAR ALL
CREATE CURSOR cc (nc I DEFAULT INT(1000000*RAND()))
APPEND BLANK
CREATE REPORT cc FROM cc
DO (_REPORTBUILDER) WITH 4, 4 && ignore all report builder events
MODIFY REPORT I:\Test\cc.FRX

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Dan Freeman]

Personally, I would never give users the ability to modify a report in a distributed app

Wimp.

It's kind of a core requirement for shrink-wrap apps, and some of us have been doing it since the FPD days.

You can obviate the "OHMYGODIRUINEDIT" support calls by building a dbf/fpt into the exe.

Create Table Reports (filename c(20), frt m, fpt m)

Store the report form itself in the memo field (in a project hook at build time, of course).

When a user freaks out about ruining a report, let them start over:

Use Reports
Locate for filename="whatever"
Copy Memo frx TO ForceExt("whatever","frx")
Copy Memo frt To ForceExt("whatever","frt")

Most users are more than happy to deal with the RW, and those that aren't are more than happy to pay your hourly rate for customizations.

 

[AndrewMozley]

Thanks Vilhelm

DO _REPORTBUILDER WITH 4,4 may well achieve the result. However it seems to close all tables, so the report does not show anything,

Is there a way of opening a cursor (or table) and then running MODIFY REPORT so that the message about REPORTBEHAVIOR and Draft mode does not show Dynamic behaviour is suppressed.

As mentioned, it is not a big thing, and I am sadly aware that bugs in VFP are no longer being fixed. I am sure that many of us would gladly pay for a revised version with some of the errors and inconveniences corrected!

Andrew

 

[vgulielmus]

it seems to close all tables, so the report does not show anything

On my PC, the demo I posted shows all the data : a single row because it's a single append, but I also tried with more appends and showed all the rows.


Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[vgulielmus]

I know this is an old thread, but I encounter the same request in another forum and I guess I found a solution.
1
DO (_reportbuilder)
Click on "Create copy"

https://www.dropbox.com/s/a68e61bzt8v7ceu/01.png?dl=0

2 (my copy is i:\reportbuilder.dbf)
USE i:\reportbuilder.dbf EXCLUSIVE
DELETE FOR hndl_class = 'PreviewFromDesignerHandler'
USE
(delete the event)

3
DO (_REPORTBUILDER) WITH 3, "i:\reportbuilder.dbf"
or
DO (_reportbuilder)
and click "Use alternative lookup table"

https://www.dropbox.com/s/4yu96tgigpftlpq/02.png?dl=0

4
USE myreport
MODI REPO myreport
Right click, Print preview

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[AndrewMozley]

Thank you Vilhelm; I have printed your suggestion and will check it out. Andrew