Registering OCX controls

[NewsArchive]

Friedrich,

Today I got a support call about a program when it launches: "Unable to
set icon size for <procedure name>". This is an error thrown by the
Noyantis Codejock wrappers. I install the OCX controls and have SB
register them. The install requires admin privileges.

The target OS is Win 7 64, but its a 32-bit install, not a hybrid, nor
64-bit.

This sounds like the registration did not take, so I've asked them to
manually register the OCX (not heard back yet). Apparently, this
inherited install never worked and I'm only finding out about this
today. (I just love timely support traffic).

One thing I noticed is the installation of the EXE/DLLs is between a
Start delayed install and stop delayed install, *then* the OCX controls
are installed (and registered)

Set Delayed File Install: Stop
Install File "C:\Program Files\Codejock Software\ActiveX\Xtreme SuitePro
ActiveX v15.3.1\Bin\Codejock.CommandBars.v15.3.1.ocx" to
"%_SB_INSTALLDIR%\Codejock.CommandBars.v15.3.1.ocx" [Feat:Always
Install] [SelfReg]
Install File "C:\Program Files\Codejock Software\ActiveX\Xtreme SuitePro
ActiveX v15.3.1\Bin\Codejock.Controls.v15.3.1.ocx" to
"%_SB_INSTALLDIR%\Codejock.Controls.v15.3.1.ocx" [Feat:Always Install]
[SelfReg]
Install File "C:\Program Files\Codejock Software\ActiveX\Xtreme SuitePro
ActiveX v15.3.1\Bin\Codejock.ShortcutBar.v15.3.1.ocx" to
"%_SB_INSTALLDIR%\Codejock.ShortcutBar.v15.3.1.ocx" [Feat:Always
Install] [SelfReg]

I never used the delayed functions, would that have anything to do with
this? I'm waiting for them to manually register the OCXs to see if that
addresses this problem.

Did I provide you with enough information?
--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Hi Russ,

Not sure if this will help in the solution, but all info can be useful :-)


The "Unable to....." message does sound like its coming from the Noyantis
class - probably the 'RaiseError' method - I take it you have the general
Error Reporting checkbox turned on?

If that's the case, then the 'RaiseError' method would trigger if it was
unable to get to a raw object in order to change one of its properties.

The cause of being unable to get to the raw object could be down to a couple
of reasons:-

1 - You have passed a method (eg, SetIconSize) an incorrect Item ID (this
shouldn't be the case if the method call was generated by the template).
2 - The ActiveX control hasn't been initialised.

For the latter, it suggests that the actual ActiveX control isn't registered
on the destination PC.

Do you have the tpl set to perform the registration as well as your
installer? In my apps, I usually do both just to be on the safe side -
although I much prefer SetupBuilder to do it for me :-)
If the tpl is set to do the registration, then as long as the error
reporting option has been set on the Registration tab as well, you should
see a "Registration Failed...." message.

Hope it helps,

Regards,

Andy
www.noyantis.com

[NewsArchive]

Russ,

Are you sure that the self-registration process did not work? I would
suggest to check the uninstall .log. The following are typical uninstall
..log entries for a "self-registered" OCX:

|006|_0000_|C:\Windows\SysWOW64\myocx.dll|1|2007/04/11|.....
|030|C:\Windows\SysWOW64\myocx.dll

Do you see item |030| for your OCX in the uninstall .log?

Friedrich

[NewsArchive]

Registration by template should never happen (after playing with it).
To the best of my knowledge, no embed code for the OCX. I'm thinking
they are not telling me everything.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

I'll have to ask the installer. But I think what really happened is the
messed up the install and they have not yet told me all of the
information. I know this because I told them to do an uninstall once
and there is no log.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

> I'll have to ask the installer. But I think what really happened is the
> messed up the install and they have not yet told me all of the
> information. I know this because I told them to do an uninstall once and
> there is no log.

