Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Trouble printing multi-page report in VFP 5.0
Message
From
03/03/1999 18:48:35
 
 
To
03/03/1999 18:42:46
Michael Klein
Alexander Stevens Edp Assoc., Inc.
Great Neck, New York, United States
General information
Forum:
Visual FoxPro
Category:
Reports & Report designer
Miscellaneous
Thread ID:
00193726
Message ID:
00193845
Views:
11
>>>>>>>Hi. I'm relatively new to VFP and its Report Designer. I am working on a system to print "Watch specifications". Since watches are complicated things, the specifications must be broken down into various sub-sections, e.g., Case, Bracelet, Movement, etc., sometimes with 2 or 3 sections printed on a page. My problem is that there is too much data to fit on one page. What can I do to include all of the information necessary, but tell the VFP Report Designer to "page break" at specific lines? Also, where do I put my information, i.e., in the "Detail" band or do I need separate "Group" bands for each section? Any help would be greatly appreciated.
>>>>>>>
>>>>>>>Thanks in advance.
>>>>>>
>>>>>>You may group your report by WatchId and select 'start each group with new page', so you will have group footer for each watch and other info will be in Detail band.
>>>>>
>>>>>Edward, thanks for your quick response. If I do that, am I supposed to put each section (Case, Bracelet, etc.) in a separate group? If so, what do I use for the "Group Expression" for the other groups after I've used WatchID for the first one?
>>>>
>>>>You may do this, grouping by 2 levels: first- WatchId, second- ItemId (case, bracelet, etc.), but I'm not sure that it's what you want to achieve. It depends on required report layout. My assumption that you may just have several lines in Detail Band:
>>>>Group Header
>>>>Case ....
>>>>Bracelet ...
>>>>Something Else ....
>>>>Group Footer
>>>>
>>>>All this also depends on data structure.
>>>
>>>OK. Here's the nitty, gritty. The data is all stored within one file since data normalization is unnecessary due to the uniqueness of each watch. The Specification Printout, needed for only one watch at a time, has the following layout, where some fields in each section are variable length memos meaning the number of lines below can vary:
>>>
>>>Summary:
>>>Line 1... line 16
>>>
>>>Case:
>>>Line 1... line 38
>>>
>>>Bracelet:
>>>Line 1... line 25
>>>
>>>Movement:
>>>Line 1... line 43
>>>
>>>Dial:
>>>Line 1... line 33
>>
>>Do these parts go sequentally, e.g. Case lines then Bracelet lines etc. If it's so the simplified report form layout is gouping by watch id/name with Summary in Group Header, and 4 fields (each one taking whole row) in detail band. Each detail field will be based on UDF, e.g. getcase(), getbracelet() etc. The UDFs will essentially concatenate fields related to Case,Bracelet etc. Each field should be marked as 'Stretch with Overflow' and 'Fix on the Bottom of Band'.
>
>Yes, the parts go sequentially, but each section is composed of multiple fields. For example, the case section has about 47 different fields, each of which must print in that section, some of which are memo fields. Sometimes 3 fields can report on a report line, sometimes only 1 or 2. You can think of this as a single column report which must include 150 fields, one per line, over 3 or 4 physical pages. Is there a way to handle this with the Report Designer or should I abandon the Report Writer entirely and hand code this thing? My only problem in doing that would be in using some of the nice grids the Report Designer provides for prettying up output.

As I said, you still can handle it concatenating fields. For example, you want to show Field1+Field2 and then on next line Field3. So your UDF will look like:
Function GetSomething
Return "Line1: "+alltrim(Field1)+space(1)+alltrim(Field2)+chr(13)+"Line2: "+alltrim(Field3)

Obviously, it does not look nice and should be used only as in your case when detail band cannot accomodate all fields. So, you may put there as many fields as you can and concatenate all extra fields/lines.
Edward Pikman
Independent Consultant
Previous
Reply
Map
View

Click here to load this message in the networking platform