Aitor Solar

As requested, here is this simple tool intended for providing an easy way of calling properties and methods. I thinks it's pretty intuitive and works as other similar applications. Select the LV version, the class and the desired properties or method. Press "copy" to have the function in the clipboard and paste it in a block diagram. Known issues: The description box doesn't show anything, because I haven't found a way of programmatically retrieving it. Any idea will be welcome. Some properties can't be created this way. For example, try Generic -> Owner and you'll see the deprecated property is created instead. Maybe not all properties and methods are included and can be some repeated. You can play with the txt files to add and try ned props/meths. The search capability was added as an afterthought and I would prefer to have it better integrated. But still useful. Please tell me any improvement or idea you get. Saludos, Aitor

QUOTE(bolle @ Nov 8 2007, 12:14 PM) Use property: Plot area -> Colors -> BG color Saludos, Aitor

QUOTE(Tomi Maila @ Nov 7 2007, 05:47 PM) Yes, it's easy. Things go more or less like this: If your XNode has a description, the palette will show the XNode library icon. If the XNode doesn't have a description, then the palette will show the Help VI icon. If the XNode doesn't have a description nor the Help Ability, then the palette will show the Initialize VI icon. If the XNode has no description, no Help and no Initialize, the palette won't accept it. So, use a description Saludos, Aitor

Well, the problem arises in the "7.8" step, when you compare two "7.8" values and the "greater?" function returns true. I'm not an expert on this but I believe is usual for floating point numbers not to be exactly the expected value, due to accuracy limits (number of bytes, etc). Surely someone else can explain better. Anyway, it's better to avoid those risks. For example, you can substract both values and check if the difference is greater than 0.1, or work with integers and convert then to double in the end. Saludos, Aitor

QUOTE(Yen @ Oct 23 2007, 07:32 PM) No, that doesn't work in LV85. It must be either another INI key or a different approach. That event structure Michael posted is not like the ones LV usually creates, probably an inner (non-exposed) property is modified. Maybe is the same detachable structure he created with that INI key in LV82 or 8 (I can't remember) and now LV85 respects it. In fact, if you dig the properties for the NamedUnbundler (the class name for the Event Data Node), you'll find this: http://lavag.org/old_files/monthly_10_2007/post-1450-1193212531.jpg' target="_blank"> "This flag tells the unbundler that is not allowed to resize to the left (when a new item is elected) nor is it allowed to move left or right." But it doesn't work (though it returns no error). There's something else. Saludos, Aitor

QUOTE(tcplomp @ Oct 22 2007, 01:09 PM) I think it can run standalone. Create the user event in the XControl (for example in the initialization) and store it in the State, then add a property or method for retrieving the user event reference and register it in the owning VI. The XControl will work on its own, and if you don't need the event, don't use it. Saludos, Aitor

QUOTE(Michael_Aivaliotis @ Oct 10 2007, 11:36 AM) ¿Can you also detach the output bundler? Saludos, Aitor

QUOTE(yen @ Oct 8 2007, 10:48 PM) No for what I've seen. Through scripting you can tell LV to set the output wiring rule to required, but it has no effect, just like in 8.2. And I suspect in that case Michael would have put it in Ruty Nails. It must be something like an automatic adaptation where LV bypass that checking... No idea Saludos, Aitor

QUOTE(PJM_labview @ May 24 2007, 08:48 PM) True, but there are also some minor problems with that: 1) If you try to change a disabled XControl, not only fails but, after that, keeps failing even if you enable it again, until the user interacts with it (or until you close the VI and open it again). I'm assuming the XControl remains in some kind of internal bad state. So if you are not careful enough and forget to remove just one case of "set value while disabled", you can make your XControl useless for the rest of the application. 2) My XControl is not disabled itself, but inside a disabled tab control. So I have to carry around the tab control refnum to enable and disable it (or get the XControl owner object to enable / disable it). It can be done, but doesn't seem very efficient since there are a lot of XControl instances (almost all the numerical controls/indicators) and I don't know if they are enabled or not . Anyway, I'll implement some similar solution and hope not to forget anything . Thanks. Saludos, Aitor

QUOTE(tcplomp @ May 24 2007, 03:43 PM) Great :thumbdown: Thanks, Ton Saludos, Aitor

QUOTE(Aristos Queue @ May 23 2007, 09:03 PM) Thanks, Aristos. Now I have found an ugly bug with XControls. XControl value property doesn't work if the XControl is disabled. I've looked in the NI forums and is a known issue: http://forums.ni.com/ni/board/message?board.id=170&message.id=177819' target="_blank">http://forums.ni.com/ni/board/message?boar...ssage.id=177819 Now the question is: has been this bug corrected in LV 8.2.1? I have my app almost finished and so I haven't updated to 8.2.1, but I'd do it if that's the solution. If not... If not this would be a big, big problem, since I need to update an XControl value from another VI when that XControl is disabled I have attached a very simple test VI. If anybody can test it in LV8.2.1 I would be grateful. Saludos, Aitor

