[AccessD] Any limits on what can be passed as an argument?

Thanks for the help, guys.


On Mon, Mar 11, 2013 at 3:47 PM, John W Colby <jwcolby at gmail.com> wrote:

> I assume the question regards arguments to functions.
>
> The answer is yes, but that they are passed as variants.  Variants can
> accept objects.  Object data type is just a pointer (more or less) the
> result of which is that the object reaches the other end but there is no
> intellisense available any more.
>
> Having said that any thing that you can use in a dim statement, which
> includes dao.querydeff, dao.tabledef etc can be passed strongly referenced
> (with the datatype).  The only things which cannot be strongly referenced
> are custom classes and third party controls and the likes.
>
> The answer to the second question is that since both query defs are
> stronbgly typed as a querydef object, when you do the set QD1 = QD what you
> are literally doing is setting a pointer (a memory reference) to a pointer
> (a memory reference).  Both pointers now point to the same area of memory,
> and the compiler understands that they are both a specific object type so
> they both point to exactly the same object.
>
> In vba I do not know of any method that copies just the information in the
> properties and such as opposed to the pointer itself.  There is such a
> thing in .Net.
>
> You can call any methods or set any properties of either pointer and the
> results are the same.  The object itself unloads from memory when the last
> pointer to the object is set to nothing. After that time any reference to
> either pointer will fail because all pointers to the object are set to
> nothing.
>
> That said, even though both point to the same object, if you close the
> object in one, it is also closed in the other.  This does NOT unload the
> object from memory it just closes the querydef.  A closed querydef almost
> certainly will fail trying to see some (or maybe all) properties.
>
> It sounds like either
> 1) You are setting both pointers to nothing and still trying to use one or
> the other
> 2) You are closing the object (via one or the other pointers) and then
> expecting to be able to use it from the other object.
>
> I always do something like
>
> On Error resume next
> qdf.close
> set qdf = nothing
>
> If the querydef is already closed there is no failure because of the On
> Error resume next
>
> You should ALWAYS be able to set a pointer to nothing, even if it is
> already nothing (without an error occurring).
>
> In the end though you should try and track down why the code closes the
> object before you think it is closing.
>
> John W. Colby
>
> Reality is what refuses to go away
> when you do not believe in it
>
>
> On 3/11/2013 2:12 PM, Arthur Fuller wrote:
>
>> I suppose that I could whip up a few test harnesses and discover this
>> myself, but hell, why bother in a list full of experts? :)
>>
>> I'm wondering whether virtually *anything* can be passed as an argument.
>>
>> Can I, for example, pass a QueryDef or TableDef?
>>
>> I'm also wondering exactly what happens in the following (pseudo-code)
>> example.
>>
>> <vba>
>> Dim qd as QueryDef
>> Dim qd1 as QueryDef
>> Set qd = QueryDefs("myDef")
>> Set qd1 = qd
>> ... make some changes to qd, such as changing the sql property
>> </vba>
>>
>> 1. Are changes to qd relfected in qd1? (My guess is Yes, that it's just a
>> pointer).
>> 2. If Yes, is there a method such as Clone which would NOT change qd1?
>> 3. Can I pass qd around like any other parameter?
>>
>> And finally, for reasons I won't go into, I declare a qd in the
>> Declarations of a form. In the FormOpen event, I retrieve the particular
>> QueryDef of interest and assign it to qd. In various other form events, I
>> manipulate qd. Then in the spirit of good housekeeping, I close it and set
>> it to Nothing. I've tried this code in both the Close and Unload events,
>> but in each place, Access tells me that there is no object qd. I'm not
>> sure
>> where it's disappearing but it is. I thought that declaring qd at the top
>> would mean that it's alive until I close the form, but apparently I was
>> wrong. I don't really understand what is occurring.
>>
>> Any ideas?
>>
>> Oh, before I close this, if I assign qd to qd1 as above, and then attempt
>> to close qd, am I correct in assuming that this will fail, since there is
>> a
>> reference to qd (qd1)?
>>
>> Finally, if I can pass a QueryDef as a parameter, does this mean that I
>> could pass it to a static function of the standard get/set type, and
>> therefore that it would live until I specifically killed it?
>>
>> (Which reminds me of something I heard in a Q&A session years ago:
>> Q: Do static functions continue to hold their values even if I turn the
>> computer off?
>> A: Well yes, but turning it back on wipes them out.
>>
>>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd>
> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com>
>



-- 
Arthur
Cell: 647.710.1314

Prediction is difficult, especially of the future.
  -- Niels Bohr