Just wrote a little test app and tried to install it on another machine.
Uses the TCP component that shipped with Delphi 2 (from NetManage).  I get
EOleSysError  - class not registered when I try to run it.  Ran fine on the
development system so I assume there's something missing.  Used
Installshield that came with D2.
Can you tell me what's wrong?

You can use code I have taken from delphi 3 demo dir and it is posted in
comp.lang.pascal.delphi.announce but for the line thet generate internal
error (if this line do then in delphi 2) you can set it to string (not an
array) DllReg.... I do not remember how it goes.

Just in case:
Procedure RegCFX;
Type
  TRegProc = function : HResult; stdcall;
  TRegAction = (raReg, raUnreg);

Const
  ProcName : Array[TRegAction] Of PChar = ('DllRegisterServer',
'DllUnregisterServer'); <-- I This line produce INTERNAL ERROR URW376 when
not using debug info ???!!!
// ProcName : PChar = 'DllRegisterServer';  <-- this line if internal error
shows in D2
  SFileNotFound = 'File "%s" not found';
  SCantFindProc = '%s procedure not found in "%s"';
  SRegFail = 'Call to %s failed in "%s"';
  SLoadFail = 'Failed to load "%s"';
  SRegSuccessful = 'Call to %s was successful!';
  SRegStr = 'registered';
  SUnregStr = 'unregistered';
  STlbName = 'Type library name: %s';
  STlbGuid = 'Type library GUID: %s';
  STlbRegSuccessful = 'Type library successfully %s!';
  SCantUnregTlb = 'The version of OLEAUT32.DLL on this machine does not ' +
    'support type library unregistration.';

Var
 FileName : String;
 RegProc : TRegProc;
 LibHandle : THandle;
Begin
  FileName := ExtractFilePath(Application.ExeName) + 'cfx32.ocx';
  LibHandle := LoadLibrary(PChar(FileName));
  If LibHandle = 0 Then raise Exception.CreateFmt(SLoadFail, [FileName]);
  Try
    @RegProc := GetProcAddress(LibHandle, ProcName[raReg]);
    If @RegProc = nil Then
      raise Exception.CreateFmt(SCantFindProc, [ProcName[raReg],
FileName]);
    If RegProc <> 0 Then
      raise Exception.CreateFmt(SRegFail, [ProcName[raReg], FileName]);
  finally
    FreeLibrary(LibHandle);
  End;
End;

--
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Regards to You all from

Igor Colovic, Belgrade, Yugoslavia, Europe

ci...@EUnet.yu

Bob Bain <proto...@mail.ameritel.net> wrote in article
<6b8df2$ol...@kronos.crosslink.net>...

