none
LocalMode Parameters and footers RRS feed

  • Question

  • My goal is to have a value from a dataset show up in the footer section on a report, IE a company name.

     

    I can't drop the company name on the footer as fields are not allowed there.

     

    I created a parameter CompanyName and assigned a Default value From Query pointed to my dataset and to the field. I added a textbox to the report footer and assigned the CompanyName parameter's value... and Yes! That works.

     

    ... until

    I copy the RDL XML into a file and rename it to RDLC. Save the Dataset to another location... create a report viewer in .NET and merge the RDLC and Dataset in localmode.

     

    The error is: CompanyName parameter is missing a value...

     

    Is what I'm doing wrong? Do I really have to open up a parameter collection and manually assign the values from the dataset? I understand parameters "don't work" in localmode but to me this seems like it should pull the value from the dataset right?

     

    Well, any thoughts would be welcome...

    Friday, April 20, 2007 9:26 PM

Answers

  • You are getting this error because you have to load the dataset into the reportviewer dynamically.  There are very minor differences between rdl files and rdlc files.  The biggest difference is how they are loaded into the report viewer.  If you load an RDL or RDLC in the report view in local mode then the datasets are not automatically loaded.  If you load a rdl file into a report viewer that is not in local mode then the datasets are automatically loaded.  If you create an RDLC from scratch and do not have any dataset information in the rdlc and you try to load it into a report viewer that is not in local mode you will get an error.

     

    You really have two options.  You can read the rdl file and try to create datasets and place those datasets onto the reportviewer before the report is shown or you can create a DataSet.xsd file in visual studios and set those datasets onto the reportviewer.  I would go with the second option because it is much quicker.

     

    Chris

    Monday, April 23, 2007 5:36 PM
  • Thank you for your reply, I appreciate it.

     

    I was only able to resolve the footer issue by placing a hidden textbox in the body that contains the field value and referencing to it from the footer. 

     

     

    Tuesday, April 24, 2007 3:43 PM

