reference question

[Mark Andrews]

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).

Thanks in advance for help,
Mark

 

[Douglas J. Steele]

Doesn't the vendor have any recommendations?

The best solution would be to use Late Binding if that's possible.

 

[Mark Andrews]

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]

I did a Bing on "regtlb.exe", and the first hit was
http://www.freevbcode.com/ShowCode.Asp?ID=2195

 

[Tony Toews [MVP]]

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.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[Mark Andrews]

Thanks, not sure why I wasn't finding it?

I did a Bing on "regtlb.exe", and the first hit was
http://www.freevbcode.com/ShowCode.Asp?ID=2195

 

[David W. Fenton]

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).

 

[David W. Fenton]

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.

 

[Tony Toews [MVP]]

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.

That said I have no idea what COM really means.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[Mark Andrews]

David,

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.

Thanks,
Mark

 

[Tony Toews [MVP]]

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.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[David W. Fenton]

That said I have no idea what COM really means.

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 might want to read this:

http://en.wikipedia.org/wiki/Component_Object_Model

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.

 

[David W. Fenton]

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?

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:

http://www.granite.ab.ca/access/email.htm

It's a very problematic area because MAPI has actually never been
very good at all.