Printing Tables

  • (2 Pages)
  • +
  • 1
  • 2

19 Replies - 1495 Views - Last Post: 30 January 2014 - 11:13 PM Rate Topic: -----

#16 dleduc  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 13
  • Joined: 23-December 13

Re: Printing Tables

Posted 29 January 2014 - 09:29 PM

On the print width issue, I did try several experiments. I created one report with just 2 columns and it did not add extra pages. Then I created my basic table again on a clean report to make sure that I hadn't inadvertently added something and I got the blank pages again. This makes it appear that my basic tablix is somehow too wide even though it does print as about 6 inches wide.
Was This Post Helpful? 0
  • +
  • -

#17 thecoat  Icon User is offline

  • D.I.C Regular

Reputation: 127
  • View blog
  • Posts: 423
  • Joined: 07-December 13

Re: Printing Tables

Posted 30 January 2014 - 02:07 PM

Okay so on the organizational issue I did do something similar. Last night I was trying to do what you need using either a tablix or matrix and grouping. The report I did at work I ended up using a subreport dropped into a tablix. I'll try this with my mock up at home and if I can get it setup correctly I'll upload the project instead of trying to explain all the gory details. Basics of it though are that I used more than one table that have a natural foreign key relation, but the reporting infrastructure seems to be woefully lacking in it's support for this to the point that I ended up using filtering on a tablix in a sub report to work around. Honestly it seems so janky that I'm thinking there has got to be an easier way to go about this, but when I was creating the report I looked at today I didn't manage to figure out an easier way.

On the extra page issue, I'm not sure. I don't know if the reporting engine here does what MS access does as far as using the targeted printer drivers when formatting the report for a print or disk save, but that might explain why it looks one way in display mode vs printing. If you want to upload your rdlc file, I could look at it from within the designer and see if I can discover where the extra page is coming from.
Was This Post Helpful? 1
  • +
  • -

#18 dleduc  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 13
  • Joined: 23-December 13

Re: Printing Tables

Posted 30 January 2014 - 09:08 PM

It will be interesting to see how you handled the format of the table. I hope that I'm up to figuring it out. This brings me to one of my original questions: Is there someplace where I can get documentation for the report feature? I have run across all kinds of terms that I just have to infer how they work.

As for the width issue. I have dealt with Access quite a bit and have always been able to find the long line or whatever that prevents it from fitting on a page, but I've had no luck with this report. I have attached my rdlc file in case you can see anything that I cannot. One thing that I find interesting is that when you click on the icon to get a print layout, it shrinks down to some mini-screen for a second or two and then returns to full size. I wonder it it won't fit on the mini-page even though it fits on the big one, but whatever it does is too fast to see what's happening. I couldn't attach an rdlc file so I zipped it

Attached File(s)


Was This Post Helpful? 0
  • +
  • -

#19 thecoat  Icon User is offline

  • D.I.C Regular

Reputation: 127
  • View blog
  • Posts: 423
  • Joined: 07-December 13

Re: Printing Tables

Posted 30 January 2014 - 10:54 PM

Okay so yea this gets hairy, and I tried to keep things as simple as possible to just demonstrate the technique we are after. Most of this is done via dialog and wizard settings, meaning there wasn't much to comment ><. RDLC files are actually just xml files, but putting comments in those would have been silly ;-).

On the dataset design I used an ID field as the key field for the relation between the two tables. This could just as easily be the String Name value for your trees. I don't believe the relation is an absolute must for the reports to function, but it's a defensive mechanism to ensure that data expected by the report isn't absent, or extraneous records that don't have a parent and should can't be accidentally added to the dataset. As you will hopefully see, the parent to child relationship of these two reports isn't established off the dataset, but via data filtering and parameters.


