[AccessD] Removing a missing reference

Martin Reid mwp.reid at qub.ac.uk
Wed Aug 9 02:55:00 CDT 2006


Rocky
 
Tricias sister is living in Vancouver island. WIll you be over there?
 
Martin
 
Martin WP Reid
Training and Assessment Unit
Riddle Hall
Belfast
 
tel: 02890 974477
 

________________________________

From: accessd-bounces at databaseadvisors.com on behalf of Rocky Smolin - Beach Access Software
Sent: Wed 09/08/2006 04:39
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Removing a missing reference



I'll be damned.  Who knew?

When all else fails, read the manual?

I owe you a beer or maybe two. Or three.  (I owe Shamil a gallon of
Vodka as well).  Might be able to pay off the debt as well next week. 
We're in Vancouver for the week.  And are planning a day trip to
Victoria.  Maybe we can say hello.

Best,

Rocky



MartyConnelly wrote:
> All the docs on the calls are in  C:\Program
> Files\Seagull\BarTender\7.74\Automation.chm
> The VB.Net code is  almost same as VBA except instantiation.
>
> This runs and prints
>
> Sub testbar()
> 'Declaring a BarTender application variable
> Dim btApp As Object
> 'Declaring a format variable
> Dim btFormat As Object
> 'Instantiating the BarTender object
> Set btApp = CreateObject("BarTender.Application")
> 'Setting the BarTender Application Visible
> btApp.Visible = True
> 'Setting the BarTender format to open
> 'the .btw template file might have to be previously saved from Bartender
> Set btFormat = btApp.Formats.Open("c:\temp\Format1.btw", False, "")
> 'Printing the label format
> Dim lRet As Long
> lRet = btFormat.PrintOut(True, True)
> 'Ending the BarTender process
> btApp.Quit (BarTender.BtSaveOptions.btDoNotSaveChanges)
> End Sub
>
>
>
> Rocky Smolin - Beach Access Software wrote:
>
>  
>> 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

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com <http://www.databaseadvisors.com/> 




More information about the AccessD mailing list