Rocky Smolin - Beach Access Software
bchacc at san.rr.com
Tue Aug 8 15:35:31 CDT 2006
Shamil: I tried using late binding which would work real well but partway into the code I got an error. On the statement: Set BtFormat = BtApp.Formats.Open(Me.fldFABLabelFile) I get an 'argument not optional' error - don't know why. But the reference is to the Bartender.exe, if that makes any difference. Using early binding, this code works well. To change from early to late binding I changed Public BtApp As BarTender.Application Public BtFormat As BarTender.Format to Public BtApp As Object 'BarTender.Application Public BtFormat As Variant 'BarTender.Format and then in the load event: Set BtApp = CreateObject("BarTender.Application") There is no object model for Bartender so I don't know what it is expecting for BtFormat. But late binding would solve the problem. Any ideas? If I want to try your other solution I'll have some questions. It's a bit past my capabilities. Thanks and regards, Rocky Shamil Salakhetdinov wrote: > Rocky, > > I still think the easiest and the most reliable solution for your case is to > use late binding. Did I miss something in this thread - why it didn't work > for you? > > If you decide to not use late binding and if remove reference doesn't work > for you - then you can use Add Reference (anyway your intention to use > Remove Reference forces your FE to loose its compiled state as well as Add > Reference does). > > I mean the following: > > - put all your bar code printing code into a separate library/utility > database, set reference to bar code printing library in this database; > > - in your FE keep the code to check is it possible to create bar code > printing object or not; > > - if it's possible to create bar code printing object then add reference to > its library (code to add reference MUST BE kept in another library database > - if executed in FE such will force FEs global vars to loose their values); > > Etc. > > This above is a flexible solution but its above description isn't a full > story - in this case if your FE uses global variables then you have to > create another "proxy" FE to keep start-up code, (dynamic) references, > commandbars... and use your current FE as a library database - then > CurrentDb if you use it becomes a problem etc. > > This above technique works very well - it was used in real life apps here > and there back to the years 1998-2000 but program databases and their code > should be refactored to be used within this technique.... > > It's very shortly described here - "A method to modularize MS Access > applications" - http://smsconsulting.spb.ru/shamil_s/downloads.htm > > But applying it for your case looks like using "cannons to shoot at > nightingales" - why not use simple and effective late binding? > > -- > Shamil > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin - > Beach Access Software > Sent: Tuesday, August 08, 2006 11:45 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Removing a missing reference > > Marty: > > Access.References.Remove refCurr still generates error: -2147319779 - Object > library not registered. > > Rocky > > > > > -- Rocky Smolin Beach Access Software 858-259-4334 www.e-z-mrp.com