Variable within a report band

What is the recommended "Windev method" of adding, and then using, a variable within a report band?

The goal: I have 14 boolean fields in the table; instead of using up a lot of page space to print boxes with checkmarks, I'd rather build / print a text string of the boolean fields that contain a value of 1.

I know how to manipulate / concatenate field values that print within the report band (i.e. within the BODY band I manipulate that ITEM value); however, I couldn't find how / where to add a local string variable that I could then add to the report. I played with the STATIC control - while the code would work one time, that control's contents wouldn't change - it would keep repeating the value within the BODY band... looked through the WD books and through various shipped examples and couldn't find an example that had an example to learn from.

To add to the situation - I added a ITEM control to the Body BAND; within the Body's "Pre-Print of BODY" section I added the code to combine the individual fields into one string for that ITEM control. At runtime the last record in the database would repeat itself for every database record that was generated to the report - this doesn't make sense to me, because when I change the contents of another ITEM control that was linked to the database it would concatenate the values as desired and it wouldn't repeat the same value at report runtime. So, an identical process was followed, within the same BAND - the only difference was one ITEM control was added to the report by the report wizard and the other was manually added - the wizard-added control printed properly, and the manually entered control did not..

Puzzled..

Hi Scott,
you can add variables in de opening section of your report. These vars are global to the report. And you can fill and use them at every stage, ie body-preprint, breaks, footer, etc

You don't actually need an (invisible) item to get the values you need. I'm assuming your report is based on a query? In that case you can also refer to the query at any point, ie qry_customers.fullname
In the body-part it's positioned on each and every record. In the page-end it's positioned on the last record. The report just itterates the query from begin to end.

It's not exactly clear to me, how your report should look like, but maybe this wiil help

Good morning Arie,

Thank you VERY much for replying - the report is filled from a table -vs- a query; I will give your recommendation a try later this afternoon.


Scott

Hi Arie,

Creating the variable was easy and made sense; however, it didn't work. Hoping I can better describe my objective so you can help me figure out what I'm doing wrong (using a make believe database and make believe record contents).

In a database named "cars" there are fields for "AirConditioning", "LeatherSeats", and "Sunroof" - those 3 fields are boolean fields, thus using a checkbox on the form.

Within the car inventory report, the default way of printing those 3 fields is to display the checkboxes - which is fine, except if you have 12+ checkboxes they start to occupy a lot of page space. Therefore, I was thinking of a way of reducing the space required on the printed page - the idea being that I would create a string variable (gsOptions) in the report initialization section - add the gsOptions variable onto the BODY band, and build the string based upon the record as it's read:

if CAR.Airconditioning = 1
gsOptions = "A/C"
end
if CAR.LeatherSeats = 1
gsOptions = nospace(gsOptions) + ", " + "Leather Seats"
end
if CAR.SunRoof = 1
gsOptions = nospace(gsOptions) + ", " + "Sunroof"
end

The problem is WHERE do I clear, and then rebuild, thegsOptions variable? I've tried every different code embed to build, and then print, the variable, and the results are incorrect and erratic... I've been opening / exploring the various example apps in WD17 hoping to find an example of what I'm trying to achieve - I've had no luck finding it so far...

If I am reading this correctly then I would think that placing

gsOptions = "" before your first 'if CAR' statement would do the trick - in the pre print of the BODY.

How and were are you running the query that returns the data?

