Aitor Solar

Yes, but AFAIK that's not the case with dynamic called VIs. Could affect an application with continuous VI Server callings? Saludos, Aitor

Can this VI's compression affect the program's performance or speed, or is negligible? Saludos, Aitor

You can use queues and notifications to send data between independent loops. They are in the synchronization palette and are an easy solution: just send the data from any loop and wait for it in another. Queues admit any number of elements waiting to be retrieved, notifications just one. Saludos, Aitor

I think this is new: * Create a tab control * Put any two or more objects inside (let's say two boolean indicators, for example) * Group them * Ungroup * Surprise! The objects are moved down (now they are invisible and a ghost image of the old locations remains, if you refresh the image you will find the objects' new location) Reported to NI. Saludos, Aitor

Not necessarily the same VI, but between them. Here the .ctl is in fact working as a external variable, in a very simple manner. Maybe this works between different runtimes too, all accessing the same type definition. Well, OK, probably not . Saludos, Aitor

Yes, that's true. And I think the problem is located in the queue creation. If you just rewire it or wire another copy of the enum constant, the problem solves. So I suspect that first constant set to "key id" is corrupt and, from that point, LV loses a valid reference to the object and what the heck it is. In fact, if we knew how to reproduce this, it would be really interesting to change constants in run time Saludos, Aitor

I suspect is a casting problem, something usual with enums. In fact, if you explicitly typecast the constant to U16 the problem dissapears... So in some step LV doesn't know what representation is that control. Unfortunately I have no more time today, tomorrow I'll check it more deeply. Saludos, Aitor

But why the size reduction for VIs is much greater than for DLLs? DLLs are just a series of VIs, isn't it? Saludos, Aitor

Yeah, that seems correct. If OLE variants are just pointers, it's logical that closing the VI would free the memory zone. But I'm still surprised it fails trying to get the variant through the VI Server. Maybe the first application reserves that memory zone and, because of that, the second application can't read it. Or maybe just the VI server can't retrieve the pointer, the same way the flattening can't get anything. I have created a real simple dll to get the OLE variant type, and a VI to understand that type or composed type (array of whatever, for example), cast it and convert it to a usual variant, like a new "to variant" function. In fact, LabVIEW has to do something very similar in the background: if you connect the OLE variant to an indicator and select the "show type" option, you get it... but I haven't found any method to get that info programmatically. Anyway, this works great so far, though I would hope an easier solution . Saludos, Aitor

As Todd says, you can use the Matlab script node (but be careful with the running threads, as it tends to take control of the UIThread). The script node uses Matlab, so you must have Matlab installed in every PC you want to run your application. BUT if you build your application like a Matlab ActiveX server, you just need the MCR in the machine, not Matlab, and it's distributable. It's still a bit heavy, about 100Mb if I remember correctly. You'll need to compile your matlab class with the Matlab's COM Builder (as I said, I'm no Matlab expert, so everybody feel free to correct me.). This shoud create an .exe file. Execute it, it creates a dll and registers it. Go to LabVIEW and create an ActiveX object, now you should see your new class in the list of available ActiveX servers. Select the creatable object you need, instantiate it and use it through the properties and methods (all of these is in the ActiveX palette in LV). Saludos, Aitor

No, it doesn't work. In fact, if I apply a "flatten to string" to the OLE Variant and (inmediately after) an "unflatten from string", I don't recover the original, the variant value is lost. The flattened string looks just "\00\00\00\00...". The only function that works is "variant to data", anything else can't get the variant type and value. :headbang: I've tried to convert OLE variant to LabVIEW variant, using the "to variant" function, but the outcome it's still the same OLE variant . I don't know what to do. I can only see the possibility of converting the OLE Variants to their respective types and then to LV variants. The problem is: 1) That is redundant, because if I want to get a generic variant in the first program, is to convert it in the second. This way it would be: [get OLEvariant] -> [convert to type] -> [convert to LV variant] -> [get from 2nd program] -> [convert to type] :thumbdown: 2) It seems there's no easy way of knowing what type is an OLE variant, and the conversion isn't one-way. For example, an int variant can be converted to an int, to a double or to a string (I suppose it just takes the pointer and tries to adapt the memory to the data type given). Saludos, Aitor

