none
Use custom Class defined in project in the Report Property's Code RRS feed

  • Question

  • Hello,

    Can someone please tell me how I can reference a class that I define in my project, when writing VB code in the report.

    Here are some details:

    I am passing an object within an object within an object . . . as a datasource for my report.

    Instead of typing
    =Fields!Elements.Value.item(0).DisplayDate

    I would like to call the following code:
    =Code.RetrieveDataFromElement(Fields!Elements.Value, 0)


    Code Snippet

    Function RetrieveDataFromElement(ByVal ElementList As System.Collections.Generic.List(Of ReportViewerTest1.Element), ByVal index As Integer) as String

            Return ElementList.Item(index).DisplayData

    End Function


    I'm getting an error "Type 'ReportViewerTest1.Element' is not defined".

    I originally tried to use "Element", recieved this error and tried the full project/class path like the way I defined the List class.
    "'ReportViewerTest1.Element"

    Neither seems to work.

    Any help would be appreciated.

    Tuesday, April 1, 2008 9:55 PM

Answers


  • Hey Blast,

    I had originally written all code in a VB class for testing purposes so I know the code should run.

    The problem is related to reports being rendered in the ReportViewer assembly, which (I believe) is partitioned from the calling assembly.  Seems like some sort of security thing.

    The issue become giving the reportviewer assembly access (limited or otherwise) to the calling assembly.

    I played with it late into the night last night, and ultimately I broke the element class, and the reportviewer code into a separate assembly (so the support code can "see" the object definition) and added the custom assembly to both my project and the reportviewer.

    http://blogs.msdn.com/mosharaf/archive/2005/12/20/LocalReportCustomCode.aspx

    The gotcha not mentioned in the link above is that the custom code assembly need to be registered in the GAC, or stored in the following directory:
    C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\PublicAssemblies

    If you miss that step the reportviewer control will not be able to see the assembly.

    That said, now I can't seem to get the aggregate functions to work on the resulting code  : >(
    But I'll post that in a separate thread.  Hopefully it has nothing to do with my use of a custom assembly. <crosses fingers>

    Thanks
    -Jordan
    Thursday, April 3, 2008 4:44 PM

All replies


  • Still no luck on this one.

    I've been poking around and found the ExecuteReportInCurrentAppDomain property and added the following, but it still fails to recognize the Element object.

    Code Snippet

    Public Sub New()

            ' This call is required by the Windows Form Designer.
              InitializeComponent()

            ' Add any initialization after the InitializeComponent() call.

      Me.ReportViewer1.LocalReport.ExecuteReportInCurrentAppDomain(AppDomain.CurrentDomain.Evidence)


    end sub


           
    Wednesday, April 2, 2008 4:59 PM
  • First, I recommend building your methods in the actual vb compiler, and testing them.  I have an entire seperate project that I build my functions for reports in,  and I test them there before pasting them into the report.   The report is very limited in it's ability to check for problems in the "Code" window.

     

    Another thing, I'm not sure of all the limitations, but I know the code window is limited on the type of stuff you can do.  I'm not completely sure that it can handle generic collections, but I could be wrong.

     

    Thursday, April 3, 2008 2:23 PM

  • Hey Blast,

    I had originally written all code in a VB class for testing purposes so I know the code should run.

    The problem is related to reports being rendered in the ReportViewer assembly, which (I believe) is partitioned from the calling assembly.  Seems like some sort of security thing.

    The issue become giving the reportviewer assembly access (limited or otherwise) to the calling assembly.

    I played with it late into the night last night, and ultimately I broke the element class, and the reportviewer code into a separate assembly (so the support code can "see" the object definition) and added the custom assembly to both my project and the reportviewer.

    http://blogs.msdn.com/mosharaf/archive/2005/12/20/LocalReportCustomCode.aspx

    The gotcha not mentioned in the link above is that the custom code assembly need to be registered in the GAC, or stored in the following directory:
    C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\PublicAssemblies

    If you miss that step the reportviewer control will not be able to see the assembly.

    That said, now I can't seem to get the aggregate functions to work on the resulting code  : >(
    But I'll post that in a separate thread.  Hopefully it has nothing to do with my use of a custom assembly. <crosses fingers>

    Thanks
    -Jordan
    Thursday, April 3, 2008 4:44 PM