Aitor Solar

QUOTE(TiT @ Apr 23 2007, 10:39 AM) That VI is done with LV7.1.1f1, and the error alert before crash says: "The exception Breakpoint. A breakpoint has been reached.", that is also pretty strange, I think. I don't have any LV8+ connected to the web to check if it works, so I'll trust you . Probably just a bug that was corrected in later versions. Saludos, Aitor

QUOTE(tum @ Apr 23 2007, 06:02 AM) As easy as this: http://forums.lavag.org/index.php?act=attach&type=post&id=5602 Try "http://www.google.com/index.html", since just "http://www.google.com" provokes a LV crash. Strange behaviour, by the way Saludos, Aitor Edited to add the user/password fields.

The facts: if you rename a VI extension to "vim" and put it in a block diagram, this subVI acquires some kind of input/output polymorphism (it adapts to any input you connect, and propagates the data type through the VI). Maybe it has some other special behaviour, I don't know. Internally, it seems the VIM files call a External Node placed in the <LVdir>/resource/Macro.llb/;DMacroizer (without extension). Unfortunately, this External Node and its subVIs are password-protected . Do we have more info about this kind of VI? Saludos, Aitor

QUOTE(Michael_Aivaliotis @ Mar 21 2007, 10:45 AM) Hey, good machine . In my PC I need 10ms, and its a 2.8MHz Dual Core. QUOTE(Michael_Aivaliotis @ Mar 21 2007, 10:45 AM) Your other example about the "Get Image" native method is similar since it does not wait for the Facade to complete the work it has to do. I suggest a workaround is to implement your own replacement "Get Image" which does the same thing as the native one. The difference is that it will force the Facade to execute thus avoiding this problem. In fact, all of this started when I tried to implement my own GetImage method, something I've been uncapable to do in a simple way (the GetImage example I mentioned is just the solution NI suggested). So maybe I'm doing something wrong. Let's call the new method GetImage2 to avoid confusion with the native one. I want GetImage2 to recieve a background color, make a native GetImage method on one of the Facade controls and return the resulting image. The way XControls' methods are implemented, you can only handle the State cluster values and after that, Facade will be called. So: 1) I can't have the image data as a State element, since that image depends on the background color (and I don't know the BGcolor until the method is executed). Moreover, having always an image in the cluster and updating it whenever is a change in the Facade seems overkilling and will make the XControl heavier in memory terms. 2) I could have, in the State cluster, a reference to the control whose image I need. That refnum can't be initialized in the Init VI, since the control is in the Facade VI. So, I can make a custom property to initialize that refnum ("InitRefnum") and call it always before GetImage2. But that's error prone (the end programmer can forget it, or we could fall again into a race condition). It would be great if GetImage2 could call internally InitRefnum to avoid problems, but is impossible to call an XControl custom property or method inside another custom property or method (it leads to recursion). 3) So, I could initialize that refnum in the Facade's Timeout event case just to be sure. But I'd prefer to do nothing in the timeout (I think this very issue was commented here about Ton's XControl creator). And that would add unnecessary code executed every time the Facade is called. 4) Minor issue: after doing all that, Facade is executed to do nothing. Why I can't decide if I need it or not? 5) If there has been an error in all the process, I'd like the invoke node error output to carry it. But that seems impossible (the "error out" cluster in the Method template doesn't go to the invoke node error, it seems get lost). I'd have to create an additional output in GetImage2 and check it in the external VI every time I call my method, just to see if has worked fine. I hope to be mistaken in any point, but the way I see it, it harldy worth the effort . Saludos, Aitor

I'm sure this will be corrected in the next version of LV, but anyway is a step backwards. The ironic part is I've discovered this will affect one of my programs if I update it from LV8 to LV82... something I must do in the next couple of months . Saludos, Aitor

When you call a custom property or method in a XControl, the apropiate VI is executed and, after that, the Facade VI is called to update the changes. OK. But it seems LV returns the control to the external VI before the Facade has finished. So if you write a property and inmediately read something that depends on it, you'll get the previous value, not the one you have just written. This can lead to problems. For example, I have implemented a property that tells the Facade to make invisible some elements, then I call the XControl "Get Image" native method. The resulting image has the elements that should have been inivisible, unless I put a delay of about 15 ms between the property and the method :thumbdown: . Saludos, Aitor EDIT: I have attached an example; open try.vi in the llb. This VI generates a random number and passes it to the custom "New value" property. This property updates the XControl value, but before that, the VI continues executing and gets the old value. If you make the delay to 10-15, the behavior is corrected as the Facade has enough time to finish before the external value is read.