I'm not a Matlab expert, but AFAIK, the easiest way of using Matlab from LabVIEW is to build an ActiveX server to connect with the MCR (Matlab Runtime). That way the dll would be just for Matlab internal use (and because of that will only have the ActiveX method for registering and so) and instead of them you should use the methods the automation provides (i.e.: the methods you have created for that class). Sorry if I have something wrong, I use Matlab-LabVIEW almost every day but only on the LabVIEW side . Saludos, Aitor but

Now I feel puzzled. I'm obtaining an OLE variant from an ActiveX method. That variant is (for example) an integer, so if I convert it to I32 with the "Variant to data" function all works fine. And if I connect this OLE Variant wire to a variant indicator, the indicator shows the data: "OLE Variant, Variant Type -> VTR_8, Value -> 60.000E+0". But now I need to get that OLE Variant from another LabVIEW application, using the VI Server and the "Get control value [variant]" method to retrieve the variant indicator value. Well, it doesn't work. All I get is an empty variant, even if I'm still seeing the correct variant value in the first application's front panel. All other kind of values (for example LV variants) are retrieved correctly . Maybe this sounds too convoluted. There is a more simple (and really surprising) way to see it. I create a constant from this OLE Variant (you can see it in the first image attached). All seems OK. Now I just close the VI with this constant and reopen it. And, miraculously, the variant constant has lost it's value and type (the second image) . Does anybody know what's wrong here? Saludos, Aitor

OK, it's confirmed. I'm utterly useless at this :headbang:. I have copied the llb in the right directory and it's working. Thanks. Saludos, Aitor

Ricght, I've managed to see the remote panel in Mozilla just copying NPLVWin32.dll in the Mozilla's plugins directory. But as you say, Firefox keep looking for an appropiate plugin. Strange. Maybe it's necessary to register the object type somewhere . Thanks anyway, people :thumbup:. Saludos, Aitor

I hate formats. It's an irrational but insuperable phobia of mine Saludos, Aitor

It's really easy, isnt'it? Just select the text you want in case true/false. Saludos, Aitor

That document has been deleted. What it said? It's possible to use remote panels with Mozilla the same that with Netscape? Saludos, Aitor

That won't work. Better try something like this. Saludos, Aitor

Thanks, sir. That's a good and simple idea I didn't think of. :headbang: Yes, but then I would need all the VIs follow this protocol. Something out of my hand here. Thanks, people Aitor

Well, the program shouldn't have dialogs, because it's a remote panel application. But sometimes, one pops-up (you can't control all the embedded dialogs, particularly when some VIs come from another programming team, or sometimes caused by Matlab incompabilities). So I need to detect when a dialog launches and close it. And this I have no idea. I can quit LabVIEW, but just close that specific Windows dialog... Saludos, Aitor

Why not to use a polymorphic VI, then? Saludos, Aitor

Yes, it's easily done looking the descriptors. Time ago, I prepared an evolutioned version of the OpenG method, so if the variant is an array or a cluster, it says what kind of contents has (so the answer is "array of I32" instead just "array", or "array of clusters of string, boolean, refnum", etc). I hope you'll find it useful. Keep in mind is just a VI I did for a particular purpose in a project, it's not really hard-validated. Just works for usual tasks. Saludos, Aitor Download File:post-1450-1129539061.llb

Is there any way of controlling (programmatically) a Windows Dialog popped-up by a VI? Like getting a reference to the dialog and closing it or pressing the OK button . Thanks, Aitor

I need to launch the Context Help Window in a remote panel. The problem is, the run-time menu element for Show Context Help is not exported to a remote panel. The CTRL+H shortcut still works fine, but I want to launch it programmatically, and the "Control Help Window" function launches the window in the server machine, not in the client (the same about using user32.dll and emulate the key pressing). Has anybody an idea for this? Saludos, Aitor