Common Dialog Activex control not loading

[bostonscot]

Hi, I am developing an application for distribution using labview 6.1. I have been using MS common dialog control (for file open) on my development system (windows XP, with VB6 installed as well). This is working well, both during debug and as an executable. However when I transfer to a different machine it sometimes fails. During debug on this other machine the control shows "control could not be loaded". This looks like a registration issue. However: 1) I have reregistered comdlg32.ocx using regsvr32 and it reregisters fine; 2) I have an identical .ocx on both the development and problem machine; 3) I can build an executable in VB6 that calls the common dialog file open....and it works fine on both systems. Am I missing s
omething obvious? Neither MS KB or the NI KB appear to have anything to recommend other than reregistering. Help!!

[John_Howard]

I have had similar problems myself, and to date haven't found any explaination for this behaviour. One symptom of the behaviour is that on the faulty machines, if you try to drop a common dialog control into an active-x container, nothing happens. Nothing I tried ever fixed the problem (including re-installing LabVIEW), until finally I got a new computer.

Sorry I don't have better news for you. Personally, I think there is some obscure bug in the LabVIEW active-x client.

[bostonscot]

After some time I think I can actually hazard a guess as to what is going on here. What it appears to be is that although the ocx is registered correctly, the user has to be using a system where the activex control is _licensed_ correctly to embed it in labview code. Running on a machine with VB6 development, this occurs automatically, but this doesn't appear to be neccessarily true with just labview. I "solved" this in the end by using a VB wrapper for the control (as suggested by microsoft: http://support.microsoft.com/default.aspx?scid=kb;en-us;281848). This solution worked....but when I reverted to the old technique of using the activex container directly.....this had been fixed as well....not sure whether this is a NI or microsoft issue?!

[Wiebe@CARYA]

Hi,

I've seen some examples in assembler, and the only thing that is done extra
is a call to InitCommonControls. It's obvious that assembler doesn't do
anything automatically. So my best guess it that it works for executables,
but perhaps not for 'just' any programming environment. Have you ever tried
to run an example as an executable (even if it didn't run during
development)? I've seen examples where LV didn't run AX properly, but an
executable of the same code did run ok (and visa versa).

It is still weird that only CommonControls is acting this way. It sould be
one of the easiest components!

Regards,

Wiebe.


"Gavin Braithwaite" wrote in message
news:506500000005000000D5650100-1078497998000@exchange.ni.com...
> After some time I thin
k I can actually hazard a guess as to what is
> going on here. What it appears to be is that although the ocx is
> registered correctly, the user has to be using a system where the
> activex control is _licensed_ correctly to embed it in labview code.
> Running on a machine with VB6 development, this occurs automatically,
> but this doesn't appear to be neccessarily true with just labview. I
> "solved" this in the end by using a VB wrapper for the control (as
> suggested by microsoft:
> http://support.microsoft.com/default.aspx?scid=kb;en-us;281848). This
> solution worked....but when I reverted to the old technique of using
> the activex container directly.....this had been fixed as well....not
> sure whether this is a NI or microsoft issue?!

[bostonscot]

Wiebe,
yes the problem was pretty persistent even on executables generated by the App builder. Still not totally happy with the "solution"!