Peter,

thanks for the response but that's not it.

Yes I have tried late binding and get the same error, but in any case I need
to early bind because I need to declare the Winsock with events (once I have
got it working properly) and VBA will understandably not allow this unless
there is a specific object type declared as far as I can see.

As for the api call, I have no explicit proof but I know it's stopped
working the way it used to. I use the call to download new code components,
and wrote in and tested the ability to drop in new ocx or dll files. I have
used it frequently over the last year to drop an updated dll to client
machines when needed. All I know is that after a service pack in the last
few months it will no longer allow an exe, ocx or dll file to be downloaded.
I have not tested it with zip files. If you really want a way around the new
limitation, I suggest you email me privately. In answer to your last
question, this should just be limited to the api call, not an installer
package.

So, if anyone else has any ideas, please let me know.

Robin Hammond
www.enhanceddatasystems.com

"Peter T" <peter_t@discussions wrote in message
...
Hi Robin,

Have you tried late binding, eg

Dim oWS As Object
Set oWS = CreateObject("MSWinSock.WinSock")

I'm a bit alarmed by this -

I started using the winsock control because MS has changed something in a
windows api call: URLDownloadToFile such that it will no longer allow
dll,
ocx or exe files to be downloaded.

Are you saying problem to distribute an xla with its required ActiveX dll
!!!
If so, does that also apply if in a zip or packaged in some other way.

Funnily enough it is fairly easily circumvented

How ?

Regards,
Peter T



"Robin Hammond" wrote in message
...
I've trawled through everything I can find on this and no joy. I think it
is
specific to some security change in Excel 2003.

I have a Winsock control - mswinsck.ocx - installed and fully registered
on
an XP box running Excel 2003 SP1. A project reference is set to Microsoft
Winsock Control 6 (sp6). This is simply 2 lines of code that run fine on
a
different Office XP box:

Dim WS as Winsock
Set WS = New Winsock 'error here
Result: Error 429, ActiveX component can't create object.

There is no compile problem with the code, so it's not a missing
reference
per se.

Does anyone have any ideas what is causing this and how I can get it to
work?


Further thoughts:
I started using the winsock control because MS has changed something in a
windows api call: URLDownloadToFile such that it will no longer allow
dll,
ocx or exe files to be downloaded. No mention of this change anywhere
that
I
can find. Funnily enough it is fairly easily circumvented, but I'm sure
there are people wondering what's gone wrong with code that's worked for
years.

Second reason for using the winsock: it allows me to show the actual
progress of a file download and cancel out if things are going wrong. The
api call above is totally synchronous and can cause problems. I have it
working very nicely in XP, and if I can find a solution to this problem
will
post it since it's quite useful and I've seen a lot of winsock questions
in
the archives.

In the MCP excel managed newsgroup all I get is a total cop out from MS
support referring me back here. I've now tried posting there twice and it
has been no help whatsoever. The minute you mention a problem making code
work they deny responsibility and assume there's an error in the code.
All
I
can say is that it's pretty hard to find an error in two lines that work
on
one box but fail on another.

Robin Hammond
www.enhanceddatasystems.com