Making fields disappear when empty? Possible?

[geraldh]

Hello,

I am trying to build a layout for printing a pdf document.

I have built a table that have many fields to cover almost every stituation that might arise.

When I print this, I want to find a way to make the empty fields (and the accompany field name) disappear so that blank spaces and field names with no accompany data do not clutter up the lay out.

I've tried conditional formatting to make the field name go blank when its accompnay field is blank.

I've done as much sliding up as I can to minimize the field size.

But I have these annoying blank spaces are still there.

If anyone might have any ideas, please let me know.

Thank you

[bcooney]

Could you provide more details about your table and the purpose of the PDF? Perhaps, your data structure is not setup in the best way possible (in that you have unfilled fields).

Methods to "hide" include:

$vars

sliding

tab panels

branching to layouts based on conditions

large text sizes (conditional formatting)

[geraldh]

bcooney,

Thank you for your response.

It is a planning document that will provide instructions for event staff for the planned event.

Currently I have all the fields in one table, and each record (of one event) will have all these fields.

Right now there are about 200 fields (!).

To minimize the bloating with empty fields when printing, I have separated these fields into different duties (Food and Beverage; Building Services; etc). Each of these will have their own layout, and will be printed separately.

Depending on the event, there will be fields that may not be applicable for some events.

I have also considered populating the empty field with "Not Applicable" to give it some presence rather than an blank space.

Early in the planning of this database, I experimented with a layout based on a Planning Document table with a portal based on "Planning Lines" (much like Invoice Lines or Estimate Lines). Lines/Records would be added when needed.

But I found that the work to set up each field and inputting the field names for each event would mean considerable work for the user. Also I think that formatting this kind of setup also has it problems.

But if I am misled, please let me know.

(the other problem, is that I've already done considerable work with my current strategy...)

I hope this helps explaining further my situation.

Thank you again.

[comment]

Early in the planning of this database, I experimented with a layout based on a Planning Document table with a portal based on "Planning Lines" (much like Invoice Lines or Estimate Lines). Lines/Records would be added when needed.

I believe that's a worthy effort - and not only for the current issue. Not sure what issues you ran into with it.

[geraldh]

I believe that's a worthy effort - and not only for the current issue. Not sure what issues you ran into with it.

Comment,

The main issue with this approach was trying design a layout that would present the data efficiently and consistently.

Because some fields will have lengthy instructions for the event staff, some would have one or two words, and some with one or two sentences, some would require an image, some with hyperlinks, it was hard to figure out how to set up a layout that would conveniently accomodate the different field sizes and field types.

When trying this approach, I tried a layout in the List View, much like an invoice or estimate would be presented; but then I realized that the size of the Body would have to be fixed to one height. Thus, not giving me the flexibility to display different sized fields and for the field to shrink/expand according to the amount of data inside.

I might have not tried hard enough to find another way to see this approach to the end; if you have any ideas, I would love to hear them. My deadline is approaching and I might have to finish with my current approach, but if they keep me around here, I might

revamp it at a later date.

Thank you...

[comment]

How many questions do you want to present to the user at the same time? Or, in other words, would it be possible to have the user go from screen to screen - each screen being a single question?

[geraldh]

I thought about that too.

Right now I have about 200 possible fields that need to be considered.

All of them could be filled in the most amibitious of events.

The other things is that the user will probably have to be able to scan the questions/field before and after to answer the current one.

Currently I have made my current approach manageable up the fields into the different departamental duties.

Just when it is finally printed, I wish to make it clean as possible so that no gaps are evident. But I might have to settle for some...

Just in case this helps. This document is filled by the Event Coordinator, not by the Client.

[comment]

The problem with your current approach is that while you can conditionally format the field names, it won't make them empty. In order for other names to slide up, you will need to calculate the field names - adding some 200 calculation fields to your table...

There is little doubt in my mind that structurally, each question should be a record in a Questions table and each answer should be a record in an Answers table - see:

http://fmforums.com/forum/topic/45972-another-survey-question/

That leaves the challenge of building the user-interface. However, keep in mind that you can use filtered portals to present any individual question (or group of questions) in its own formatting.

[geraldh]

Thank you comment for your response.

The final document has to be a pdf printed for the event staff. This is my challenge, not really in the user interface.

I wish the pdf to be as compact as possible, but also allowing for fields that may have 20 lines of instructions, and some with only one word instructions.

I can't seem to think of a way that a portal can be flexible enough to shrink and expand according to the size of data in each field.

I hope I am understanding your suggestions correctly?

Thank you.

[comment]

Perhaps I am misunderstanding your situation: I thought that when printing out the PDF, you no longer need to format each answer individually (other than the length of the field). By "format each answer individually", I mean that some questions could be presented as checkboxes or radio buttons set, others as popup menus and some as edit boxes.

[john renfrew]

You might have to think right outside the box here

Bruce Robertson has showed how the virtual list technique might be used to cope with breaking over pages when the text might be of variable length.

The other option is to build the framework document with iText which again would then cope with the large variation in field content lengths

[voltron2112]

Maybe I'm over simplifying things and it's hard to tell without a preview of your PDF, but what about just a big text field with a bunch of merge variables or something a little more complex with a script that loops through a layout to each field and if it has something in it then set a var called $instructions and stores title and info as ($instuctions & " food and beverages: " & field::info )

If empty skip

Use some text formatting functions while gathering it to make the text look nice then set your message field with $instructions

Since its just a PDF it really doesn't need the actual fields or anything all that complex in my opinion, well good luck.