All replies

  • You are getting this error because you have to load the dataset into the reportviewer dynamically.  There are very minor differences between rdl files and rdlc files.  The biggest difference is how they are loaded into the report viewer.  If you load an RDL or RDLC in the report view in local mode then the datasets are not automatically loaded.  If you load a rdl file into a report viewer that is not in local mode then the datasets are automatically loaded.  If you create an RDLC from scratch and do not have any dataset information in the rdlc and you try to load it into a report viewer that is not in local mode you will get an error.

     

    You really have two options.  You can read the rdl file and try to create datasets and place those datasets onto the reportviewer before the report is shown or you can create a DataSet.xsd file in visual studios and set those datasets onto the reportviewer.  I would go with the second option because it is much quicker.

     

    Chris

    Monday, April 23, 2007 5:36 PM
  • Thank you for your reply, I appreciate it.

     

    I was only able to resolve the footer issue by placing a hidden textbox in the body that contains the field value and referencing to it from the footer. 

     

     

    Tuesday, April 24, 2007 3:43 PM
  • This is what we had to do. For every dataset-derived field that we wanted in a header/footer, we had to create an intermediate field in the report body, map the dataset-derived value to the field, then reference the body's field in the header/footer.

     

    We made the fields in the body 0.05 inches square, set them to hidden, and set CanGrow to false, just to be sure they don't pop up on a report somewhere/someday. We then shove them off into a neat little row just below the header and out of harms' way...

     

    The good part is that it works quite well once set up, though it is klunky. We were even able to extract bmp's (images) from our dataset, encode them as strings, and then use those in header/footer fields. There's a blurb on the net somewhere about how to do that. Now that it's set up I just cut-n-paste so I don't remember the details.

     

    Wednesday, July 18, 2007 12:50 AM
  • "The good part is that it works quite well once set up, though it is klunky. We were even able to extract bmp's (images) from our dataset, encode them as strings, and then use those in header/footer fields. There's a blurb on the net somewhere about how to do that. Now that it's set up I just cut-n-paste so I don't remember the details."

     

    Any idea where this article is?

     

    -Markus

    Tuesday, July 24, 2007 2:54 PM
  • Sorry Markus, I haven't checked the forum in a few days (I was adding features and fixing defects in other areas of our apps...)

     

    Anyways, I'm looking for the link and if I can't find it, I'll summarize the process myself sometime over the next 24 hours or so.

     

    Please be patient, we're in ship mode on one project and are working features heavily on another...

     

    Thursday, July 26, 2007 5:14 PM
  • I can't recover the original link.

     

    Here's the long and short of it, cut-n-pasted from a working example.

     

    In the body of the Report (not the header or footer), create a Textbox field named some convenient name, such as AConvenienceFieldToCarryMyBmpToMyHeader.

     

    For it's value, use something like this (properly edited):

    =Convert.ToBase64String(First(Fields!SomeReportValueThatIsTheBump.Value, "MyDataSetThatContainsTheValue"))

     

    Note that the second parameter is only necessary if you have multiple datasources for the Report. What this does is suck the bmp out of the datasource, convert it to a Base64 string, and store it's value in the report field.

     

    Then, create an Image field in the header/footer. Set the mime type according, and at least I set the source to database.

     

    Then, for it's value, use something like this:

    =Convert.FromBase64String(ReportItems!AConvenienceFieldToCarryMyBmpToMyHeader.Value)

     

    There might be some minor tweakage necessary and I apologize for having lost the original reference.

     

    In words, you create a convenience field in the body of the report to receive the value out of the datasource  and convert it to a Base64 string.

     

    Then in the header/footer you can access the convenience field because it a Report field and not a DB field.

     

    You do the access and then convert back from the Base64 string and you're done.

     

    Again, there's probably some tweakage involved somewhere and I've lost the original link.

     

    Thursday, July 26, 2007 6:10 PM
  • The above idea of showing an image in a report header field originates from "Report Design Tips and Tricks"

    (http://msdn2.microsoft.com/en-us/library/bb395166.aspx). I am trying the example involved ("Image Value Referring to a Text-Box Value"), but unfortunately, I does not work yet for me.  Leendert.

     

    Friday, August 10, 2007 11:55 AM
  •  Leonardo52 wrote:

    The above idea of showing an image in a report header field originates from "Report Design Tips and Tricks"

    (http://msdn2.microsoft.com/en-us/library/bb395166.aspx). I am trying the example involved ("Image Value Referring to a Text-Box Value"), but unfortunately, I does not work yet for me.  Leendert.

     

     

    It's been working for us but it is frail, for lack of a better term.

     

    Because of indirection through the form field and the conversion of the image (Byte[] along the way, everything has to be set up just so or it won't work.There's a lot of properties and so on that have to be set up properly. Patience and a willingness to experiment is what got us through it.

     

    In our case the report field in the header is an image, the MIMEType is set to image/bmkp, the Source is set to Database, and the Sizing is set to FitProportional.

     

    We give the customer the option of defining their company's information, including an optional BMP (logo, thumbnail.)

     

    So far so good...

     

    But during testing we discovered that if they entered no information, the row doesn't exist in the CustomerInfo table, adn we'd get exceptions. We worked around that by adding a row to the in-mem Dataset if we have to.

     

    Then we next discovered that if the row existed but there was no image in that column in the DB, we'd get variously either an Exception trying to manipulate that row+column or we'd end up with the broken BMP image in the header of the report.

     

    We worked around that by embedding a default image in the ReportViewer's parent form and hiding it.

     

    Once we fix up the row (if needs be) we attempt to access the row+column for the image and catch the exception if one is generated. If there's an Except. we initialize that row+column to a "new"'ed Byte[0] value.

     

    Then we retest the length of the row+column and if necessary extract the default BMP from the parent form's resources and stuff it into the field.

    Friday, August 10, 2007 4:27 PM