Report1 consists of a single tablix. Since we wouldn't be interested in a Header (the row with the value data is essentially a header) I set the top header text box visibility to false, so you will see it in the designer but not when the report is rendered. I then expanded the single column in the tablix to be the width I'd need to contain the sub report (it's actually larger, but in your case you want a healthy width for your fairly large tablix in the sub report. Now of course we need another "static" row in the tablix to contain the sub report. Right clicking on the bottom row Insert Row > Inside Group - Below. This gives us a row to stuff the second report in (report2). I didn't check the number of actual objects in the report at runtime, but my perception here is that for each header type record a new instance of the subreport is created and placed below it.


Report2 (the sub report) is based on the second table, which has two generic data fields. I just ran the wizard to create a second report then drag/dropped it into the tablix on the report1, instead of dragging the generic sub report control from the tool box. If you look at the code from form1 I then added prior to the report refresh call an event handler to handle the subreport load.

AddHandler ReportViewer1.LocalReport.SubreportProcessing, AddressOf AddSubReportData


 Private Sub AddSubReportData(sender As Object, e As Microsoft.Reporting.WinForms.SubreportProcessingEventArgs)
        Try
            e.DataSources.Add(New Microsoft.Reporting.WinForms.ReportDataSource("DataSet1", Me.ReportData.Tables(0)))
        Catch ex As InvalidExpressionException
            MsgBox(ex.Message)
            Debug.WriteLine(ex.StackTrace)
            Debug.WriteLine("")
        End Try
    End Sub


Unlike specifying the main report on the report viewer control at design time, loading the sub report doesn't just get the datasource off the form so it becomes necessary to add it at runtime. I just realized I could place a break in the handler method and tell how many times it was fired.. it was indeed fired twice once for each of the two headers I added, so yea behind the scenes multiple instances of the sub report are being created.

At this point you can run the report, but because it is based on the detail table ("ReportData") it will load all the records, which is where the parameters and filters come in.
With the report2 design tab open you should be able to see the report data tool box. And view the report parameter (right click on the name parameter to add a new one). Side note here, if you ever close the Report Data toolbox when viewing a report getting it back can be a fun one to find CTL+ALT+D with a report design open will get it back. Anyway I added a parameter called CatID we will pass this value from report1 and use it to filter out only records that match the parent Category. Then if you select the tablix and right click on the upper left square and got to the tablix property sheet(still on report2) you can go to filters and see the filter I created.

Back on Report1 you can right click on the sub report and go to it's properties and go to the parameters, this is where we pass the data from the current row to the sub report.

Yea I know I should have probably included screen shots and not just let loose with diarrhea of the mind here, hope I didn't get to confusing, but it's getting late and I want to look at your rdlc before I head to bed.

Attached File(s)


This post has been edited by thecoat: 30 January 2014 - 10:55 PM

Was This Post Helpful? 0
  • +
  • -

#20 thecoat  Icon User is offline

  • D.I.C Regular

Reputation: 127
  • View blog
  • Posts: 423
  • Joined: 07-December 13

Re: Printing Tables

Posted 30 January 2014 - 11:13 PM

Yea I don't see anything jumping off the page in design mode, and the numbers look okay, you are about an inch under the standard 8.5 width including margins. What I suspect is going on though is that when rendering the report for print the main table is getting re sized beyond the edge of the page to fit the data, and that there is a very small sliver of the last column spilling over. Adding a an outline border to the body section may show this to you, if this is the case you'll essentially see half a rectangle on the formerly blank pages.

Edit: Oh yes and as to your question:

Quote

Is there someplace where I can get documentation for the report feature?


MSDN? Honestly RDLC report design is in my "I really need to find a good book on that at some point." categories. It's imho a lot like Wix, the information is out there on the web, and in many cases not horrible, but finding a complete concise from the ground up book will likely be needed to bring it all together for a light bulb moment (at least for myself). I'm sure some of the training sites have videos and such, I should probably look into that as well. At this point most of what I know about this type of report design has been from playing around (sometimes fighting) with them... which is why I was kinda hoping someone would pop into this thread and tell me I was doing it all wrong, because it just feels so workaround janky... and I have a ton of MS Access reports at work that I'd like to get out of Access and replaced with a .Net App. Every time I mess with RDLC though it's one of the few times I think "This is easier in Access", usually it's the other way around.

This post has been edited by thecoat: 30 January 2014 - 11:30 PM

Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2