One Report with multiple fields (1 Viewer)

[azhar2006]

Hello my friends
I have a report with six fields, and I have a form with two buttons to print the same report. What I want to do is have one of the buttons on the form display the full report with all its fields, and the second button, when clicked, will show the same report, but with only four fields, not all of them. I do not want to build two reports in the database. Or I need one button on the form to show me the report with its six or four fields based on the type of data in a specific field of the report. For example, if the city is (X), the report appears with all its fields, and if the value of the field is (Y), only four fields appear in the report.
Thanks to all

 

[plog]

You use DoCmd.OpenReport to open the report in both instances:

DoCmd.OpenReport method (Access)

Office VBA reference topic

learn.microsoft.com

Then on the button you want to hide fields in you add code to set the .Visible property of the fields after the OpenReport:

DoCmd.OpenReport "YourReport", acPreview
Reports.YourReport.FieldToHide.Visible = False

 

[azhar2006]

You use DoCmd.OpenReport to open the report in both instances:

DoCmd.OpenReport method (Access)

Office VBA reference topic

learn.microsoft.com

Then on the button you want to hide fields in you add code to set the .Visible property of the fields after the OpenReport:

DoCmd.OpenReport "YourReport", acPreview
Reports.YourReport.FieldToHide.Visible = False

Thank you

plog​

. And if one button based on a certain value in a field?

 

[plog]

I don't understand your question. Buttons aren't based on things.

 

[GPGeorge]

Hello my friends
I have a report with six fields, and I have a form with two buttons to print the same report. What I want to do is have one of the buttons on the form display the full report with all its fields, and the second button, when clicked, will show the same report, but with only four fields, not all of them. I do not want to build two reports in the database. Or I need one button on the form to show me the report with its six or four fields based on the type of data in a specific field of the report. For example, if the city is (X), the report appears with all its fields, and if the value of the field is (Y), only four fields appear in the report.
Thanks to all

Sometimes, when we try to describe a situation with vague terms and partial references, that attempt to "simplify" backfires, actually making it harder to follow the situation and understand the problem.

Instead, it's almost always better to be very specific about the data and the requirement and the situation.

Here, you could tell us: If the values of field "YourFieldNameGoesHere" is "RealExampleofDataGoesHere", control "NameofControlNameOnReportGoesHere" should be not be visible.

Of course, in this case, I'm sure there is a reason why sometimes you want to show the control on the report and sometimes not, so you also need to explain that. Why do you want to show the control only for some types of values? What is different about them?

We are usually pretty good at sorting out the data when we have actual, real, specific information to work with. We often struggle, though, with ambiguous terms like "the type of data in a specific field".

Help us help you. Use real examples and real names and describe real requirements.

 

[Pat Hartman]

I don't like the suggestion in #2 where you open the report and modify the report on the next line. Using this method means that every place you open this report from would need the same code. You may not open reports from multiple places but I always seem to.

My solution is to open the report and using the OpenArgs send a 1 or 2 (or whatever). Then in the load event of the report, it checks the value in OpenArgs and shows/hides the controls that way. This leaves the code that modifies the report in the report so it runs regardless of how the report got opened. You need to decide what the default is. Check for the non-default value. If it is true, then do the non-default thing else do the default thing.

 

[azhar2006]

I don't like the suggestion in #2 where you open the report and modify the report on the next line. Using this method means that every place you open this report from would need the same code. You may not open reports from multiple places but I always seem to.

My solution is to open the report and using the OpenArgs send a 1 or 2 (or whatever). Then in the load event of the report, it checks the value in OpenArgs and shows/hides the controls that way. This leaves the code that modifies the report in the report so it runs regardless of how the report got opened. You need to decide what the default is. Check for the non-default value. If it is true, then do the non-default thing else do the default thing.

Thank you very much .
I created another report and put a button to open it. The user can choose what report he wants by clicking on the first or second button.
I was thinking of using the function (if) based on a specific value in the table, for example the country. Whereas, if the country is (A), a text box will appear in the report that he is fluent in the English language. If the country is (B), then the language text box will completely disappear from the report.

 

[The_Doc_Man]

You have a solution and it works for you. I offer an observation (and it is NOT a criticism).

After the fact I can tell you that from a labor viewpoint, your "two different reports" approach is probably easier and more stable than having to dynamically alter the behavior of a single report. If you build the first report, copy it, and alter the second report to remove excess fields, then offer your user the option of which report to take, that is highly time-efficient AND does not require complex code to enable or disable things within your report. Labor-wise, a good choice. Technique-wise, also a good choice. The ONLY drawback is if the report has to change in the future, you need to change two reports. Since it does not appear that a report specification takes up a LOT of room in Access, having two reports that are almost alike is not a high price to pay. Keeping your selection logic simple (and external to the report itself) is also a good choice.

 

[azhar2006]

You have a solution and it works for you. I offer an observation (and it is NOT a criticism).

After the fact I can tell you that from a labor viewpoint, your "two different reports" approach is probably easier and more stable than having to dynamically alter the behavior of a single report. If you build the first report, copy it, and alter the second report to remove excess fields, then offer your user the option of which report to take, that is highly time-efficient AND does not require complex code to enable or disable things within your report. Labor-wise, a good choice. Technique-wise, also a good choice. The ONLY drawback is if the report has to change in the future, you need to change two reports. Since it does not appear that a report specification takes up a LOT of room in Access, having two reports that are almost alike is not a high price to pay. Keeping your selection logic simple (and external to the report itself) is also a good choice.

thank you sir
And I did what you said. But I know they will come back to me in the future for some changes