Hide report sections

Fisherman

All -

i'm trying to do a report with multiple rollups (totals) and a grand total at the end. I have the base report working, but there's some added functionality that I'd like to include that is giving me trouble.

I have included checkboxes on the Request form to allow the user to only view certain rollups of the report. The idea is that a user might want to only view the grand total, and not all of the supporting data.

My checkboxes have a "SourceExpr" equal to global boolean variables, so that when they check the box, the boolean is set to true.

In my OnPreSection() trigger, I have used the following CAL Statement to attempt to dynamically show/hide the section based on the user selection:

CurrReport.SHOWOUTPUT(NOT gMyBooleanVar);

It ALMOSTworks. When the report renders, it does not show the section in question. Instead, it leaves page after page blank, and displays the grand total on the last page.

Can someone tell me how to prevent the unrendered sections from taking up space on the page so that the grand total shows up on the first page if the user wants to hide all other detail? I tried setting section height dynamically, but I haven't found a way to do it yet.

DenSter

Probably a section with no (or empty) controls on it that doesn't have your logic, so it prints those even though you don't want to see them. Check every section for the logic and make sure there's no double negatives in there that confuse you.

Personally I always try to keep booleans to positives. I would rather have a user choice that says "Show Detail", than one that says "Hide Detail". In the first case the code would say SHOWOUTPUT(ShowDetail), in the second it would say SHOWOUTPUT(Not HideDetail). I personally think the second is easy to misinterpret ("when the user checks the box, the value is TRUE, but he means he does NOT want to see detail, so SHOWOUTPUT must be FALSE, but because the variable is TRUE for NOT showing the output, I have to program NOT FALSE for TRUE"), very confusing....

This type of issue is difficult to troubleshoot without access to the actual object though.

Fisherman

Personally I always try to keep booleans to positives.

Normally, I do too. My rule, though, is to have the boolean map to the default condition. The default condition in this case is to show the output. Since checkboxes bound to booleans automatically set the boolean to "True", and I have no way to override that functionality, I'm not sure how else to handle this and retain usability (Believe me, I come from C++ originally, and those guys are nuts about it).

I'll look to see if there's anything out of the ordinary. I thought I had already been through every section, but maybe I missed one.

kine

Hard to say, but try to enable debugger and check that the boolean variable is really True when you want to hide the sections.

Fisherman

Does anyone have any other suggestions here? I have verified that the boolean values are setting correctly by using a MESSAGE to output the result of the SHOWOUTPUT function, which is returning "No".

I'm still stuck with the same problem. Any other tricks to try? Is there a way to dynamically set the section height on-the-fly?

Savatage

have you changed keepwithnext set to no or
printoneverypage set to yes?
or placeinbottom?

Can you paste a text file of the report?

Fisherman

Let me give those a shot. I'll let you know what I find, and if it doesn't work, I'll paste the report.

it is based on tables that are specific to a custom 3rd-party solution that we're using, so it may not make a lot of sense at first.

Savatage

Oh I see. It must be something beacuse Any hide sections that I've used tightens up the report just fine without pages & pages of blanks.
:-k

might wanna check the PrintOnEveryPage property too on these sections that won't go away

DenSter

Fisherman wrote:

Since checkboxes bound to booleans automatically set the boolean to "True", and I have no way to override that functionality, I'm not sure how else to handle this and retain usability

Actually, the default value of booleans is FALSE. A checkbox control on a form with a boolean variable as its sourceexpr will be unchecked in NAV. Just having a checkbox tied to a boolean variable doesn't set its value.

In a report the first trigger that fires (before the request form is displayed) is OnInitReport, which is where I always program these types of preconditions. So I would have a boolean variable called ShowDetail, with a checkbox on the Options tab, which you can set to the default value of TRUE in the OnInitReport trigger of the report.

Fisherman

Den -

i think you misunderstood my intent. I'm not stating that the default value of a boolean is TRUE, I'm stating that default behavior of a checkbox bound to a boolean is to set the boolean value to TRUE when the box is checked, and I don't know of any way to override this behavior.

I could just as easily code it this way -

IF gMyBooleanVar THEN
    CurrReport.SHOWOUTPUT(FALSE);

... and maybe I should, because it's more self-documenting in terms of intent, but the statements are equivalent in function right now.