QUOTE(BrokenArrow @ Mar 19 2007, 03:35 PM) OK, I think I get it. The problem is that a "Floating point" mode won't accept 0 digits of precision. But depending on its previous accepted state, will revert to another mode (for example, I see it in "Automatic formatting" when I open your VI) or will keep the "Floating point" but with 1 digit of precision, as you say. So I suspect we were seeing different behaviors . Now, this is a LV82 problem, since it works fine for LV8. Maybe you could use a "SI Notation" mode, that seem to accept different number of digits without problems (but is not the same, of course). Saludos, Aitor

QUOTE(BrokenArrow @ Mar 19 2007, 03:05 PM) Well, I haven't seen that behavior in your example, just a 1435 error code. In fact, when I open your VI, the numeric control already has 0 digits of precision. If I edit the Format and Precision options, I find no problem to put 0, 1, 2 or more digits of precision. The only problem arises when I try to modify programmatically the number of digits of precision AND the control has "Automatic formatting". Saludos, Aitor

Automatic wikification results in strange things when the wikified word already was inside a link. For example, try: The [wiki]NI[/wiki] page The first part of the external link goes to ni.com, the "NI" goes to wiki and the end doesn't go anywhere. I would prefer links are not wikified. The same applies to codeboxes. Saludos, Aitor

The error is provoked for having an "Automatic formatting" format selected in the control. See here: Changing the Format and Precision of a [wiki]Numeric[/wiki] Control Programmatically Saludos, Aitor

QUOTE(Michael_Aivaliotis @ Dec 27 2006, 08:10 AM) Well, you can protect XControl's properties and methods, like you protect a library VI so VIs belonging to other libraries can't use them. Now, does that mean the end user won't see the protected properties and methods? Unfortunately, it seems not. The user will see the protected properties and methods... but will get an error if he tries to run them . Saludos, Aitor

QUOTE(TiT @ Mar 6 2007, 10:52 AM) I suppose you can create an XNode that detects if is inside a for loop, and in the generate code phase, replace that for loop with a while loop that stops with the boolean condition passed to the XNode. The hard part would be checking all the indexed array inputs to see when to stop, if the N is wired... Imagine that, after all that hard work, NI decides to add that capablity to LV's native for loops. It would be crazy! Saludos, Aitor

QUOTE(Jim Kring @ Mar 10 2007, 09:23 AM) No, access denied, even if I logged in NI Hey, I'm a beta citizen in a beta test Saludos, Aitor

And where is that beta forum? Yes, I'm accepted, I'm downloading the software, see the reported bugs, the documentation and known issues... but no forum Saludos, Aitor

