Dalmady, Otto [mailto:[EMAIL PROTECTED] wrote:
>Unfortunately that's what I was expecting but I thought I would ask. >For all it's strengths, the biggest weakness I've encountered in Labview >seems to be with it's interface to other applications (on Windows). >I'm sure this is partly due to it's platform independent nature since >DLLs and ActiveX interfaces don't exist on non Windows machines. >It's too bad because we could do some really cool things if they were >better supported. Well, I do think we do quite some cool things without using ActiveX. And I do not really see to many things we couldn't do without ActiveX >I've also, in the past, had the need to register a callback function in a >DLL (non activeX) but the concept of passing a pointer to a LV function >doesn't exist. Wrapper DLLs, created using other compilers, are often >needed to solve these issues. This tends to undermine the use of LV in >the first place. Not for me. If I encounter such an issue I simply write a wrapper DLL and am done with it in a few hours. Using Active X costs me just as much time but I have never had a problem that such a DLL suddenly didn't work after having upgraded Windows or LabVIEW or even just installing an MS Office application. >I think we should include these enhancements in our LabVIEW wish list >(hope you are listening Mr McKaskle). Perhaps NI developers can somehow >tie activex into the event structure so a programmer can define events >that correspond to activeX methods. Both the event and method would be >created by the programmer. Also, allow for pointer to function capabilities >for DLL callbacks. I have some other peewees I would rather have NI spend their time with ;-) I think having Active X methods representing event states would completely obscure the event architecture in LabVIEW. I already find it less than clean the way it is now. Function pointer capabilities is another problem. It could be done in principle with a VI getting translated in a function pointer but the setup of this would be quite complex, more in fact than the current Call Library function dialog. A lot of possible problems exist with multithreading or the context in which the Callback is called, e.g. interrupt time, being some of them. Active X itself specifically distinguishes between Methods, Properties, and Events. Why go and confuse these things altogether in LabVIEW? Your mileage obviously varies but I try to avoid ActiveX as much as possible and have been quite successful in it. My reasons: - Windows only - still unstable and that is not only the problem of the LabVIEW ActiveX interface - installation issues with registration of the ActiveX server and version issues - A very complex technology to create a sort of universal interface which typically has low level changes in every new Windows version - A lot of ActiveX object developers don't understand ActiveX and consequently create unstable or unusable objects - Most "Standard" Windows objects change so often, either in their registered name or even worse in their entire Active X Object interface. - Windows only and proprietary Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
