making position of flds in rpt variable 1

[johncook]

Can someone point me in the right direction on this:

I am printing a one page report. It will always be one page. I need several of the fields on the report to be positioned depending on system configuration.

Example: Client A uses form 123. When using form 123 the name should begin on row 3, column 10.
Example: Client B uses form 234. When using form 234 the name should begin on row 2, column 20.

My report expertise is very limited. Would it be a matter of setting the top and left properties for the name textbox, from the values in this clients' sysconfig.dbf or something like that? I may be asking for the impossible but it sure would beat creating a separate report for each client.

Thanks,
John

 

[fumbles]

Hi John -


If the report can "see" the form type ( global variable or control file setting ) use the PrintWhen dialog ie.

g_ccurrentform = "123"

or

sysconfig.FormUsed = "234"

Put both field locations on your report.

Steve

 

[Mike Gagnon]

johncook

You could use fumbles' suggestion, but having gone through the process, depending on how complex your report is, it might get a little confusing.
Although there is also a way to completely from scratch, you may find that the easiest solution will end up being creating separate reports.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[johncook]

Hi Steve,

If I understand correctly:

1. Place the textbox on the form twice even if they overlap each other a bit.

2. For the 1st textbox PrintWhen sysconfig.formnbr=123

3. For the 2nd textbox PrintWhen sysconfig.formnbr=234

If I understand correctly that would work but it doesn't allow unlimited settings. The more I think about it the more I realize I may have to manually code the report with @say commands and use the sysconfig.prnt_name_at_row and sysconfig.prnt_name_at_col to have complete flexibility. I'd probably be better off to create separate reports.

Anyway, just let me know if my thoughts make any sense and I will go from there.
Thanks,
John

 

[fumbles]

Hi John -

Trying to decide which road to take, that's why programmers make the "big money" . Do you have a feeling for how many different formats are involved? I would think that maintaining many different sets of @say output would be harder - especially for subsequent changes to the form.

Steve

 

[johncook]

Well Steve, I should have been more specific.

I am printing a check. I wanted to be able to finsh this BEFORE I know the exact check format the user will select.

In other words, the user may want to select a 3-up format where the check is printed on the first 1/3rd of the form and the other two thirds are the stub, etc
OR
the user may choose a format where the real check is in the middle of the page and the stub is above it and probably a copy of the check is below.

Either way, I was thinking, If I make all the positioning based on a table, I can code it now and just change the data to move the fields around on the form.

This is more important because of the time frame. I will just have to wait till the format is selected or create 3 different reports and use the appropriate one once the format is selected. I can probably pull that off. Thanks for the input,
John
P.S. As for the big money, that part remains to be seen

 

[acerrudo]

You can define a report with several similar fields below each other, like this ... (rows may overlap)

evaluate(chkdata1)
evaluate(chkdata2)
evaluate(chkdata3)
evaluate(chkdata4)
...
evaluate(chkdatan)


Then before calling this report, u must initialize all the variables from chckdata1 to chekdatan


DO CASE
CASE client = 1
chkdata1 = "space(80)+CHCK_DATE" && the space(80) is to adjust the column position
Chkdata2 = "space(10)+CHCK_FOR"
CHKDATA3 = "space(1)"
CHKDATA4 = "space(10)+CHCK_WORD"
(and so on up to cHKDATAn)
CASE client = 2
chkdata1 = "space(1)"
chkdata2 = "space(90)+CHCK_DATE"
Chkdata3 = "space(20)+CHCK_FOR"
CHKDATA4 = "space(1)"
CHKDATA5 = "space(15)+CHCK_WORD"
(and so on up to cHKDATAn)
CASE client = 3
chkdata1 = "space(1)"
chkdata2 = "space(1)"
chkdata3 = "space(1)"
chkdata4 = "space(100)+CHCK_DATE"
Chkdata5 = "space(5)+CHCK_FOR"
CHKDATA6 = "space(1)"
CHKDATA7 = "space(1)"
CHKDATA8 = "space(70)+CHCK_WORD"
(and so on up to cHKDATAn)
ENDCASE


THEN U run your report (the secret recipe is the evaluate function).

If you are more ambitious and want's a more flexible report, you may use a table and set the content of
the variable like a template :=)

GOOD LUCK,
Allan Cerrudo

 

[johncook]

Alan
That is probably more like what I really SHOULD do. Since my knowledge is so limited I am unsure if I will get that done by Friday with soooooo may other things to do.

Having said that I hope I can pull it off. I am in compromise mode at the moment. HAHA

Thanks all for the help.
John

 

[craigsboyd]

Johncook,

My question is, let's say you set this thing up for an infinite number of check forms, which it appears you are doing, you would have to have 100's if not 1000's of fields on your report given the proposed solution wouldn't you? I mean, is there a margin of error allowed or does the info have to print right on the check lines like it should? Also, how is the user going to select their preferences? If it is via a drop-down or something containing the form numbers then doesn't that mean you will need the specific format hard-coded anyways? Like in the above example where you code variable values in a Do Case statement? That seems to ruin the whole idea of this being dynamic. I think a seperate report for each check form is the way to go, unless I am missing something. In the long run you will complete your task faster and it will be more maintainable in the future. IMHO

Slighthaze = NULL

 

[Mike Gagnon]

johncook.

Here is another suggestion, we have a commercial software that we use to print check, and upon setup, the software requests the administator to either specify a generic check layout (pre-existing) or to design a custom one. And since MODIFY REPORT is distributable you can allow the software let any customer design one to suit their needs, that way you are no longer obligated to create either 1000 posibilities or a 1000 fields on one report.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[acerrudo]

Hey guys, chkdata1 are fixed variables. Using the method I suggested. Let us say I define 25 variables. Therefore I already have 25 rows for my check. And If I have 1000 records. I don't have to define 1000 variables for that.

Plus why will I allow myself be obligated to create 1000 possibilities. As I suggest to Johncook hea can make a module to allow the user to define a user-define template.

 

[Mike Gagnon]

acerrudo

. I don't have to define 1000 variables for that.

I was suggesting that you may end up with 1000 different possilities of placements, depending on the style of check you pusrchase, not 1000 variable, but rather 1000 different configuration. 1000 is probably over kill, but still.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.