Conditional Layout?

[Mark L]

I have an application that prints a rather large report. The customer is insisting that they have the option to print some portions, but not others. Does anyone have some insight on how this could be done?

Example:

Report could contain the following topics:

Topic A

Topic B

Topic C

Topic D

Topic E

Topic F

Topic G

Mind you, I jump through a number of hoops to create some of those topics – they are not just straight print offs of fields.

Goal: User goes to a screen checks off that they want Topics B, D, E and G. So only those should print off in the report.

(Weak) Brainstorms I've had about this include - making all the portions of the report separate layouts and then using a flag field to indicate to a script as whether to print or not. But this make for a messy report with lots of blanks. And some of the current report logic probably couldn't stand to be broken up.

HELP!

-Mark

[Sanjai]

Hi Mark,

There is not an easy and intelligent solution to this from developers point. I was asked a similar type of question and I insisted that we cannot give users a choice and we need specific requirements. I would suggest if you still want to do this then put the topics in a layout in table view and draw a red line(based on the boundaries you see in preview mode) telling the users that if they don't want any column then put those columns outside this line and they will not print. This way they can get a choice to rearrange topics (whether they want topicA before TopicB or TopicC before TopicA), eliminate topics, resize the width of columns, sort columns etc. This may not work if you want to show the report with summarized columns or if you want any extra formatting.

You need to make sure that the field names should be same as what they want as column heading and how the user will come out of table view mode because I tried keeping buttons in layout mode but they are inivisible in table view.

[Mark L]

Sanjai-

I know this is a difficult circumstance for FM - and thanks for your suggestions.

I need something that is more "automatic" - here is a sketch of an idea - what do you think?

1) Create table to hold all the fields that could be on the reports. Make them global fields - so I don't necessarily need a relationship with any particular table to access/view them. Also make fields that will be "switches" for different "Topics" of the report.

2) Create a report layout with the global fields that uses Merge Fields and the "Sliding" options set to move things up and over if they are blank.

3) Create a script that will move the necessary values into the global fields - based on "switches" toggled by the user before the report is run. Blanks/empty values get moved to the fields in the sections not selected.

Does this have any hope of working?

Sanjai and everybody else - what else can be done?

Thanks,

Mark

[VICH]

i personaly don' like your method because i wouldn't give my users the rightst to layout mode..that could be very dangerous even if their intents are not...

there is a not so easy but intellegent way to do this from a developers point and its performing a search on the wanted topics i haven't thought a complete script..and don't have time to becasue i am working on my own stuff but i can get you started....have you check screen and then a script that if topic is checked it includes in in the search and do the search with the "or" command that will allow you to find topic a "or" topic b "or" topic d

i get off work early today maybe when i go home i can come up with an actual script you can use

it takes some thought and trial and error but you should be able to get it

[Ender]

Hi Mark,

There is a handy technique using GetField() to dynamically show fields, even in a report format. Check out the attached demo (it also shows a dynamic portal using the same idea.)

This technique gives your users control of what fields they wish to see on the report, and how they want the report summarized. Each field they wish to see is a separate column in the report.

DynamicReport.fp7.zip

Edited September 13, 2005 by Guest

[Ender]

Mark - having re-read your original post, I'm wondering just how much info is in each Topic? Are they just a few words, a couple paragaphs, or are there many fields for each Topic? This might change how to go about this.

[Sanjai]

Mark, in the second solution of yours, how would you import multiple records in the global fields. Instead if you create a separate database with text fields that could be a solution but it will be a single user solution.

I would like to have a look at Ender's file and see how I can use them. I have version 7 in my home computer and would give it a try.

[SteveB]

Another idea: version 8 includes the abilty to save a report in PDF format, and automatically open Reader. Then the user can print whatever pages he chooses to, and you don't have to jump thru hoops.

Steve

[Mark L]

Ender and everyone else trying to help me out,

Thanks for posting the demo. I'm starting to study it and try to understand how I might apply it.

In answer to your previous question, the volume of the reports can be great, but it's because there is a lot of text in any one given field.

Each Topic of the report probably has no more than a 7 or 8 fields PER TOPIC (with about 8 Topics in all)- but some of the field contents range from a paragraph to a couple pages of text in each field. Remember too, the origin of each Topic can be from different, but related sources.

To help you visualize this better, here is a completely fictitious example, I’m making up as I’m typing: It would be an app for Publishers to look up book details. A full report would have all of the items below – but the user has the option to check which Topics they’d like to print (each hyphen is another Topic:)

- Detail about the Book (From Book table) – Title, ISBN, Author’s Name, Publication Date, Publisher, Formats (hardcover, softcover etc,) Summary of Book (could be a paragraph to two printed pages,)

- Detail about the Author (From Author table) – Author’s Name, Birth Date, Birth City/Country, Author’s Bio (could be a paragraph or a couple of printed pages)

- Reviews of Book (From Reviews table) – Reviewer’s Name, Date of Review, Publication, Review (from a paragraph to a single page in length)

- Listing of Other books by Author (From Book table also) Title, Publication Date, Publisher

- Detail about time period book was written (From HistorybyDecade table) (Single field) HistoryofPeriod (A paragraph to two pages long.)

- List of Related Authors (from Author table which has link of related Author names) – Author Name

- List of Related Books (based on Related Authors above) – Title, Publication Date, Publisher

Like I said, this is an ad hoc, fictitious example, attempting to give you a sense of what I’m trying to do.

Does that help flesh out what I’m trying to do?

Thanks so much,

Mark

[Mark L]

Sanjai-

You have a point there on the globals.

-Mark

[comment]

According to your description, these would have to be separate reports, each with its own layout and script. Each would either have to be printed in turn, or you would have to assemble them piece-meal into a global text field.

A simple way would be to let the user check the reports he wants in a global checkbox, then run a master script that, based on what the user requested, either calls or not sub-scripts for each report.

[Mark L]

comment-

If you look at my original posting on this top - the multiple layouts was one of my brainstorms - thanks for confirming it. I was hoping to avoid it - but it may just be what I'll have to do for the time being.

Thanks,

Mark

[Mark L]

comment-

A second thought - What would it take to get the different pieces into a global field of some sort? Is this at all possible?

Thanks again,

Mark

[comment]

It is possible. It would take a script that does something like:

clear the global field

go to related records in Table A (or perform find)

set the global field to FieldName1 & tab & FieldName2 & tab & ...

loop between records:

set the global field to global field & ¶ & Field1 & tab & Field2 & tab & ...

end loop

go to related records in Table B

...

---

IMHO, it's much easier just to let the script queue the various reports at the printer. You get much better control of the layout of each section.

Edited September 14, 2005 by Guest

[Mark L]

comment-

OK - that makes some sense to me. I guess I have to go experiment now. I'll try to post which way I go with this here when I make the final decision.

Thanks so much,

Mark