QUOTE(DanyAllard @ Feb 27 2007, 08:20 AM) Good work. But I think the abilities' public names not always match the internal names. For example, the documentation talks about a BuildMenu, BuildMenu2 and BuildMenu3 abilities, but internally we have a BuildPopup (whose documentation seems what is defined as "BuildMenu" in the doc), BuildMenu (whose documentation seems what is defined as "BuildMenu2" in the doc) and BuildMenu3 (this one 's correct). And a "BuildMenu2" ability in an XNode gives an ability-not-recognized error. I suspect NI renamed the abilities for the LV8.2 project manager (and hence their name in the documentation) but internally they retain the LV8 name. Pretty chaotic for us :-( By the way, I have observed the XNode Manager gives an error whenever you add an ability with an absolute path ("relative path?" unchecked). When the application tries to add the VI to the XNode library, it returns a 56003 error ("Adding this item would cause a conflict with an item already in memory"). Strange. Saludos, Aitor P.S.: XNode Manager 1.4 for CR is on its way.

QUOTE(AdamRofer @ Feb 24 2007, 01:02 AM) Thanks, Adam. Yes, it seems there are some inconsistences, like deprecated abilities that point to an ability not supported. Also, there are at least two VIs that are not abilities but of recommended use: L10N and HelpMap. Here is my last list of abilities, see if you find any hole: http://forums.lavag.org/index.php?act=attach&type=post&id=5030 QUOTE(Michael_Aivaliotis @ Feb 24 2007, 10:00 AM) I've created an xnodes category in the code repository. Please post this code there. I'm preparing a new version with Adam's suggestions for the Code Repository. But I'm reading the CR requisites and seem daunting . I'll try to adapt the code, though. QUOTE(Jim Kring @ Feb 25 2007, 01:55 AM) Aitor: Under which license are you distributing the XNode Manager tool? I would like to volunteer to help package this up so that people can install it using VIPM. Good question. I hadn't thought about that. People is free to use the code, modify it as they please and redistribute it, provided they respect original authorship and their versions retain the same conditions. Is there any of the usually acepted licenses that accomplishes that? Saludos, Aitor

QUOTE(Michael_Aivaliotis @ Feb 22 2007, 06:11 PM) OK, stupid mistake. I have uploaded an updated version, more robust. Saludos, Aitor

Yes, using an XNode would be great, but we'd need a lot on info about them we still don't have. I've tried a simpler solution, an XControl that is replaced with another one if the input type changes, something very similar to a polymorphic VI. The example is limited to two cases: I32 and String input. Create a new VI and put some of the provided XControls (Str_poly.xctl and I32_poly.xctl) in the front panel. Make them indicators and try to connect an I32 wire to the string XControls and strings to the I32 ones. But is not a solution I really like 'cos it relies on a hidden daemon checking continuosly the XControls. We would need an event fired when something is connected to the XControl, but I think LV doesn't give us something like that . BTW: Keep in mind this is just a proof of concept. Is not perfectly done (for example, if you save and reload a VI with these XControls, the polymorphism will be lost since is included in the init ability) and you'll probably end up with an unstable LV, so be careful. Saludos, Aitor

QUOTE(DanyAllard @ Feb 22 2007, 04:42 AM) That's the tricky part: not all the abilities in that llb work properly. Some of them give an "ability not recognized" error (different from the "parameter X has incorrect datatype" error, that just means the inputs / outputs for that ability are not what they should). Anyway, you can add new abilities easily and check them in the XNode Manager, just add the new ability to the list ("Ability list.ctl", IIRC). Saludos, Aitor P.S.: I think the new zip is linked properly, please check.

QUOTE(Jim Kring @ Feb 21 2007, 06:15 PM) They should be in the "comunes Xnode manager.llb" included in the zip. Saludos, Aitor

This is an application for creation and management of XNodes. Hypothetical future versions will be at the bottom of the thread. Delete elements from 2D array.vi I think the program is self-explaining in its simplicity. It allows to open or create a XNode and add or remove abilities, and I hope will be a useful tool for anybody who wants to try their own XNodes. I don't have much free time nowadays, but I'll try to correct any problem that arises. I'll love to read your feedback. Caveats: 1) Some XNodes' private properties and methods doesn't seem to work properly, so this program uses XML VIs. So, you'll need the Internet Toolkit for LV. 2) Maybe the abilities list is not complete (but I have tried all the proposed til now). If you find other abilities, please tell me. 3) This doesn't do the hard work, just provides management (correct patterns, etc). You'll still have to program what your XNode does. Saludos, Aitor

Let's say you make a XControl of a graph. Graphs are polymorphic (for example, a Waveform Graph can accept 1D or 2D-array data), but the XControl doesn't. Any workaround? Saludos, Aitor

QUOTE(gustav @ Feb 14 2007, 11:23 AM) Yes, provided is not a filter event. As a side note, I have experienced some problems with dynamic events catched in multiple structures, sometimes events "get lost", so I advise caution. Saludos, Aitor

Have you opened the automation reference? Saludos, Aitor

Great! Now is much easier . Here is a llb with blank Ability VIs, with the appropiate connector pane. Is not the complete set, there are still some more abilities, though the most frequently used are included. I'll try to complete later. I'm surprised they are so many and not cleared differenciated (there is "BuildMenu" and "BuildMenu3", for example). And yes, State.ctl carries the internal state just it does in Xcontrols. Replies are used to call another Ability (for example if you generate code that changes the terminals, you should return a "UpdateTerms" reply). Saludos, Aitor EDITED: Ok, now the llb has all the Ability VIs I know of. So if anybody finds some else, tell us . Is there any list of all the possible abilities? Download File:post-1450-1169210073.llb