End user editable reports in runtime

[popellis]

I understand that version 9 runtimes are the runtime plus version where end users can edit reports. Does anyone know of any documentation on how this is done?

[Stan Mathews]

Re: End user editable reports in runtime

I found a link to the runtime plus documentation in this thread. It is not really a zip file so if you download it, remove the .zip extension. It is a pdf file.

[DaveM]

Re: End user editable reports in runtime

Mark,

Word of caution. Please take as a friend to a friend.

several years ago we offered something similar with a clipper app. It worked well, but the support was never ending. They wanted more than was offered, made horrible mistakes, called with no app problems, couldn't understand why a report took 3 pages to print, and on and on. If you are using inhouse, maybe.

Most of us subscribe to the KISS philosophy.

[popellis]

Re: End user editable reports in runtime

Thanks Dave

I respect your opinion. I guess what I was trying to accomplish is a way of changing just the header information on a report. The reports are actually a form to send to a municipality. There are more than 1 municipality, and as governing bodies they have a need to change there form even slightly like change there fax number, or add it to the form. Then they get bent out of shape if you don't use that form. Anyway I will have to look into another way of handling this problem.

[Stan Mathews]

Re: End user editable reports in runtime

There are more than 1 municipality, and as governing bodies they have a need to change there form even slightly like change there fax number, or add it to the form.

As for the changing of things like a fax number, attention to, etc, give the users a place such as a table to store and edit these things. The report is then set to reference those fields.

Seems like this sort of thing has been discussed several times on the board. Might try a search.

[DaveM]

Re: End user editable reports in runtime

Mark,

It is not unusual for an app to have a main or dummy table where the name address phone fax fields are stored. If you use this idea and a form that they cannot add a new recored to, but can change the data, you have a source to get what you need. You can then use a lookup in layouts to make the data appear as needed. Other ways would be to capture that data in global variables at the start of the app so they are always available. Then just paste the variable on the layout.

[popellis]

Re: End user editable reports in runtime

I like the idea of a table with just the address information then you would create a set just for the report where the report header table and other information would be gathered to create the report.

[Stan Mathews]

Re: End user editable reports in runtime

I like the idea of a table with just the address information then you would create a set just for the report where the report header table and other information would be gathered to create the report.

A set for the report is not a bad idea but really unnecessary if you just create variables which you populate with the table fields that you have in the child table. The report can see those variables if you dim them properly.

[MikeC]

Re: End user editable reports in runtime

Mark,
I use something similar to what DaveM mentioned. I have a preferences table (pref) that users can open a form to change values in. Among many other things it has the company name, address, city, state, phone, fax etc. ...all of which can be changed. I then have my autoexec script load these values into a global character variable which is used primarily for a header for reports. Below is how I have it set up in the autoexec.

dim global t as p
dim global gvBusiness as C

t=table.open("pref")
gvBusiness=if(isnotblank("t.P_Business"),alltrim(t.P_Business),"")+if(isnotblank("t.P_Address"),", "+alltrim(t.P_Address),"")+if(isnotblank("t.P_City"),", "+alltrim(t.P_City),"")+if(isnotblank("t.P_State"),", "+alltrim(t.P_State),"")+if(isnotblank("t.P_Zip"),", "+alltrim(t.P_Zip),"")+if(isnotblank("t.P_Phone"),", Phone: "+alltrim(t.P_Phone),"")+if(isnotblank("t.P_Fax"),", Fax: "+alltrim(t.P_Fax),"")+if(isnotblank("t.P_Email"),", "+alltrim(t.P_Email),"")

t.close()

The way I have it, if any of the fields are blank they are simply not used.




EDIT:
But if these are going to be changed on a regualr basis then would opt for the report just referencing fields that personally I would have as part of the report selection process. Soooo many ways!! :)