I want to use Ostrosoft's SMTP component in a product that many people will have to install.
Their newest product consists of a DLL and a TLB file.
If I put both files in the application directory and set a reference to the TLB file everything works fine.
Wondering the best approach to use: - Can I set a reference and it will still work if files are in application directory? Even if user installs application in different directory? - Can I set the reference at runtime? - should both files be in windows\system32? Would rather not have to register anything if not needed.
I cannot rely on Outlook to be installed for emailing, so I need a third party smtp (also I like a lot of the features of this product).
>I want to use Ostrosoft's SMTP component in a product that many people will >have to install.
> Their newest product consists of a DLL and a TLB file.
> If I put both files in the application directory and set a reference to > the TLB file everything works fine.
> Wondering the best approach to use: > - Can I set a reference and it will still work if files are in application > directory? Even if user installs application in different directory? > - Can I set the reference at runtime? > - should both files be in windows\system32? > Would rather not have to register anything if not needed.
> I cannot rely on Outlook to be installed for emailing, so I need a third > party smtp (also I like a lot of the features of this product).
They are difficult to get an answer from and they deal mostly with people using .net.
I think I was mistaken and I do need to register the type library. I had the old library registered and certain code was still working off the old library.
I believe some of the functionality I'm using requires early binding. The old product was just a dll (but they indicate they don't support activeX anymore only COM on the new product).
Different question: Know of any good ways to register a type library. I think I need Regtlb.exe and it's not on this Vista machine. Know of a good place to find it?
> The best solution would be to use Late Binding if that's possible.
> -- > Doug Steele, Microsoft Access MVP > http://I.Am/DougSteele > (no e-mails, please!)
> "Mark Andrews" <mandrewsNOS...@rptsoftware.com> wrote in message > news:OJVPymkXKHA.5368@TK2MSFTNGP02.phx.gbl... >>I want to use Ostrosoft's SMTP component in a product that many people >>will have to install.
>> Their newest product consists of a DLL and a TLB file.
>> If I put both files in the application directory and set a reference to >> the TLB file everything works fine.
>> Wondering the best approach to use: >> - Can I set a reference and it will still work if files are in >> application directory? Even if user installs application in different >> directory? >> - Can I set the reference at runtime? >> - should both files be in windows\system32? >> Would rather not have to register anything if not needed.
>> I cannot rely on Outlook to be installed for emailing, so I need a third >> party smtp (also I like a lot of the features of this product).
> They are difficult to get an answer from and they deal mostly with people > using .net.
> I think I was mistaken and I do need to register the type library. I had > the old library registered and certain code was still working off the old > library.
> I believe some of the functionality I'm using requires early binding. The > old product was just a dll (but they indicate they don't support activeX > anymore only COM on the new product).
> Different question: > Know of any good ways to register a type library. I think I need > Regtlb.exe and it's not on this Vista machine. Know of a good place to > find it?
> Mark
> "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_gmail.com> wrote in message > news:Oj8VuukXKHA.4360@TK2MSFTNGP04.phx.gbl... >> Doesn't the vendor have any recommendations?
>> The best solution would be to use Late Binding if that's possible.
>> -- >> Doug Steele, Microsoft Access MVP >> http://I.Am/DougSteele >> (no e-mails, please!)
>> "Mark Andrews" <mandrewsNOS...@rptsoftware.com> wrote in message >> news:OJVPymkXKHA.5368@TK2MSFTNGP02.phx.gbl... >>>I want to use Ostrosoft's SMTP component in a product that many people >>>will have to install.
>>> Their newest product consists of a DLL and a TLB file.
>>> If I put both files in the application directory and set a reference to >>> the TLB file everything works fine.
>>> Wondering the best approach to use: >>> - Can I set a reference and it will still work if files are in >>> application directory? Even if user installs application in different >>> directory? >>> - Can I set the reference at runtime? >>> - should both files be in windows\system32? >>> Would rather not have to register anything if not needed.
>>> I cannot rely on Outlook to be installed for emailing, so I need a third >>> party smtp (also I like a lot of the features of this product).
"Mark Andrews" <mandrewsNOS...@rptsoftware.com> wrote: >I want to use Ostrosoft's SMTP component in a product that many people will >have to install.
>Their newest product consists of a DLL and a TLB file.
>If I put both files in the application directory and set a reference to the >TLB file everything works fine.
>Wondering the best approach to use: >- Can I set a reference and it will still work if files are in application >directory? Even if user installs application in different directory? >- Can I set the reference at runtime? >- should both files be in windows\system32?
You might need to register the tlb file on your machine. I don't know much about tlb files though. But my limited understanding is that the tlb file is just for development purposes and you don't need to distribute it.
Also I don't you can register a DLL so it should be enough to include it in the same folder at your users.
This kind of stuff should be tested using a virtual machine such as Virtual PC or VMWare or others. They make testing this very easy. Tip. Create a new OS install in the VM. Once it's setup, has all the patches and anti virus installed shut it down. Make a copy of the virtual hard drive and install your program into the copy. Test away for a while. Once you've decided you've "polluted" this VM delete it and make a fresh copy of the virtual hard drive.
> -- > Doug Steele, Microsoft Access MVP > http://I.Am/DougSteele > (no private e-mails, please)
> "Mark Andrews" <mandrewsNOS...@rptsoftware.com> wrote in message > news:uW726elXKHA.4808@TK2MSFTNGP06.phx.gbl... >> They are difficult to get an answer from and they deal mostly with people >> using .net.
>> I think I was mistaken and I do need to register the type library. I had >> the old library registered and certain code was still working off the old >> library.
>> I believe some of the functionality I'm using requires early binding. >> The old product was just a dll (but they indicate they don't support >> activeX anymore only COM on the new product).
>> Different question: >> Know of any good ways to register a type library. I think I need >> Regtlb.exe and it's not on this Vista machine. Know of a good place to >> find it?
>> Mark
>> "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_gmail.com> wrote in message >> news:Oj8VuukXKHA.4360@TK2MSFTNGP04.phx.gbl... >>> Doesn't the vendor have any recommendations?
>>> The best solution would be to use Late Binding if that's possible.
>>> -- >>> Doug Steele, Microsoft Access MVP >>> http://I.Am/DougSteele >>> (no e-mails, please!)
>>> "Mark Andrews" <mandrewsNOS...@rptsoftware.com> wrote in message >>> news:OJVPymkXKHA.5368@TK2MSFTNGP02.phx.gbl... >>>>I want to use Ostrosoft's SMTP component in a product that many people >>>>will have to install.
>>>> Their newest product consists of a DLL and a TLB file.
>>>> If I put both files in the application directory and set a reference to >>>> the TLB file everything works fine.
>>>> Wondering the best approach to use: >>>> - Can I set a reference and it will still work if files are in >>>> application directory? Even if user installs application in different >>>> directory? >>>> - Can I set the reference at runtime? >>>> - should both files be in windows\system32? >>>> Would rather not have to register anything if not needed.
>>>> I cannot rely on Outlook to be installed for emailing, so I need a >>>> third party smtp (also I like a lot of the features of this product).
> I don't know > much about tlb files though. But my limited understanding is > that the tlb file is just for development purposes and you don't > need to distribute it.
I'm pretty sure (but could not confirm it with a bit of Googling) that the TLB file is a wrapper around a COM library the purpose of which is to support high-level IDE functions like the Object Browser and Intellisense in the VBE. The absence of a TLB file does not preclude the use of the underlying functionality of the COM library it is a wrapper around -- it's just less user-friendly for those use MS IDEs (or any other IDE that knows how to use a COM TLB file).
> They are difficult to get an answer from and they deal mostly with > people using .net.
> I think I was mistaken and I do need to register the type library. > I had the old library registered and certain code was still > working off the old library.
> I believe some of the functionality I'm using requires early > binding.
If it's registered, it should be usable via late binding. However, it may not work as well (depending on what it does and how it's structured). It's really a matter of finding what top-level object you're using with CreateObject("My.Application"), and some registry browsing can find that.
What I usually do is use early binding for development and to figure out the object model, and then convert to late binding for production use. Sometimes I'll maintain a separate MDB with the reference so that during development after conversion to late binding I don't have to add the reference back to my production database.
> The > old product was just a dll (but they indicate they don't support > activeX anymore only COM on the new product).
That's gibberish. "ActiveX" is just a rebranding of "COM" which was a rebranding of "OLE." A DLL may or may not be a full COM object ("COM" is the winner after all of these years, and it's what everyone uses to refer to the technology) -- depends on what interfaces it supports.
> Different question: > Know of any good ways to register a type library. I think I need > Regtlb.exe and it's not on this Vista machine. Know of a good > place to find it?
The Access VBE's references browser will register a TLB file if it's not already, just as if you point at an unregistered (and registerable) DLL, it will register that without running REGSVR32.
"David W. Fenton" <XXXuse...@dfenton.com.invalid> wrote:
>> I don't know >> much about tlb files though. But my limited understanding is >> that the tlb file is just for development purposes and you don't >> need to distribute it.
>I'm pretty sure (but could not confirm it with a bit of Googling) >that the TLB file is a wrapper around a COM library the purpose of >which is to support high-level IDE functions like the Object Browser >and Intellisense in the VBE. The absence of a TLB file does not >preclude the use of the underlying functionality of the COM library >it is a wrapper around -- it's just less user-friendly for those use >MS IDEs (or any other IDE that knows how to use a COM TLB file).
Ok, that makes some sense. I'm using a TLB file in the Auto FE Updater for reading and creating shortcuts.
>> They are difficult to get an answer from and they deal mostly with >> people using .net.
>> I think I was mistaken and I do need to register the type library. >> I had the old library registered and certain code was still >> working off the old library.
>> I believe some of the functionality I'm using requires early >> binding.
> If it's registered, it should be usable via late binding. However, > it may not work as well (depending on what it does and how it's > structured). It's really a matter of finding what top-level object > you're using with CreateObject("My.Application"), and some registry > browsing can find that.
> What I usually do is use early binding for development and to figure > out the object model, and then convert to late binding for > production use. Sometimes I'll maintain a separate MDB with the > reference so that during development after conversion to late > binding I don't have to add the reference back to my production > database.
>> The >> old product was just a dll (but they indicate they don't support >> activeX anymore only COM on the new product).
> That's gibberish. "ActiveX" is just a rebranding of "COM" which was > a rebranding of "OLE." A DLL may or may not be a full COM object > ("COM" is the winner after all of these years, and it's what > everyone uses to refer to the technology) -- depends on what > interfaces it supports.
>> Different question: >> Know of any good ways to register a type library. I think I need >> Regtlb.exe and it's not on this Vista machine. Know of a good >> place to find it?
> The Access VBE's references browser will register a TLB file if it's > not already, just as if you point at an unregistered (and > registerable) DLL, it will register that without running REGSVR32.
"Mark Andrews" <mandrewsNOS...@rptsoftware.com> wrote: >Thanks for the info. You wouldn't want to take a look at >http://www.ostrosoft.com/smtp_component.asp >and help me figure out the best way to use this component?
>Would love to figure out a way that I don't need to register it (and just >include the files in the directory the front-end db lives).
>I would think using something like this component would help tons of people >struggling with emailing from Access as well.
Download the Using with Visual Basic example and poke about with Notepad. In particular note the references, it has quite a few.
But be advised that when I ran it in VB 6.0, with the DLLs in the directory, I got the following message ActiveX component can't create object And that was with the OSSMTP_Plus DLL and tlb in the same folder as the VB 6 source code. So it may require registering anyhow.
Er, Office has been entirely based on it since at least 1994 (the registry existed back in the day for coordinating OLE in that version of Office) and all versions of Windows since Win95 have it fully baked in at all levels.
You're using COM all the time -- it's the entire basis for references in Access, as well as for late binding (which depends on COM registration of the components you're using). The Windows System registry is the heart of COM, because it defines all the relationships between the components.
The first line of the cited page explains why you are having problems. It says:
OstroSoft SMTP Component is a .NET library
.NET is not COM and that's why it doesn't work well with COM.
For it to work, it has to have a COM wrapper somewhere to expose it's interfaces in COM-compatible format.
I would stick with COM-only for Access development if I were you.
I also wouldn't use outside libraries for email. If I were contemplating sending email without automating Outlook, I'd likely do it straight MAPI. It's very difficult, but you'd not be dependent on somebody else's components to make it work. Tony has a page on email that lists all the alternatives for sending email from Access:
|
