Leaderboard

Well, I just checked it again. It has been a long time that I have worked with this but DDE Server is unfortunately not an option here using the LabVIEW DDE VIs. The LabVIEW internal DDE callback specifically refuses to receive DDE Execute commands and that is exactly the method used by the Windows shell to pass such requests to an application. You would have to implement your own DDE server in C and integrate it as DLL which I think is not a useful exercise in terms of effort required and the benefit you get. As to the solution to your problem I'm sure it has been talked about in the threads linked to from this one as well as in a previous post by me and others in this thread before. With any respect but I find this remark rather amusing. DDE is an old legacy technology. If it is any more secure than TCP/IP then only by its obscurity but certainly not by its way of implementation. DDE is a technology that origins from Windows 3.x days when applications had no seperate virtual memory and could write in each others memory anyway they wanted. Great for implementing interapplication communication schemes like DDE since you had almost nothing to do to allow that. Absolutely not so great for security. In order to make DDE work in Win32, they had to jump through many hoops and add a lot of code that does some obscure things deep in the windows event management to allow for proper operation of it. As such I would never trust it to be really secure, other than the obscurity fact, since very few people know nowadays about DDE and how to use it. The use of TCP/IP (either explicitedly or through VI server) has the advantage that everything will keep working exactly the same if you happen to use this on a non Bill Gates sanctioned OS . There is AFAIK no ActiveX server method to assign file extensions. Even if there would be an alternative that allows to invoke an application based on file extension, the LabVIEW ActiveX server would not be compatible since it only exports its own ActiveX Class Interface and not any other ones. Microsoft would for sure have designed a specifc COM interface for this, that such applications would have to expose, but as said I'm not aware of an alternative ActiveX activation based on file extensions. How things currently happen: If a file extension has a DDE Server registry entry the Windows shell simply tries to contact that server. Failing that it will launch the executable and optionally pass it the file as command line parameter (command/open verb contains the %1 parameter). If that parameter is missing it will try again to contact the application through DDE and pass it the open verb with the file path. Rolf Kalbermatter

This issue is now resolved. Everyone can report posts now. Admin edit: this post was reported successfully by Ton Plomp with the following text: "This is a test report"

The dimming is showing that the class's private data control has changes which have not been applied. As you are editing the control we don't want to constantly be recompiling and messing with other VIs because you could be doing multiple things at once, changing your mind, etc. Instead we let you make your changes and then when you save the class, close the private data control window, or choose File->Apply Changes in the private data control window then we will update all the other VIs that need to be updated. While the class is in this intermediate state it's considered broken because we don't yet know whether your changes will break other VIs, so it makes no sense to allow you to run them yet. Once you apply the changes then we can do a real check to see if anything broke, and if not then those constants stop being dimmed. None of this is JIT, though. This is all compile-time stuff. The child class is only broken because the parent class is broken, and the parent is only broken because it is in this intermediate state. As soon as you apply the changes then the parent class becomes unbroken, and thus the child class becomes unbroken as well. As long as you end up with a good (non-broken) parent class then nothing you change in the parent's private data will cause a recompile of the child class VIs. They don't even have to be in memory when you make the change, and they won't notice if they come into memory after the fact. The only thing you really need to worry about with editing the parent class is making sure that the child classes still meet all the requirements (i.e., dynamic dispatch VIs have the same connector pane). If you change the connector pane of a dynamic dispatch VI then you definitely have to modify your child classes.