Hi DerekT - nope, no query used for this report - I created the report from scratch (right click on REPORTS; selected FORM, then FROM A DATA FILE OR AN EXISTING QUERY, selected the HF table, chose a key, defined the sort order, no breaks, selected all of the fields (since they would all be printed on the report's page), left the default of all SUMS being created automatically, Portrait mode on 8.5x11, MediaPlayer skin, named it and saved it.

I initially began with the PRE-PRINT embed to build the variable, as that is where I concatenated several fields for the ITEM controls within the BODY band - those worked just fine... I would then add within that same embed something like:

// Blank out the variable
gsOptions = ""
if CAR.Airconditioning = 1
gsOptions = "A/C"
end
if CAR.LeatherSeats = 1
gsOptions = nospace(gsOptions) + ", " + "Leather Seats"
end
if CAR.SunRoof = 1
gsOptions = nospace(gsOptions) + ", " + "Sunroof"
end

..and then ran the report that the gsOptions string would't be correct - I would leave the checkboxes within the BODY band so they would print onto the page (so I could be 100% sure that the gsOptions variable was being created properly) - sometimes the gsOptions variable would say "A/C" and sometimes it wouldn't, and it didn't matter what the actual checkbox value was - I would then comment out that code within the BODY embed and try adding it within a different embed, and it would be the same problem - sometimes the gsOptions variable would contain the "A/C" and sometimes it wouldn't - and it didn't matter if the checkbox was checked or not!

Scott,
it seems not very wrong to me. You do not actually need the variable, if that makes it more complex to you.
You can use the pre-print section of your ITEM_Options and change it's value directly.
(do no bind/link this item to a databasefield ...)

if CAR.Airconditioning = 1
ITEM_Options = "A/C"
end
if CAR.LeatherSeats = 1
ITEM_Options = nospace(ITEM_Options) + ", " + "Leather Seats"
end
if CAR.SunRoof = 1
ITEM_Options = nospace(ITEM_Options) + ", " + "Sunroof"
end

I would also debug this piece of code, so you can follow exactly what's in CAR.Sunroof and other CAR-fields.
- set a breakpoint at the required line. Then the IDE will stop their and you can see all variables and so on, at that very moment.
or
- add extra lines likes these
Trace("Sun " + CAR.Sunroof, "LS " + CAR.LetherSeats)

Scott
I cannot see any issue with the code you have illustrated.

As Arie says debugging will show you exactly what is happening when reading the records into the report.

Couple of wild guesses.....................
Have you tried using False and True as opposed to 0 and 1 in your code ? - cannot see that it should make any difference but.......

Have you tried also setting all the check boxes to false, in addition to clearing gsContract, in the BODY prior to reading each record?

Hi DerekT - the database is already populated (imported from a Clarion *.TPS database - the boolean fields already have integer values of either 0 or 1) - are you saying for me to do this:

if CAR_AirConditioning = "TRUE"
add the string to the onscreen variable
end



Hi Arie - I don't have an extra "field" within the table that I can use to wipe out it's contents and then append the "A/C", "Leather Seats", etc to... therefore I have to use a string variable to first wipe out, and then check the true/false values to append information to that string

Scott
Yes - just try, cannot see why it should be any different as False/True is just an interpretation of 0/1 but as part of debug.

Are your check boxes linked (bound) to the data table (file) ?

Try using HReset(MyTable(File)) at the start of the BODY block to clear the buffer of previous values

Unlink them and set them individually when reading each record -- MyCBox1 = MyTable.Value


For debugging, set a breakpoint on the first code line in the BODY block - run the report which will stop at this break and then step through (using F7) and watch the values as they change in the debug pane at the bottom of the window

Scott I think you mix up 2 things.
an item (control) of your report, which can show whatever value (text,number) you want.
a field of a table (database).
you can link an item to a field, so it will display the fields value automatically.
but you can also use non-linked items.
bu default, when you use the wizards, the item are linked to the database. using the description window however, you can remove this link.

I think you should do that. I guess the unpredictable results are caused by the fact you set the value "by code" AND the get's it's value (while it is still LINKed) from the database. It then depends: who wins

Hi Arie,

I am using a variable that was created within the report to store the values that I am building with code placed within the BODY embed - that variable shouldn't be linked to a database field (but I will double check).. two days ago I tried using a new STATIC control that I added to the BODY band (that wasn't linked to anything) and I had the same erratic results with that control as I do now with the variable...

Hi Scott,

I have not read all the answers, so perhaps I'm doubling other people but there is something definitely wrong with your code.
1. you have omitted the THEN after the IF.
2. if a car has no Airco, the ITEM_Options is not initialized.
3. If by any chance you are using an internal query for your report you need to use the MySource variable to refer to the source of the report, otherwise you can use the name of the file that is the data source.
4. Your code needs to be placed in the pre-print section of body code or pre-print of the control code

So the code could look like:

sItem is string
if MySource.Airconditioning THEN sItem +=", "+"A/C" 
if MySource.LeatherSeats THEN sItem += ", "+"Leather Seats"
if MySource.SunRoof  THEN sItem += ", "+"Sunroof"
if sItem<>"" THEN sItem=sItem&#91;&#91;2 TO]]  //remove the first ", "
ITEM_Options=sItem

Regards,
Piet



Edited 1 time(s). Last edit at 10/10/2012 04:14PM by Piet van Zanten.

Like Piet above, I haven't read all the answers above but... might help...

I just had something rather similar - I found that referencing the item / static control in the body of my report produced erratic results whereas referencing the query field itself produces perfect results every time...

Just a thoight, might be worth a try and apols in advance if this duplicates something above or wastes your time (shouldn't take more than a jiffy or two to try though)..

Rgds

Ian

Ian / Piet - I didn't get a chance to experiment last night (sick kids at home), but will give your excellent suggestions a try tonight!! It was driving me nuts that within the BODY report band I could manipulate the ITEM controls (e.g. concatenate fields), but everything I tried with the boolean fields and a variable were producing inconsistent results.... if the code produced consistently bad results it would have been one thing, but as my screen capture showed nothing was consistent <g>...

Thank you both VERY much for the help!!!!!!!!!!

Piet - your example was dead on the money!!!! The problem was I didn't assign the variable back to the ITEM control within the report band - I had tried your code MINUS the last line (ITEM_Options=sItem) and the results were the same as mine; when I added the last line (ITEM_Options=sItem) into the pre-print code it worked. Thank you SO much!!!! What an invaluable lesson, and I thank everyone for helping me with this problem, as I accustomed to "tweaking" report output like this, and I was chasing my tail. YOU ROCK!!!