See - in my report, the default behavior is to Show all detail. It is only desirable to not show detail if the user only wants a grand total. Therefore, my checkboxes are labled as "Hide Item Detail", "Hide Lot Detail", etc... When the user checks the box, they indicate that they want to hide that level of detail.

If I reversed the logic (DeMorgan's rule), I would say "Show Item Detail", but this would require action to enable the default behavior - not a desirable situation.

This is why I'm using a NOT operator to check the value of the boolean. I normally do not do this, but the default behavior, in this situation, is negative. For the report to make sense to the user, I have presented them with a positive decision, but I am checking the negated value in code for the proper transformation.

Fisherman

Savatage -

Interesting results.

I did have the primary data item's Header section set to print on every page. Turning it off results in a Two-page output now. One page with the header and no data, and the second page with only the grand total line.

The question now is, what is causing the first page to fill in with blanks, and then I'm golden...

DenSter

Fisherman wrote:

i think you misunderstood my intent. I'm not stating that the default value of a boolean is TRUE, I'm stating that default behavior of a checkbox bound to a boolean is to set the boolean value to TRUE when the box is checked, and I don't know of any way to override this behavior.

I understood your intent perfectly well. I'm not saying you should override any behavior, you couldn't you even if you wanted to. A checkmark means Yes or TRUE, no checkmark means No or FALSE. You must have misunderstood me when you thought that was what I suggested.

Fisherman wrote:

the statements are equivalent in function right now.

Yes they are, and perfectly valid coding too. All I am saying is that to me it is less friendly to read. As a rule I program from a general "yes means something happens, no means something doesn't happen". If I want something to happen I don't set a condition to NOT FALSE, when I can just as easily program it to say TRUE. I'm lazy I guess, I don't want to think about double negatives when it is just as easy to write code the other way.

Fisherman wrote:

See - in my report, the default behavior is to Show all detail. It is only desirable to not show detail if the user only wants a grand total. Therefore, my checkboxes are labled as "Hide Item Detail", "Hide Lot Detail", etc... When the user checks the box, they indicate that they want to hide that level of detail.

Yes that is what I understood, and when I want something like that accomplished, I have a checkbox saying "Show Detail", and I program it to have a checkmark in it to start out with. Nobody has to do anything and they get the default results automatically.

Fisherman wrote:

If I reversed the logic (DeMorgan's rule), I would say "Show Item Detail", but this would require action to enable the default behavior - not a desirable situation.

Not if you make a checked checkbox the default behavior (DenSter's rule ). To me double negatives are what is reverse logic. When I want to program TRUE, I try to program TRUE, and I try to avoid having to program NOT FALSE. It means the same, and it is perfectly valid, but not very friendly to work with.

Fisherman wrote:

This is why I'm using a NOT operator to check the value of the boolean. I normally do not do this, but the default behavior, in this situation, is negative. For the report to make sense to the user, I have presented them with a positive decision, but I am checking the negated value in code for the proper transformation.

The default behavior is not negative, see that's why the way this is programmed is so confusing, even to you. The default behavior is "Show me the detail", but you are programming "Don't hide the detail".

I'm not saying you are wrong, I am just making a case for the way that I would personally do it. Your report has a whole bunch of unchecked checkboxes when the user opens it called "hide x" and "hide y", My version would have a whole bunch of checked checkboxes called "show x" and "show y". They would do exactly the same, but the code in my version would be easier to read (in my personal humble opinion of course ).

Didn't expect to get a whole dissertation, but thanks for explaining your way of thinking.

DenSter

When you said:

Fisherman wrote:

Since checkboxes bound to booleans automatically set the boolean to "True"

I thought you meant that the action of binding a checkbox to a boolean sets its value to TRUE, which is not correct.

Fisherman

Got it!

I had NewPagePerRecord and NewPagePerGroup set to True. When I set them to FALSE, it started performing as expected.

Savatage

Those pesky properties strike again!

Fisherman

Yeah - if only there were some company that had tons of documentation standards, and tons of documents about documentation standards, and tons of people who could fully document annoying little things like this so that programmers didn't spend a day and a half trying to figure out an odd display issue caused by a seemingly unrelated property...

Oh, wait. Doesn't Microsoft own Navision

DenSter

Fisherman wrote:

Got it!

Good work =D> that stuff is hard to troubleshoot.