Jump to content

Aitor Solar

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Aitor Solar

  1. 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
  2. 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.
  3. 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
  4. 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 me
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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 (an
  16. 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 th
  17. QUOTE(Michael_Aivaliotis @ Feb 22 2007, 06:11 PM) OK, stupid mistake. I have uploaded an updated version, more robust. Saludos, Aitor
  18. 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 checkin
  19. 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.
  20. QUOTE(Jim Kring @ Feb 21 2007, 06:15 PM) They should be in the "comunes Xnode manager.llb" included in the zip. Saludos, Aitor
  21. 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
  22. 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
  23. 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
  24. 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:
  • Create New...

Important Information

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