Resolved Object reference not set to an instance error

[LabProARW]

        DateTime dtStartDate = DtStartingDate.Value;
            DateTime dtEndDate = DtEndingDate.Value;
            ReportParameter[] newparams = new ReportParameter[2]; 
            newparams[0] = new ReportParameter("StartDate", dtStartDate.ToString(), false); 
            newparams[1] = new ReportParameter("EndDate", dtEndDate.ToString(), false);
            this.SampleCountReportViewer.LocalReport.SetParameters(newparams);   // <-- this line throws the error.  Hovering over dtStartDate and dtEndDate shows the correct dates as taken from the form.
            this.SampleCountReportViewer.RefreshReport();

This code snippet worked and was reported as an answer to a users question attempting to pass date parameters to a report. What instance of an object am I missing?

Thank you.

 

[Skydiver]

Hover over SampleCountReportViewer or LocalReport. One of them is likely null.

 

[NoUserHere]

You beat me to it.

Likely SampleCountReportViewer needs instantiating.

Op shouldn't be copying code and using it without understanding how it works.

I have no sympathy. You should know how the code works, or else don't use it!

 

[NoUserHere]

Or it belongs to another class which we are not seeing.

What is SampleCountReportViewer and what is LocalReport and how and where are they defined in your current code scope?

 

[LabProARW]

On hover of SampleCountReportViewer is -> '(field) Report Viewer FrmSampleCountReport.SampleCountReportViewer.' The interface does not flag this with a red underline in the code itself. It does upon running the code.
On hover of LocalReport is -> 'LocalReport ReportViewer.LocalReport { get; }'

The SampleCountReportViewer.RefreshReport() runs without a problem. Its where I try to 'SetParameters' that the instance error occurs - so I figured the objects were fine. This is all invoked on FrmSampleCountReport from BtnGenerateReport. The copied code is portrayed as working - just not working in my form code in VS2019.

 

[LabProARW]

The solution for this problem was to add this code in the procedure.

this.SampleCountReportViewer.LocalReport.ReportPath = "SampleCountReport.rdlc";

 

[Skydiver]

So for the report viewer to work correctly, some of its properties have to be set in a specific order otherwise things blow up. Looks like someone over at MS decided to not go to the API design classes that offered. Thanks for sharing your findings.

 

[jmcilhinney]

So for the report viewer to work correctly, some of its properties have to be set in a specific order otherwise things blow up. Looks like someone over at MS decided to not go to the API design classes that offered. Thanks for sharing your findings.

SetParameters is a method, not a property, so I'm not sure that your implication actually applies.

Given that the documentation for the SetParameters method says this:

The parameters specified for the SetParameters method must be defined in the original report definition.

it should be fairly obvious that you have to specify the report before you can set the parameters of that report. Of course, if you don't read the documentation...

 

[Skydiver]

I thought I read that, but it just didn't pop out for me that the local report path had to be set by the time SetParameters() was called. I thought that all of that would be resolved when it was time to actually render the report, not when SetParameters() was called. On the other hand, I've had too much SharePoint on the brain this current on call week, and SharePoint seems to do everything at the last possible moment, so I may have gotten used to that model.

 

[jmcilhinney]

I've used ReportViewer controls a bit but more in ASP.NET than WinForms. I think that the ServerReport and LocalReport properties each refer to objects that can contain a report, rather than being the actual report themselves. You basically have to load the report into them first and then you can manipulate it. I guess they could provide a parameter cache inside that object and then apply the parameters when you actually specified the report but that would add considerable complexity so I it seems the pragmatic path to not do that.

 

[Skydiver]

So basically immediate-mode vs. retained mode. And yes implementing immediate-mode APIs is much easier, but it also requires the user of the API to understand the underlying workings of things.