Gustav Brock
Gustav at cactus.dk
Mon Jan 2 02:05:25 CST 2012
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