There seems to be a glitch when binding Report Parameter properties to properties in its Root Container, which are parameters given to the window upon opening. The reportName binding works perfectly, no issue there, but all of the Report Parameters are blank even know they’re bound to custom properties on the Root Container which are filled with values. The binding shows active, and does take effect if I close and reopen the binding… and oddly, if I change the values of any of the components that affect the bindings on the main screen. (So it’s only noticeable if you leave everything at default and hit Show Report – I’ve definitely noted that the parameters are correctly passed in the script and correctly show on the root container at the other end on the Report window, it’s only the Report Viewer that won’t pick them up.) That’s despite the defaults on the parameter screen being different from the defaults on the report screen.
I’ve worked around it for now by creating a script on InternalFrameActivated that explicitly copies the parameters from the root container to the report viewer. Whatever works, I guess.
Not sure you are going to fix this if you are binding report name. When bindings start up, they can get a null delivered before the actual data, which would briefly disturb your selected report. Which in turn will briefly destroy the custom properties on the report viewer. Which could (timing dependent) make them not exist when your other bindings try to deliver the rest of the root container values.
Consider using a propertyChange event on the root container to propagate the report name, skipping the assignment if null, empty string, or already equal.
The report viewer component properties are dynamic based on the report path specified. In addition to what Phil said about not directly binding to the Report Path property, be careful about binding to the specific report parameters too. In version 7.9 we had bindings on Report Viewer’s report parameters. When upgrading to version 8.1 we now had a red overlay on the Report Viewer because an exception was being thrown for one of the bindings. In this case it was an error converting a string value to integer. The integer property being referenced in the error message was no longer a valid report parameter as it had been deleted from the report. The Report Viewer left the property but removed it from the property editor so we could not see or remove the offending link. Using the window XML, the property still existed on the component. Fixing the phantom property required either adding a new Report Viewer component and rebinding the property values or temporarily adding the report parameter back.
1 Like