OK, let's go one further.  After getting rid of the stupid messages I tried
to install the app on a target machine.  Now I've got another problem.  The
ISP controls are OCX's and I can't find any info on deployment.  How the
heck do I get the OCX's to the target machine.  I don't even know which
OCX's are used, much less how to install them.  Installshield doesn't seem
to pick up on the need for the OCX's by itself, so how do I do this?  This
probably sounds pretty stupid to you guys, but I've never used OCX's before
so I'm pretty lost here.  BTW, I downloaded Francois's stuff but there isn't
any documentation (not that it's that complicated to use).

Bob Bain

Come on Bob, get a clue!

Bob,
NO offense meant, but that's the problem with OLE, COM, DCOM and
ActiveX. It may work, or it may not work, but you'll never know WHY or
HOW.  It may work on this machine today, but not on another tomorrow.
You may get it to work, until MS stuffs your machine with the latest
version of xyz.dll .  Really high-tech...
Wish you luck. You'll need it...

Your problem occured because TCP component is in fact an
ActiveX Control. It must be registered in the registry of
the Windows 95/NT, in the section named"HKEY_CLASSES_ROOT".
To view the registry you can use regedit / regedit32 program
that comes with Windows, or an alternative viewer like "OLE VIEW" or "OLE
OBJECT EXPLORER"(comes with Ole Enterprise).

Grigory Balantsev
Delphi enthusiast from Russia.

Bob Bain <proto...@mail.ameritel.net>
<6b8df2$ol...@kronos.crosslink.net>...

Actually, this isn't a MICROSOFT problem at all.  NetManage produced the
components that BORLAND shipped with Delphi 2 in the Internet Solutions
Pack.  While I use Borland's development tools almost exclusively, I have
great respect for Microsoft.  I have NO respect for Microsoft bashers at
all.  While MS may have it's shortcomings and downfalls, if it were not for
them you'd be using Unix or DOS or a Mac or who knows what - but Windows IS
a great  product in terms of what it does and it's acceptance.  I've since
figured out all my deployment problems with the ISP components, and may or
may not use them in the future, but it has NOTHING to do with MS.  Most of
the problems I had with them came from NetManage and Borland - but I'll
continue to use Borland's products as well.  Much like MS, I have great
respect for Borland, too.

Bob Bain

If MS would have made it's OLE/COM/DCOM/ActiveX interfaces stable
*BEFORE* they put it on the market, then Borland's components would
not have given you this problems.
It's always the same game: they distribute beta's , wait for the bug
reports, change all & everything, and then have everybody waiting for
the final release, until *their* products based on it are released.
Really nice.

| While I use Borland's development tools almost exclusively, I have
|great respect for Microsoft.I have NO respect for Microsoft bashers
at
|all.

Your choice.

 While MS may have it's shortcomings and downfalls, if it were not for
|them you'd be using Unix or DOS or a Mac or who knows what - but
Windows IS
|a great  product in terms of what it does and it's acceptance.

I agree on Win95 and  NT, specially NT (really: hat off!) . Before
that it was a *very* flaky business.

 I've since
|figured out all my deployment problems with the ISP components, and
may or
|may not use them in the future, but it has NOTHING to do with MS.
Most of
|the problems I had with them came from NetManage and Borland - but
I'll
|continue to use Borland's products as well.  Much like MS, I have
great
|respect for Borland, too.
|

I will further clarify on my aversion for OLE & derived products. I've
been writing software for industrial applications for some 15 years
now. Most of them were "mission-critical" apps (data communication)
that were supposed to be as robust as was practically feasible. With
DOS , this was possible. With WIN3.x, it became more difficult. I
really liked the Borland approach : one EXE that does it all , no
depending on version 1.25a of xyz.DLL or whatever. OLE and its
derivatives may be nice for linking Word to Excel. If things screwed
up, it was just bad luck.

I cannot let my apps  depend on some technology that works simply
*flaky* and *unreliable* , is still *immature* , and depends on too
many black boxes. Let the facts speak for themselves: these newsgroups
are flooded daily with "HELP! OleSysError" , "HELP: class not
registered!", "HELP! It works on my PC, but not on another"
Can you simply grasp what this kind of *misery* means to a large
company with some 2000 PC's installed??
If you call this bashing , that's OK with me, but I honestly think
it's at least based on some hard facts.

Dirk,
I agree with pretty much all of what you've said.  My points were: 1) the
specific problem was not Microsoft related but rather Borland / NetManage
related.   2) I definitely appreciate Microsoft's products, and these days
there's WAY too much bashing going on.  So far as OLE goes, yes - it has
it's downfalls and problems, but eventually it will be the way to go.  I
fully understand the implications of potential failures and their associated
costs.  In the earlier DOS days there were similar problems.  This is a
natural progression.  Use of third party components can be dangerous, OLE or
not, but it's still a fact of life these days.  It's just not cost effective
to re-invent components.

Bob

Spending a lot of cash help doing good products. But if good means used
by everybody, MS is doing good products.

When i'm doing an app for a customer, i don't accept any bug. Because i
know that the customer will not accept to work with me anymore.

[very large snip]

 I hated Windows 3.x, at least from a developers point of view.  It
|was a very buggy and unstable platform and lacked the features and
|capabilities inherent in typical multitasking systems.  I used to
really cho
|ke when people talked about "multitasking" with Windows.  I don't
{*word*88}
|anymore.  Windows 95, 98, and NT are a quantum leap forward from 3.x
NT is,
|in fact, a leap forward from Unix in my opinion (hold the flames,
please -
|just my opinion).
[snip]
NT was far more than Mom and Pop could handle, but
|95 seemed manageable.  NT 5 will close the gap significantly, and
users will
|soon migrate to NT.  I expect 95 (98) to be around until NT becomes
usable
|by the general public, then 95 will fade away.  DOS will probably
live for a
|long time, primarily to support embedded controller applications.

I absolutely agree. When I like something from Ms, I'll say it too.
The whole migration process Win3.x >> WIN95 >> NT/WIN98 was/is a
technical masterpiece of a dazzling complexity. But one of the deeper
reasons  I launched the "See? OLE works great" posting , was that I'd
like to see MS for once & for all draw a clear , solid line  between
"this is OS land", and "App country starts here".
-I dislike sayings like "Explorer is an integral  part of your OS",
because this is just *one* little step from "to have this or that to
work, you *should* have Explorer"

- Example from the real world: myself and 9 collegues at work signed
up with a new ISP, including a free copy of IE4, and an "automatic"
installation/signup/ configuration  program.
I'll spare you the gruesome details, but *6* out of 10 (not including
me :^) )had *very* serious troubles before they got things were
working again. It is simply unacceptable that your whole *system* has
to be rebuild to have an *app* working.
That is what I mean by : MS should draw a clear borderline and stick
to it.