[AccessD] Set references via automation

 > Then, I think, all you need is a function to add the references from the full paths:

I assume I have to drop the old reference first.

 > and - when done - and this is the trick - one(1) function in a separate module to be used to 
compile and save all (other) modules:

You don't think this can be done from the C# code as well?

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 1/2/2012 3:05 AM, Gustav Brock wrote:
> Hi John
>
> Then, I think, all you need is a function to add the references from the full paths:
>
>    References.AddFromFile strFullPath1
>    References.AddFromFile strFullPath2
>    etc.
>
> and - when done - and this is the trick - one(1) function in a separate module to be used to compile and save all (other) modules:
>
> <vba>
> Option Explicit
>
> Public Function CompileAndSave()
>
>    ' Compile and Save All Modules.
>    ' The command:
>    '   Application.RunCommand acCmdCompileAndSaveAllModules
>    ' can not be used as no module is open.
>    ' Thus, use undocumented SysCmd() call.
>    Call SysCmd(504, 16483)
>
> End Function
> </vba>
>
> Call these from the AutoExec macro as the first happening:
>
> RunCode: AddReferences ()
> RunCode: CompileAndSave()
>
> This works with Access. I haven't tried (have no need) to run Access and call macros from C#.
>
> /gustav
>
>
>>>> jwcolby at colbyconsulting.com 02-01-2012 04:51>>>
>   >  I read the article as saying the same thing I was saying.
>
> Yep.
>
> What I am after is actually storing the references outside of the container, opening the container
> with C# code and deleting / (re)creating the references "on-the-fly".  The reason I want to do this
> is simply that the whole "use the reference if it is found otherwise search and recreate the
> reference" causes me (as the developer) immense problems.  I carefully set up references to specific
> paths on the C:\xyz\ directory, store the database container on the network and then... my client
> opens the file in place and the file "fixes" the broken file automagically.  Except I wanted the
> reference I had, not the reference it fixed it to.  He didn't even know that this "fix" was
> occurring and neither did I.
>
> So my objective is to download the files and the libs, open the FE, delete specific references (to
> these libs) and rebuild them, referencing the lib files in the directory that I just downloaded the
> libs to.
>
> This is a different task, though similar to just "fixing broken references".  I mean to delete the
> references and recreate them entirely, at a location of my own choosing.  And notice that I am only
> discussing just the references to my libs, I am not discussing various and sundry issues with things
> like versions of excel etc.  However it occurs to me that if I copied the excel lib to a specific
> location as well, I could fix the reference to that as well.  The whole "what version of office is
> on your machine / early / late bind" issue would suddenly become a non-issue.
>
> I just spent a looooong few days battling what turned out to be references which managed to find and
> "fix" to old outdated copies of my framework.  Who really knows what is sitting out on a user's machine?
>
> Sigh.
>
> With my new tool I will know precisely where I am putting things and fix the references to the files
> that I have just copied.
>
> It turns out to be trivial to read out the references for an access container.  Store that "one
> time" in a child table out in my tool and voila, I know where to go and get the file that is really
> needed for a given access container - even things like excel or word libs.
>
> Note I have not yet actually *done* this.  ;)  But I have the rest of the copy and run app up and
> working.  Adding this is an incremental upgrade to what I already am using.
>
> John W. Colby
> Colby Consulting
>
> Reality is what refuses to go away
> when you do not believe in it
>
> On 1/1/2012 10:00 PM, Charlotte Foust wrote:
>> John,
>>
>> I read the article as saying the same thing I was saying.  In the code you
>> run from autoexec, you disambiguate everything but the VBA call he
>> suggested is to check a particular reference to see if VBA is broken.  I
>> believe you'll find that you still need VBE to do the fixing because it can
>> be called without loading VBA.  Calling things using the VBA library in
>> disambiguated calls doesn't fix a broken reference.  You have to test each
>> reference to see which one is broken and fix it before you load VBA.
>>
>>
>> Charlotte Foust
>
>