Aitor Solar

But you can create an object if you have the type descriptor... Anyway, the problem is always the output type. You need a VI that executes when put in the BD, and that's a Xnode (a solution I don't like either). Wait a minute, what about this: have a running VI in memory that checks what you're doing in another VIs BD (easy). When you connect a wire to the "variant VI" input, this daemon reads what type of wire it is and modifies the "variant VI" output indicator to be the same as the input. That would work, but the "variant VI" should be constructed to allow its output manipullation. Do I have explained mayself? Saludos, Aitor

You can. It's hard, but just a matter of time. Use the "variant to flattened string" function with the variant input. In the type string you'll get the cluster definition, including the element types and labels. In the data string you'll get the values. There are already some VIs to get the types (including one at least in OpenG), but the part of parsing the value string can be a mess. Hope that helps. Saludos, Aitor

Well, you can set the input as variant, and anything will adapt to it. The problem arises when you want the output to be different depending on the input type (I think you'll need scripting for that). Saludos, Aitor

IIRC, in 7.1 it depends if the client is just viewing the panel or controlling it. If it's controlling, he will see the dialogs and subVIs, but not in monitor mode. The problem arises when a dialog can open before the remote panel has completed loading and the client still doesn't have control of it (the request control command is one of the last things to be processed) because in such case, the dialog will be only visible in the server machine. A solution is setting the VI first to wait until the RP is loaded before proceeding. I don't remember finding a different behaviour in 8.0, I'll test it just out of curiosity . Saludos, Aitor

Now, the connector order for each pattern (which one is the 0, the 1, etc) is pretty chaotic. Sometimes it starts from bottom-right, some from top-left... Is a mess when you are connecting dinamically created VIs Saludos, Aitor

Of course, I should have known that just because I haven't see it, doesn't mean is not everywhere :-D. What would be really great is a way to set a customised pattern in a VI, instead the predefined ones. For example, defining hot zones in a 32x32 square. As far as I know, only Xnodes can do that, but they are pretty complex for just something like that :-( Saludos, Aitor

I haven't seen this info elsewhere and I think it can be useful. Pattern code - Number of connectors 4800 - 1 4801 - 2 4802 - 3 4803 - 3 4804 - 4 4805 - 4 4806 - 4 4807 - 5 4808 - 5 4809 - 6 4810 - 6 4811 - 7 4812 - 8 4813 - 9 4814 - 10 4815 - 12 4816 - 6 4817 - 7 4818 - 8 4819 - 9 4820 - 10 4821 - 11 4822 - 9 4823 - 6 4824 - 7 4825 - 8 4826 - 10 4827 - 7 4828 - 8 4829 - 11 4830 - 4 4831 - 5 4832 - 6 4833 - 16 4834 - 20 4835 - 28 Number of connectors - Pattern codes 1 - 4800 2 - 4801 3 - 4802, 4803 4 - 4804, 4805, 4806, 4830 5 - 4807, 4808, 4831 6 - 4809, 4810, 4816, 4823, 4832 7 - 4811, 4817, 4824, 4827 8 - 4812, 4818, 4825, 4828 9 - 4813, 4819, 4822 10 - 4814, 4820, 4826 11 - 4821, 4829 12 - 4815 16 - 4833 20 - 4834 28 - 4835 Saludos, Aitor

And if it's an ActiveX dll, register it and call it like an ActiveX object. The same would apply to .NET Matlab dlls, but for some reason I haven't be able to call them from LV yet. Saludos, Aitor

The project icon editor available in LV8 (you see it when defining an application properties) allows to create .ico files for LV executables. But not programmatically, I'm afraid Saludos, Aitor

Has anybody managed to access a wire branch instead the whole wire? I have a wire that connects one source and several sinks, and I want to delete just one segment, leaving the rest intact. But I can't see how, all methods and properties refer to the whole wire, though this can easily be done manually. I could delete the wire and re-connect the source to the remaining terminals, but dinamically created wires are not really clean and it could lead to new problems . Saludos, Aitor

People use them, but they are private. You have modified "something" in your LV to use them, but officially you shouldn't see them. So, their help file is not included in the package. I wish it was, too . You can use try-and-error. Get every terminal and check its properties, as classname or classID, to find which one you're looking for. In the case you mention, surely the first two elements are the timeout inner and outer terminals, so the third one is probably the first user-defined one. Saludos, Aitor

OK, now it has more sense! I have prepared an improved version; it works fairly well, but I still detecting problems with some objects when several versions are installed . If anybody discovers something else, please tell me. Saludos, Aitor Download File:post-1450-1151580411.llb

I don't see that object (TypeLib Information Ver 1.0), but I have prepared a working tool . I think it's of easy use, I hope it's useful. 1) Click on "Generar lista" to generate the ActiveX classes list for your computer. 2) Select a class. First try to create a common class like InternetExplorer.Application for test, because depending on what registry entries have that class, the program maybe unable to create an object. If it's able, the controls in the inferior panel will be enabled and the led will be on green. If not, the led will be on red and you'll see only the registry keys the program can recover. This can be slow, depending on the machine and the number of defined interfaces. 3) Select an available interface. Not all can be created, though I don't know why yet. Select a common one for test. 4) Select an existing VI. The program will create an ActiveX refnum in that VI. It doesn't have to be open. 5) Click on "Generar objeto" to create the object. Even if you see the object, check it to see it goes to the right class. As you can see, it still needs a lot of improvement . Saludos, Aitor Download File:post-1450-1151419476.llb

Confirmed, it can be done. But it's not straightforward for all kind of objects, unfortunately. All of my objects have well defined registry entries so I have implemented an ActiveX-refnum creation wizard and it works great, but I suspect the generic way would be not searching the registry for all the data, but calling a method in the type library dll, probably DllGetClassObject, and retrieving the info directly. You will need to know the object's CLSID, its TypeLibrary and its Interface (surprisingly, that seems the really important parameter) to build the typedesc array, as the other array elements are constant. Tell me if you discover a better way of retrieving that three parameters, of if you need more info on my "experiments" . Saludos, Aitor

When you build an exe you can specify the behavior of the related VIs, like removing their front panel if you're not going to show them. But surely you already knew that, after all you have seven years of LV experience, more than myself. So I think that's not what you're asking for . When you double click a LV built-in function, you can't open it because it's not a VI. I think you are asking how to reproduce that for a VI. Am I right? Saludos, Aitor

I think this example does that before setting transparency: Make Window Tranparent Saludos, Aitor

Because, you know, all your controls are disabled Right click -> Properties -> Appearance -> Enabled state Saludos, Aitor

It's curious, I'm working right now in something very similar I haven't found any way of select the ActiveX class by scripting, because with typecasting you can only make it a generic refnum, nothing more specific. As my needs are simpler than yours (I just need to programmatically adapt an ActiveX refnum to a specific type from a reduced list), I have tried replacing it with a predefined control and, of course, it works. Not very elegant, but effective. Now, in the type descriptor you do have the CLSID of the ActiveX class, as it appears in the Windows registry (starting from position 12, I think), so I'll give it a look. Saludos, Aitor

But you don't know, from the html page, if the remote panel has control or not (or at least I haven't found how). The embedded object doesn't expose any property or method. Well, in fact you can read and change the "reqctrl" attribute, but the remote panel doesn't pay attention to that after startup . Of course, you could reload the whole page every x seconds, asking for control, but that seems a real bad solution :thumbdown:. Saludos, Aitor