Hmmmmm :-(

BTW, the self-registration procedure works like this:

1. You install a file with the "Register as OCX/DLL/EXE/TLB" checkbox
marked. This will "queue" the file for later self registration.

For example:

Install File "HTTP32.dll" to "%_SB_INSTALLDIR%\HTTP32.dll" [Feat:Always
Install] [SelfReg]

2. At the end of the installation, you'll find the standard "Register all
pending file operations" function. This command will then immediately start
registering all queued files that are awaiting registration. The
registration is done by the OCX itself, not by SetupBuilder. The installer
just "executes" the self-registration function in the OCX (it loads the
library and starts the registration function; the OCX registers itself and
gives control back to the installer).

Friedrich

[NewsArchive]

Friedrich,

Thanks for the information. I just now got access to the machine,
registered it manually and the program now works. I'll need to
investigate this script. Each OCX is self-reg. And SB confirms they
are self registering.

The register all pending file operations function is there.

BTW - any ideas why a delay file install start and stop was added to
this script? The normal files from the files visualizer are in between
(except the OCX controls, they come after the stop). I'm not sure why
its there. I've removed it as I never needed this in other scripts.

If you need the script, just give me a shout.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Hi Russ,

Do you see the |030| entry in the .log? If this is the case then the OCX
registered successfully via the installer. If you only see the install file
action in the .log then the install did not execute the self-reg process or
the OCX self-reg process failed. You can send the project and I will review
it.

Friedrich

[NewsArchive]

Crap! I forgot to look! I'll check it out over the weekend when the
user is not working.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

> Crap! I forgot to look! I'll check it out over the weekend when the user
> is not working.

No problem, I'll be here :)

BTW, you should see one |006| (= install file) and a |030| (= register OXC)
entry in the uninstall .log.

|006|_0000_|C:\Windows\SysWOW64\myocx.dll|1|2007/04/11|.....
....
....
|030|C:\Windows\SysWOW64\myocx.dll

Friedrich

[NewsArchive]

Russ,

> BTW - any ideas why a delay file install start and stop was added to this
> script? The normal files from the files visualizer are in between (except
> the OCX controls, they come after the stop). I'm not sure why its there.
> I've removed it as I never needed this in other scripts.

Forgot to answer the above one. A "Start/Stop Delayed File Install" only
makes sense for web installations (or binary patches). It makes sure the
final update process is not performed unless all required files are
downloaded and all patches have been applied correctly. Otherwise, it
performs an automated rollback to the previous state.

Friedrich

[NewsArchive]

Thanks! Now that makes sense. This was not a patch situation, this is
for a new installation.

BTW - I *think* I know what happened as I glance two difference versions
of the same OCX on the system. When this script was first made, the
older version was likely installed and properly registered. But the
program uses the new version. Just checked the web update script and it
does not deploy any OCXs. That will be fixed in the next couple of minutes.

The template wrappers are version sensitive, so they were trying to use
the new version that was never registered since the old main install
script was all they had.

I'll have both scripts deployed over the weekend so version mismatches
can't happen again.

I did not think anything in SB caused this, this thread was more of a
"what else could cause this"? <bg>

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

> I did not think anything in SB caused this, this thread was more of a
> "what else could cause this"? <bg>

<BG> :-) Thanks for the update!

Friedrich

[NewsArchive]

>The template wrappers are version sensitive, so they were trying to use
>the new version that was never registered since the old main install
>script was all they had.

What does that mean consequently?

Do you have to un-register the old OCXs and register the new one?

What, if another project exists on this machine, relying on the old ones and
you actually disabled that one?



>I'll have both scripts deployed over the weekend so version mismatches
>can't happen again.

Or can two different versions co-exist on the same machine, each being
accessible for the appropriate project? (in its own
subfolder)











All that makes me faint....

Wolfgang Orth

[NewsArchive]

First of all: I have no idea what I am talking about!

What made me wonder and scared a bit is the discussion about RegFreeOCX and all
this registering efforts. Makes me want to avoid OCXs.

>The
>registration is done by the OCX itself, not by SetupBuilder. The installer
>just "executes" the self-registration function in the OCX (it loads the
>library and starts the registration function; the OCX registers itself and
>gives control back to the installer).

This sounds to to me, that - given that I use SetupBuilder - all these creepy
OCXs get registered for me and I am off.

I understand, that in case of distributing my program with OCXs, it is not a
"sort of portable" app as a normal Clarion program uses to be. Instead it will
require another install, if the user wants to move my app from one computer to
another.

If the move is just inside the same machine from C: to D:, would it matter
then? Does the OCX point to a specified folder of my EXE or is it available in
general?

Do I have to install the OCX into the system? I guess not, I _think_ the OCXs
can stay in my EXE-folder or in a separate folder beneath.

I have a weird idea to solve that OCX puzzle.

Wouldn't it be possible, that I call another EXE at startup of my Main-EXE or a
Procedure, which then checks for properly installed OCXs?


IF OCXProperInstallOkay()
DO Nothing
ELSE
dummy# = START('RegisterMyOCX.exe', 25000) ! (require Admin privileges)
END

....continue with my normal EXE now.

In this case an Admin can move around my program folder as he thinks is best
for their network and I can rest assured, that everything will still work.

Or is this just a steamy dream?

thx
Wolfgang

[NewsArchive]

Hi Wolfgang,

Registering an OCX simply means adding the appropriate Registry
entries,

> Wouldn't it be possible, that I call another EXE at startup of my Main-EXE or
> a Procedure, which then checks for properly installed OCXs?
> IF OCXProperInstallOkay()
> DO Nothing
> ELSE
> dummy# = START('RegisterMyOCX.exe', 25000) ! (require Admin privileges)
> END

so yes, you just check for the registry entries and if missing offer to
install the OCX.

