ActiveX Treeview does not load in executable on target machine

[lvw]

I am using an ActiveX (Version 6.0 SP4) treeview control within my LabVIEW 6.1 application. After building an executable it works fine on the developing machine but after installation on the target machine the control is empty. Only something like 'failed to create contol' is displayed in the center of the control. Operation system is in both cases WinXP SP1. Do anyone knows how to solve this problem?

[Wiebe@CARYA]

Hi,

It took me days to figure this one out...

First, all the AX components and dependencies has to be on the machine and
registered. So copy them to windows\system32 and use regsvr32.exe to
register them. (Installing a computer with a more complete setup also seems
to make a difference, is the destination pc by any change a laptop?)

For the treeview you need:
MSComctl.ocx
MSComct2.ocx

I also needed to register some NI dll's. I'm not sure why, or even (for
sure) if this did it, but after registering the following dll's it did work.
Before I registered them, the development environment did run the treeview,
the executable didn't.

nicont.dll
nicontdt.dll

If it only has to run on one machine, you're in luck. My application could
be installed on any machine
, so I needed to automate the entire process. I
created LabVIEW executable to copy and register everything, and run the
executable automatically through the installer.

Please let us know how it works out.

Regards,

Wiebe.


"lvw" wrote in message
news:506500000008000000AFE00000-1079395200000@exchange.ni.com...
> I am using an ActiveX (Version 6.0 SP4) treeview control within my
> LabVIEW 6.1 application. After building an executable it works fine on
> the developing machine but after installation on the target machine
> the control is empty. Only something like 'failed to create contol' is
> displayed in the center of the control. Operation system is in both
> cases WinXP SP1. Do anyone knows how to solve this problem?

[lvw]

Hi Wiebe,

thx a lot for this hint. In fact the two Treeview OCX files where already in target machines system folder. So I started with the registration of NICONT.DLL via regsvr32.exe and afterwards it worked fine.

But all this seems strange to me. I have tested the application on another fresh installed WinXP SP1 target machine without even installing the RTE 6.1 (I only copy the RTE files to a subdir of my executable and point to the runtime DLLs via an entry in the corresponding INI of my application. It looks something like

[LVRT]
DLLPath=Subfoldername

The program works fine on this machine without even installing the RTE. The files NIcont*.dll you mentioned do not exist on this target machine.

So I think there must be an 3. party applica
tion on some target machines which mess up the registry. NI claims in some articles that using ActiveX is much better than working with DLLs but I cannot confirm this. When you want to create an executable you can/will end up with more problems. Normally I put my DLLs into the same folder as my executable and never had problems with this approach.

Thanks
lvw

[Wiebe@CARYA]

Hi,

Good to hear that it worked.

I don't understand it either. Perhaps registering those dll's has some
additional effects. Registering the dll's calls some dedicated functions
inside those dll's. Who knows what they do. Most likely, they add some
register keys. Perhaps you can (if you want to push your luck) delete the
dll's and see if it still works. That would mean registering them does
something that is needed... Perhaps someone at NI could answer that...

Regards,

Wiebe.


"lvw" wrote in message
news:506500000005000000D29F0100-1079395200000@exchange.ni.com...
> Hi Wiebe,
>
> thx a lot for this hint. In fact the two Treeview OCX files where
> already in target machines system folder. So I started with the
> registration of N
ICONT.DLL via regsvr32.exe and afterwards it worked
> fine.
>
> But all this seems strange to me. I have tested the application on
> another fresh installed WinXP SP1 target machine without even
> installing the RTE 6.1 (I only copy the RTE files to a subdir of my
> executable and point to the runtime DLLs via an entry in the
> corresponding INI of my application. It looks something like
>
> [LVRT]
> DLLPath=Subfoldername
>
> The program works fine on this machine without even installing the
> RTE. The files NIcont*.dll you mentioned do not exist on this target
> machine.
>
> So I think there must be an 3. party application on some target
> machines which mess up the registry. NI claims in some articles that
> using ActiveX is much better than working with DLLs but I cannot
> confirm this. When you want to create an executable you can/will end
> up with more problems. Normally I put my DLLs into the same folder as
> my executable and never had problems with this approach.
>
> Thanks
>
lvw