It seems automatic upcasting doesn't work with XControls (see attached image), it's necessary to explicitly upcast to Control class. But I don't know if it's a bug or another strange XControl thing particular of my machine. Anybody else? Saludos, Aitor Umm, it seems if the XControl reference is connected to the first terminal of the build array node, it works, but if it's on another, it fails... Saludos, Aitor

If that debugger don't expose anything (ActiveX, .Net, whatever) and you can't pass the needed info through the command line or similar, I don't see how you can control it from LV :thumbdown: . I suppose you could get the control of Windows mouse and keyboard and simulate a human user... but that's defnitely not elegant. Saludos, Aitor

QUOTE(nhollenback @ May 15 2007, 07:28 PM) Trust me, I do nothing: I select the Thermometer XControl that ships with LabVIEW 8.20, I hover it over the block diagram and see something strange like an empty lowered box http://forums.lavag.org/index.php?act=attach&type=post&id=5880''>http://forums.lavag.org/index.php?act=attach&type=post&id=5880'>http://forums.lavag.org/index.php?act=attach&type=post&id=5880 And when I release the mouse, crash. I don't think the XNodes are related to this (though I have seen strange errors in XNodes when trying to create an XControl input, so who knows). Just to be sure we are doing the same, I don't mean to drag an XControl from the front panel to the block diagram (that works) but placing it directly in the BD. Steps: in the BD right click -> Select a VI -> go to the XControl folder -> select "All files" to see the XCtl -> select the XCtl file -> place in the BD. Saludos, Aitor

QUOTE(nhollenback @ May 15 2007, 02:17 AM) Nothing special, in fact I also tried it with the xctl in the LV examples (dual thermomether I think it's called, is placed in examples/general/xcontrols) and the behavior is the same: crash boom bang. Did you tried with 8.20 or 8.2.1? Saludos, Aitor

Just place a xctl in the BD (as to get a constant). LV crashes. Probably it doesn't make much sense to have a Xcontrol constant, but LV shouldn't crash, IMHO. In LV8 this wasn't allowed and so there was no problem. Saludos, Aitor

QUOTE(mballa @ May 14 2007, 12:00 AM) Thanks a lot! The funny thing is I searched nearly an hour for it. Even now, if you search in the forums for "icon editor", that topic doesn't appear in the list . Saludos, Aitor

I'm sure somebody gave a way for calling programmatically the icon editor, but now that I need it I can't find it . Does anybody remember? Thanks. Saludos, Aitor

QUOTE(Ami @ May 1 2007, 05:55 PM) He could implement an ActiveX / TCP / Shared variable communication with App1 from App2 and test it periodically. If it doesn't respond, abort it through a taskkill or similar. You can even reinitialize it from App2 to avoid lost time. Saludos, Aitor

I personally don't think XControls are the definitive solution for UI customizing. Are interesting, yes, but have too much caveats. When you make a XControl, you want the behavior of a normal control plus some specific changes. The way XControls are conceived, when you create a new one you go back to a generic control and then you have to add all the things a specific control type (like numeric, picture, etc) does (and then, of course, make the special things you want for your XControl). IMHO, some things are not well implemented like the error propagation, the impossibility of using a XControl property or method inside another property or method, the absence of a simple way of adding your own events, etc. As you can see, I'm a little dissapointed with XControls even if at the beginning I considered it a great step forward. I'm looking forward Michael's presentation too, because I'd love to love XControls again . Saludos, Aitor

For example: http://forums.lavag.org/index.php?act=attach&type=post&id=5649 Saludos, Aitor

QUOTE(tcplomp @ Apr 23 2007, 04:23 PM) But the arrow in the Static VI reference lends me to think it's also strict... and it's not. Anyway, it doesn't mind. Thanks, Ton. Saludos, Aitor

I've always (well, since LV8) have a doubt. Why the strictness seems to be represented sometimes with a star and sometimes with an arrow? http://forums.lavag.org/index.php?act=attach&type=post&id=5608 Surely it's obvious . Saludos, Aitor

It also works with the [text] suffix if you put the end slash: "www.google.com/" . Usually the web browser corrects that; my fault. Anyway, I think LV shouldn't crash if I ask for text with something that is not text. An error code is OK, but a crash... Saludos, Aitor

QUOTE(TiT @ Apr 23 2007, 11:33 AM) Umm. My LV7.1.1 has a NI patch to speed up remote panels, so maybe it added a bug to the data socket functions. At least, it's the only reason I can think of . Saludos, Aitor