RegFreeCOM means all these registry details are held in the EXEs
manifest file and the OCX(s) can live alongside the EXE.
No 'registration', xcopy deployment, no hassle - or would be no hassle
if Clarion came out of the dark ages and supported it :-(

Graham

[NewsArchive]

Wolfgang,

> This sounds to to me, that - given that I use SetupBuilder - all these
> creepy OCXs get registered for me and I am off.

The recommended method is to install the ActiveX control into the
"Windows\System32" directory (or "Windows\SysWOW64" for 32-bit controls on
Windows x64). The "Register as Shared File", "Register as OCX/DLL/EXE/TLB"
and "Check File (Version then Date/Time)" File Replacement options in
SetupBuilder will then do proper versioning and reference counting of the
OCX file and automatically execute the self-registration process. That's
all you have to do.

Then there is another strategy called "DLL/COM redirection" in Windows. An
ActiveX control can be installed in the application directory and DLL/COM
redirection is "activated" on an application-by-application basis by the
presence of a ".local" file. But the use of DLL/COM redirection strategies
is *NOT* recommended on modern operating systems (Vista, Windows Server
2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 R2).
So don't use this strategy. NEVER!

"Registration-Free Activation" is available on Windows XP and better OS
(including Win7 and Win8). This lets your application use its own copy of
the ActiveX control. You make use of an application manifest (must include
the comClass and typelib definitions) and install the OCX file into your
application directory. The ActiveX control is then automatically registered
when it is used the first time. Versioning, reference counting and
registration of the ActiveX are completely eliminated.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

--Helping You Build Better Installations
--SetupBuilder "point. click. ship"
--Create Windows 8 ready installations in minutes
--Official COMODO Code Signing and SSL Certificate Partner

[NewsArchive]

>The recommended method is to install the ActiveX control into the
>"Windows\System32" directory

In the past I could plug my USB-thumbdrive into any computer and run my programs.

That does'nt work with OCX registration anymore.

<hmmmmmpf!>



>Then there is another strategy called "DLL/COM redirection" in Windows. An
>ActiveX control can be installed in the application directory and DLL/COM
>redirection is "activated" on an application-by-application basis by the
>presence of a ".local" file. But the use of DLL/COM redirection strategies
>is *NOT* recommended on modern operating systems (Vista, Windows Server
>2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 R2).
>So don't use this strategy. NEVER!

okay okay, cool, man.... cool.... okay?



>"Registration-Free Activation" is available on Windows XP and better OS
>(including Win7 and Win8). This lets your application use its own copy of
>the ActiveX control. You make use of an application manifest (must include
>the comClass and typelib definitions) and install the OCX file into your
>application directory. The ActiveX control is then automatically registered
>when it is used the first time. Versioning, reference counting and
>registration of the ActiveX are completely eliminated.

Hmmmm, and why don't we do it that way?

Because its a bit more complicarted?

" You make use of an application manifest ...."

You do not really mean me, don't you?

no no, not _I_ make.....

So, as Graham already pointed out, SV has to come out of the closet in this case?

<sigh>

So, what can we do to get this thing going?

Wolfgang Orth

[NewsArchive]

If the templates are set for version 1 and you deploy version 2, the OCX
won't work. The opposite is also true.

Rule of thumb: If you change the version in the templates, you must
deploy the new OCX controls. IOW - ensure they always match.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

>If the templates are set for version 1 and you deploy version 2, the OCX
>won't work. The opposite is also true.
>
>Rule of thumb: If you change the version in the templates, you must
>deploy the new OCX controls. IOW - ensure they always match.

Russ,

what I meant in my question was: what if another project of another vendor uses
that "same" OCX, but other version.

I can't replace that OCX without harming the other project and I don't want
them to harm mine!

So...... keeping all my geese in my own square is the way to handle this.

Right?

Wolfgang Orth

[NewsArchive]

Wolfgang,

> what I meant in my question was: what if another project of another vendor
> uses that "same" OCX, but other version.
>
> I can't replace that OCX without harming the other project and I don't
> want them to harm mine!
>
> So...... keeping all my geese in my own square is the way to handle this.
>
> Right?

OCX files should always be "backward" compatible. So let us assume, the
target system already has OCX version 12.1.1 installed and self-registered
in the System32 folder.

In your own install, in the "Install File(s)" Conditions, you set the
Replacement Option to "Check File (Version then Date/Time). Okay, you
packaged an older OCX version 12.0.0. When the installer detects (at
runtime) the newer version on the target machine then it will not update the
OCX. Only if the OCX is "outdated" then it will replace the file. Your own
application can use the existing OCX version 12.1.1.

BTW, if an install does not handle proper versioning (and reference
counting) then the machine will run into "DLL Hell" sooner or later.

Friedrich

[NewsArchive]

>BTW, if an install does not handle proper versioning (and reference
>counting) then the machine will run into "DLL Hell" sooner or later.

Thats what I expected, but after your explanation I feel eased.

All I have to do is to be very careful when setting up the SB-script.

I am very confident in SetupBuilder!

Thanks again for your support, Friedrich.

Wolfgang Orth