Common dialog control 6.0

[Mikael_Garcia]

Hi guys,
Some time ago I posted a question regarding a "Save as type" function in which you could choose file type from a drop-down list as seen in many programs today. I got an excellent answer from Brian Vibert that did the trick. However, at that time I used LabVIEW 6.02 under Windows 98. Now I am using 6.1/2K and my VI does not work anymore. The problem can be traced to the ActiveX for the Common dialog control 6.0. I have read some threads about it but the problem seems to be unsovled from what I can tell. The thing is that my ActiveX container remains empty when I add this control to it. Is this a known bug that 6.1 does not support this ActiveX control under Win2K? Any input in this matter is very welcome. Thanks.

[mikeporter]

Are you having trouble with all ActiveX contols, or just the ones from Microsoft? I had a problem sometime ago where I couldn't access Microsoft control, with the same symptom that you described. In the end it turned out to be a licensing issue of the ActiveX control. The way I "fixed" it was to install VC++ and then immediately uninstall it.

Mike...

[Mikael_Garcia]

Mike.
Good hint! I checked out some of the other MS cnrls and most of them work. But far from all of them. Other cntrls that do not work, i. e. remains empty, on my machine are (but not limited to): Progress bar ver. 5, Listview ver. 5, Image list ver. 5, Tabstrip ver. 5, Toolbar ver 5, Slider ver. 5, Statusbar ver. 5. All these are version 5 and the newer versions (6.0) work for all of them. Something is not right, that is for sure. Any more ideas? Thanks. /Mikael

[wiebe@CARYA]

Mikael,

The Common Dialog Control seems somewhat special. I got almost every COM
object working, except the Common Dialog Control...

I think the CDC is not ment to have a front panel interface. If I open it
with an "Automation Open", at least I get properties and methods. The
automation open returns an error "Class is not licensed for use". The SDK
says that an application must first call the InitCommonControl function
(void InitCommonControls(VOID)).

This did not help... I use the GetOpenFileName API instead (which has a set
of problems of it's own).

Regards,

Wiebe.

"Mikael Garcia" wrote in message
news:5065000000080000004A820000-1042324653000@exchange.ni.com...
> Hi guys,
> Some time ago I posted a question regarding a "Save as type" fun
ction
> in which you could choose file type from a drop-down list as seen in
> many programs today. I got an excellent answer from Brian Vibert that
> did the trick. However, at that time I used LabVIEW 6.02 under Windows
> 98. Now I am using 6.1/2K and my VI does not work anymore. The problem
> can be traced to the ActiveX for the Common dialog control 6.0. I have
> read some threads about it but the problem seems to be unsovled from
> what I can tell. The thing is that my ActiveX container remains empty
> when I add this control to it. Is this a known bug that 6.1 does not
> support this ActiveX control under Win2K? Any input in this matter is
> very welcome. Thanks.

[wiebe@CARYA]

Mikael,

The other Microsoft classes (treeview etc.) have caused me some trouble too.

Sorry for the confusing previous awnser...

I had some problems too, on a new, clean labtop. The strange thing was that
an LV executable was allowed to create a treeview control, but LV
development environment was not.

Mike's awnser should do the trick, but I solved it by installing office.
There is a tag in the registry that says if a PC is allowed to be developed
on. Office installs VB for Applications, and sets this tag. Installing VC++
will do the same.

But even after doing this, the Common Dialog Control does not work, while
all the other controls (treeview etc.) do work.

Regards,

Wiebe.


"Wiebe@AIR" wrote in message
news:3e9abf8c$0$157$e4fe514c@dreader8.news.xs4all.nl...
> Mikael,
>
> The Common Dialog Control seems somewhat special. I got almost every COM
> object working, except the Common Dialog Control...
>
> I think the CDC is not ment to have a front panel interface. If I open it
> with an "Automation Open", at least I get properties and methods. The
> automation open returns an error "Class is not licensed for use". The SDK
> says that an application must first call the InitCommonControl function
> (void InitCommonControls(VOID)).
>
> This did not help... I use the GetOpenFileName API instead (which has a
set
> of problems of it's own).
>
> Regards,
>
> Wiebe.
>
> "Mikael Garcia" wrote in message
> news:5065000000080000004A820000-1042324653000@exchange.ni.com...
> > Hi guys,
> > Some time ago I posted a question regarding a "Save as type" function
> > in which you could choose file type from a drop-down list as seen in
> > many programs today. I got an excellent answer from Brian Vibert that
> > did the trick. However, at that time I used LabVIEW 6.02 under Windows
> > 98. Now I am using 6.1/2K and my VI does not work anymore. The problem
> > can be traced to the ActiveX for the Common dialog control 6.0. I have
> > read some threads about it but the problem seems to be unsovled from
> > what I can tell. The thing is that my ActiveX container remains empty
> > when I add this control to it. Is this a known bug that 6.1 does not
> > support this ActiveX control under Win2K? Any input in this matter is
> > very welcome. Thanks.
>
>

[mikeporter]

sorry, no...

Mike...

[Mikael_Garcia]

Mike,
Thanks anyway. With your and Wiebes input I come to the following conclusion:
Although LabVIEW lists ActiveX controls, there seem to be no check wheter they are actually possible to use or not.

Re-installing LabVIEW or perhaps a third party software might help. But in many cases it is a lot faster to walk around the sticky problem by using a different solution all togheter. Many probably agree with the notion that either a function works right away or it is not being implemented at all (if possible). Thanks again for your thoughts Mike. /Mikael

[mikeporter]

Well certainly you have to use your judgement to determine which of two possible approaches will take longer to implement. In addition, there's always the danger that if something was fiddly to get working in the first place it might me even more fiddly to keep running--or even worse--get it running on a client's computer .

In any case, if you can do what you need without ActiveX, that would probibly be a good thing from the standpoint of reliability, reusability and transportability.

Mike...

PS: Glad I could help, the "Michaels" of the world should stick together 🙂 . Actually everybody in the world should stick together, but that's another discussion group...

[mikeporter]

Another quick note, just checked your profile and was wondering where yo are in Mass. I'm here (Sudbury area) for about 3 months on a consulting job.

Mike...

[wiebe@CARYA]

Hi,

Running it on client computers might not be a problem, if the deliverable is
an executable. You do have to make sure nicont.dll and nicontdt.dll are
registered. This does not appear to be done by the installer (LV6.0.2).

Regards,

Wiebe.


"mikeporter" wrote in message
news:50650000000500000089E70000-1042324653000@exchange.ni.com...
> Well certainly you have to use your judgement to determine which of
> two possible approaches will take longer to implement. In addition,
> there's always the danger that if something was fiddly to get working
> in the first place it might me even more fiddly to keep running--or
> even worse--get it running on a client's computer .
>
> In any case, if you can do
what you need without ActiveX, that would
> probibly be a good thing from the standpoint of reliability,
> reusability and transportability.
>
> Mike...
>
> PS: Glad I could help, the "Michaels" of the world should stick
> together 🙂 . Actually everybody in the world should stick together,
> but that's another discussion group...