That's even easier.

I can't, LabVIEW 7 & 8 don't save VIs for such an old version. But as tnt said, it is really easy. Saludos, Aitor

What do you mean, just to count the time a loop is running? Something like this? But that's not real time Saludos, Aitor

I'm glad is useful, though my improvement is really small. LV8 already has the possibility of running a VI with transparency, but I think this is more powerful, as also allows to define a specific color and, so, making "holes" in the front panel. BTW, it doesn't work with remote panels. It's obvious, since it makes a call to a local dll, but just for the record. Saludos, Aitor

I wonder what kind of communication establishes the remote panel with the server machine's LV Web Browser. Obviously, the htm file request is HTTP, but what about the inner remote-panel-to-original-VI part? I suppose it goes for the same port, but surely follows a NI private protocol. If we could "decieve" it to believe it has recieved a request control from the remote machine... :question: Saludos, Aitor

I know, I know, in fact there are more things I would change if it was in my hands. But in big projects, you usually inherit some restrictions and, in a late stage, there's no many room for changes . Not to mention a big latency affects TCP/IP too, and (if I have correctly understood what you propose) browser-embedded remote panels are not "seen" by a local LV built-in application, so I would need to launch them directly from the exe, heavily changing the program philosophy... Yep, that's what I've done. But I'm not sure it's as good as it sounds, because if the control changes state (a numeric control or a ring, for example), the predisabled copy won't change, leading to some confusing visual contradictions. And connecting copy and original control for all posible value changes in several hundreds VIs seems... well... not desirable It would be great if we could connect two controls as if they would be the same, i.e.: two visual representations in the Front Panel of the same inner control, like two locals of the same terminal in the block diagram. Anyway, thanks for all your suggestions. I know it's a pretty restricted situation, and not all possible solutions are available. Saludos, Aitor