Dear Richard,

well, we are going a little far away from the title of the original post 
are we.

I agree that using API is safe if you know how to use them. I use them
every day in C (what else can I use) and translate them in VB for me is 
very easy. But if the project is too strongly based on API, then I decide 
that VB is not worth it anymore, and I change my dll into C (but I never 
change a GUI!) Creating a ActiveX dll in C++ using ATL is as easy as in VB.

The problem I was referring is another. Is it alway safe to use API from 
VB? No, not at all. Never try to cheat COM, go against COM, or "to bypass 
all of the safety  mechanism built into Visual Basic" (Dan Appleman's: 
Developing Com/ActiveX Components with Visual Basic 6, pg 662.) Few 
examples: CreateThread, CoCreateThread, setting windows hooks and 
subclassing.

Let me quote Appleman again (from the same book, pg 661) about hooking:
"...I have serious doubts as to whatever this can be done safely (if at 
all) with Visual Basic. The cross-process hook controls provides with 
SpyWorks (one of the Appleman's products that includes also subclassing, 
ndr) are all written in C++".

I fact I wrote hooks and subclassing dll's in VB just for fun, I know that 
it is possible to do, but I much can I trust them? Our customers run our
applications for weeks without stopping, 24/7, they pay a premium for our
products because they thing we are the best in the market (with reason)
I simply cannot afford to be called because of a GPF or a run time error
because I built my app on top of a house of cards.

Marco

> It is the result of misunderstanding on the programmer's part who codes 
the
API functions improperly.  If you know exactly what the API function needs
and what it returns and under what conditions it works, then all is well.
For example, if the API is expecting a c-string type buffer (terminated 
with
a zero byte) and you send it a VB string which is not the proper length and
zero terminated, the API function is likely to do screwy things like write
overtop of your program's code destroying it.  If it does so, and the 
result
creates an infinite loop or tells the cpu to halt, then the code is
unresponsive -- if there is no wait state in the loop, your app is
hopelessly locked up.  If it results in a jump out of your application's
assigned memory, then you get a GPF (General Protection Fault) error.
Better a GPF error than allowing the code to run and send junk to a disk
controller (as my code in C did when I first learned C language!) or some
other critical device.

Similar things occur when the API expects a 2 byte integer and you sent it 
a
4 byte integer, say.  API functions can do literally what you ask them when
you do get it right.  If  you change some operating system feature, it may
persist beyond your session ---

The bottom line is that you need to understand what parameters the API call
needs and exactly what it does and what exactly what it returns.  If you 
do,
API calls are safe.

A good reference is "Visual Basic Programmer's Guide to the Win32 API" by
Dan Appleman, published by SAMS in 1999.  Also the MSDN help from Microsoft
has reasonable write ups for most of the WIN32 API which often include
sample code (usually in C language).  Dan Appleman's book carefully shows
you how to translate the C function calls into VB function calls, if you 
are
new to doing that.  He also identifies about a thousand API calls which are
useful for VB programmers complete with sample code showing how to use
them.... If you ae coding in VB.NET your world is easier.  Many of the APIs
appear in the .NET Framework. The .NET help nearly always has examples even
for API call written in VB.NET code...

Unlike some of the others on this thread, I have been successful using a
variety of embedded API calls in both VB6 and VB.NET.  However, I do not
employ them as a first choice when I can code the same functionality easily
in VB itself.  And, I do my homework: I research the API call before I use
it. Then, test it on a small test application before I put into production
code.

I have found that simply having the API arguments is not sufficient
information to reliably use API calls.... For example, API calls are added
to each windows release.  So... you need to know something of the release
history of the API call you want to use.  You need to know if the API call
references other objects you need to have available.  Some API Calls are 
not
thread safe.  etc. etc.  But, if you do your homework, the API calls you
code will work, and they will provide your applications with additional
functionality that that is useful, efficient and reliable.

Hope this helps.