Jump to content

Aitor Solar

Members
  • Posts

    259
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Aitor Solar

  1. 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

  2. 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

  3. 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

  4. I haven't seen this info elsewhere and I think it can be useful.

    post-1450-1157021964.gif?width=400

    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

  5. I have not looked at the code yet for these editors. I have been toying a little with LabVIEW 8.0 this week and am going to download LabVIEW 8.2 today as I have SSP subscription. Anyhow, what would be needed is a way to programmatically make 16-color and 2-color 32 x 32 and 16 x 16 icons, and the ability to save as .ico file.

    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

  6. 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.

    post-1450-1155725912.gif?width=400

    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 :wacko: .

    Saludos,

    Aitor

  7. When i press Ctrl + H for certain Properties , it says to check "LabVIEW Scripting Properties and Methods Help Menu item in the Help Menu" which is not available. Is there any way to get that. Lot of properties look new and people are using that frequently. I want to know about it.

    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 ;) .

    For example, In a vi, Terms[] property of Event Structure is indexed for the 3rd element to get the Term, how did they found it is a 3rd element? Lot of unanswered question like this? Any source to know about all this? :headbang:

    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

  8. 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.

    post-1450-1151419766.jpg?width=400

    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 :unsure: .

    Saludos,

    Aitor

    Download File:post-1450-1151419476.llb

  9. If that works then thats my solution!

    I need to create these from scratch.

    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" :D .

    Saludos,

    Aitor

  10. thanks crelf, build the vi, do you mean, at the Tools>> build application>>...... menu to do that ?

    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 :rolleyes: .

    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

  11. 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

  12. My thought on duping it out is that if you could get the html to continually try and auto-connect every 10 seconds or so, then the server could choose a client by disconnecting clients until the desired client grabs the connection.

    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 :angry: .

    Of course, you could reload the whole page every x seconds, asking for control, but that seems a real bad solution :thumbdown:.

    Saludos,

    Aitor

  13. 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

  14. 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

  15. Yes, I know you'd probably like to just use the remote panel itself, but you have obviously ran into a limitation, showing that, while really neat, RPs are, in some ways, still not ready for prime time.

    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 :unsure: . 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... :wacko:

    Go with your tab control idea but on the second tab page, just drop a copy of the control you want to disable that is "pre-disabled".

    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 :blink:

    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

  16. I have to enable / disable / hide a control. Easy, isn't it? Property node -> visible or disabled.

    But the VI is going to be seen in a remote panel, and in RPs (in a net with big latency, to add) property nodes are really (I mean reaaally) slow. I can't use them.

    What can I do? The only idea I've had is to use a tab control. Tab 1 has the control, tab 2 has nothing, a change in the tab value is almost inmediate. But this doesn't reproduce a "disabled" behaviour, just invisibility. I'm stuck there. A tab page can be invisible, but then you see what's under the tab control, not what's in another tab page, and that's what I need :angry: .

    Any ideas, please? I'm running out of neurons...

    :headbang:

    Thaks a lot,

    Aitor

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.