dcsimg
Results 1 to 5 of 5

Thread: Passing objects in the ParamArray of an ActiveDLL interface

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,139

    Passing objects in the ParamArray of an ActiveDLL interface

    I need to use ParamArray in an Activedll interface to pass object instances, for example:

    MyActiveDLL.MyClass:

    Code:
    Public Function GetRs(ParamArray P()) as boolean
    
    End Function
    The function is invoked as follows:

    Code:
    (1) MyActiveDLL.MyClass.GetRs sSQL, adoRs	'--- adoRs: ADODB.RecordSet
    
    (2) MyActiveDLL.MyClass.GetRs sSQL, sqliteRs		'--- sqliteRs: vbRichClient5.cRecordSet
    
    (3) MyActiveDLL.MyClass.GetRs sSQL, sqliteRs, adoRs
    
    (4) MyActiveDLL.MyClass.GetRs sPara1, sPara2, sPara3, sPara4, sqliteRs, daoRs
    I don't know if it's a good way. Or is there any better way?
    Last edited by dreammanor; Mar 8th, 2018 at 02:41 PM.

  2. #2
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    4,864

    Re: Passing objects in the ParamArray of an ActiveDLL interface

    Sure, what you're thinking looks perfect to me.

    Since you said DLL, I'm assuming that we're talking about an In-Process ActiveX component. Since it's in-process, it'll be sharing the same address space, so you can pass it anything you like. And since a ParamArray is a Variant array, and since Variants can hold just about anything you can throw at them (short of UDTs not wrapped in a class), what you've outlined should work just fine.

    Just remember that all your instantiation, uninstantiation, Redim, Erase rules still hold, even though you're over in another component.

    Good Luck,
    Elroy

    EDIT1: Basically, I just think of these ActiveX.DLLs as another piece of my project (very similar to a class that's actually in the main project). The only real difference I see is that they're not compiled at the same time, and, I suppose that they're registered and could be used by more than one project.

    EDIT2: Also, just to mention it, I don't even register these ActiveX.DLLs. With the assistance of some code by The Trick, I just load them directly. If you examine the attachment of post #8 in this tutorial link, you'll find the code I use to do it.
    Last edited by Elroy; Mar 8th, 2018 at 03:20 PM.
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  3. #3
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,904

    Re: Passing objects in the ParamArray of an ActiveDLL interface

    If this is for "Remote-stuff" (RPCs) - and you want flexibility (argument-wise),
    then you should use a JSON-Object as the (single) Parameter.

    Meaning, that your Method-Signature could look like that (in MyClass):
    Code:
        Public Function GetRs(jsIn As cCollection) As Byte() 'return a ByteArray here
    
           Dim Mode As enmDBMode: Mode = jsIn("Mode")
           Dim SQL As String:     SQL  = jsIn("SQL")
           'etc, for potentially more JSON-Input-Keys
    
           'and for "optional stuff" the checks could look like this:
           Dim optVal: optVal = "some default": If jsIn.Exists("OptionalProp") Then optVal = jsIn("OptionalProp")  
     
           Select Case Mode
               Case dbModeSQLite
                   Set RsSQLite = ... (a matching Cnn-based Resultset-retrieval)
                   GetRs = RsSQlite.Content
               Case dbModeADO
                   Set RsADO =  ... (a matching Cnn-based Resultset-retrieval)
                   GetRs = DisconnectAndSerializeADORs(RsAdo)
           End Select
           
        End Function
    The way I currently work with WebApps (and VB-Client-http-requests) is,
    I'm not even passing the jsIn to concrete methods (as a Parameter).

    I have a generic Method-Handler, which is retrieving the (via Ajax or WinHttp51) incoming jsIn-Parameter -
    and two of the Properties of the jsonInput are always:
    - a "Handler-ClassName"
    - and a "Handler-Methodname"

    When a new Request comes in at the Serverside (in the "generic delegator") I will:
    - instantiate the appropriate Class "by Handler-ClassName" (according to what's contained in jsIn("HandlerClassName"))
    - then I place the current jsIn-Object inside the just created Handler-Instance (per Friend-Method)
    - then I do a "CallByName" on the HandlerClass (without having to pass any Params), using the jsIn("HandlerMethodName")
    - the Handler-Class has jsIn available at Class-Level then - and does not need to pass it around (also not into SubRoutines of that Class)
    - the results of the Public method-calls of a given HandlerClass are received back in the "generic delegator"
    - and then (usually) written as ByteArray into the http-result-stream via Response.BinaryWrite (because I work with IIS/ASP currently)

    So, at the clientside (in the Browser or your VB6-client) it all boils down to (since everything works over the above described mechanism):
    - How to properly set the required Props of the jsIn-Object (which then gets passed to the Serverside either per Ajax or WinHttp5.1 in always the same way).

    HTH

    Olaf
    Last edited by Schmidt; Mar 8th, 2018 at 03:33 PM.

  4. #4

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,139

    Re: Passing objects in the ParamArray of an ActiveDLL interface

    Quote Originally Posted by Elroy View Post
    Sure, what you're thinking looks perfect to me.

    Since you said DLL, I'm assuming that we're talking about an In-Process ActiveX component. Since it's in-process, it'll be sharing the same address space, so you can pass it anything you like. And since a ParamArray is a Variant array, and since Variants can hold just about anything you can throw at them (short of UDTs not wrapped in a class), what you've outlined should work just fine.

    Just remember that all your instantiation, uninstantiation, Redim, Erase rules still hold, even though you're over in another component.

    Good Luck,
    Elroy

    EDIT1: Basically, I just think of these ActiveX.DLLs as another piece of my project (very similar to a class that's actually in the main project). The only real difference I see is that they're not compiled at the same time, and, I suppose that they're registered and could be used by more than one project.

    EDIT2: Also, just to mention it, I don't even register these ActiveX.DLLs. With the assistance of some code by The Trick, I just load them directly. If you examine the attachment of post #8 in this tutorial link, you'll find the code I use to do it.
    Hi Elroy, thanks for your reply. There are two kinds of my Activex-DLLs, one is the "In-Process" ActiveX component for local Win-Apps, and the other is Remote-stuff(RPCs) mentioned by Olaf, which is used for both Web-Apps and desktop Win-Apps .

    I read your tutorial, it's wonderful. Thank you very much.

    In addition, I think that the UtilityBank of VBForums should be merged into the CodeBank.
    Last edited by dreammanor; Mar 9th, 2018 at 06:49 AM.

  5. #5

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,139

    Re: Passing objects in the ParamArray of an ActiveDLL interface

    Quote Originally Posted by Schmidt View Post
    If this is for "Remote-stuff" (RPCs) - and you want flexibility (argument-wise),
    then you should use a JSON-Object as the (single) Parameter.

    Meaning, that your Method-Signature could look like that (in MyClass):
    Code:
        Public Function GetRs(jsIn As cCollection) As Byte() 'return a ByteArray here
    
           Dim Mode As enmDBMode: Mode = jsIn("Mode")
           Dim SQL As String:     SQL  = jsIn("SQL")
           'etc, for potentially more JSON-Input-Keys
    
           'and for "optional stuff" the checks could look like this:
           Dim optVal: optVal = "some default": If jsIn.Exists("OptionalProp") Then optVal = jsIn("OptionalProp")  
     
           Select Case Mode
               Case dbModeSQLite
                   Set RsSQLite = ... (a matching Cnn-based Resultset-retrieval)
                   GetRs = RsSQlite.Content
               Case dbModeADO
                   Set RsADO =  ... (a matching Cnn-based Resultset-retrieval)
                   GetRs = DisconnectAndSerializeADORs(RsAdo)
           End Select
           
        End Function
    Great advice, thank you very much.

    Quote Originally Posted by Schmidt View Post
    The way I currently work with WebApps (and VB-Client-http-requests) is,
    I'm not even passing the jsIn to concrete methods (as a Parameter).

    I have a generic Method-Handler, which is retrieving the (via Ajax or WinHttp51) incoming jsIn-Parameter -
    and two of the Properties of the jsonInput are always:
    - a "Handler-ClassName"
    - and a "Handler-Methodname"

    When a new Request comes in at the Serverside (in the "generic delegator") I will:
    - instantiate the appropriate Class "by Handler-ClassName" (according to what's contained in jsIn("HandlerClassName"))
    - then I place the current jsIn-Object inside the just created Handler-Instance (per Friend-Method)
    - then I do a "CallByName" on the HandlerClass (without having to pass any Params), using the jsIn("HandlerMethodName")
    - the Handler-Class has jsIn available at Class-Level then - and does not need to pass it around (also not into SubRoutines of that Class)
    - the results of the Public method-calls of a given HandlerClass are received back in the "generic delegator"
    - and then (usually) written as ByteArray into the http-result-stream via Response.BinaryWrite (because I work with IIS/ASP currently)

    So, at the clientside (in the Browser or your VB6-client) it all boils down to (since everything works over the above described mechanism):
    - How to properly set the required Props of the jsIn-Object (which then gets passed to the Serverside either per Ajax or WinHttp5.1 in always the same way).
    Hi Olaf, I haven't fully understood what you said, could you post a simple example? The flexible(argument-wise) web interface is very important to me. I don't have experience in this area and I would like to get more guidance from you. Extremely grateful.
    Last edited by dreammanor; Mar 9th, 2018 at 06:51 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width