[AccessD] Set references via automation

Gustav Brock Gustav at cactus.dk
Mon Jan 2 07:15:57 CST 2012


Hi John

I thought you planned to make some kind of clean install where references were not set - including the files for the libraries to be used - then add these libraries as references.
Of course, if they are already there, you would need to delete them first - should be no big deal. But if you use a fixed path for the libraries, I don't see why it should be necessary to remove and re-add these.

I don't know about macros run via automation or from the office tools for Visual Studio. By second thought, using the AutoExec macro was just convenient, it could be run from the opening form as well as long as it doesn't contain action code dependant on the new references. If so, you should be able to call the functions directly via the office tool, thus skipping the macro stuff - but again, I'm shooting in the wild, have never used it.

/gustav


>>> jwcolby at colbyconsulting.com 02-01-2012 13:39 >>>
 > 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



More information about the AccessD mailing list