Aitor Solar

QUOTE(tum @ Apr 23 2007, 06:02 AM)

1.How to get HTML code form webpage (etc. www.google.co.th,www.lavag.org) by labview

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)

First of all. This example can be fixed. If you put a delay of 1ms, then it works.

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)

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)

Odd! & you're running 8.2. Sure enough, when I try to put in a 0, it acts like it'll take it, then when I pop back in, it's set to 1. Just like the problem described by the guy in the [wiki]NI[/wiki] posting that I linked.

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)

That didn't do it. In fact, the Format & Precision propertes box won't let me put the Digitits of Precision to 0! When I enter 0, it always goes back to 1.

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)

This is the same solution I have come to as well. The problem however with exposing a reference to the end user is that this breaks encapsulation rules. There is the potential of messing around with elements that you want protected.

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)

But if some geek can make an Xnode of this, that would be great !

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)

http://forums.ni.com/ni/board?board.id=beta13''>http://forums.ni.com/ni/board?board.id=beta13' target="_blank">http://forums.ni.com/ni/board?board.id=beta13

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)

I have extracted the help documentation for the abilities and I have formated in a word document with hyperlinks.

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)

Does that make sense? Not very consistent. I'm also not sure if this is true for all of the "new" names but I noticed it for most of them.

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'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)

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)

Init Ability always runs when XControl instance is loaded. The problem is you put your code in the 0.0.0.0 frame. You need to put it in the default frame. Delete the 0.0.0.0 frame altogether.

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)

You can find all the Abilities vi's in <LV8.2>\resource\Framework\Providers\xi\xnode.llb

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)

Looks nice. However, it won't run, because it is missing a couple VIs: "borrar error.vi" and "convierte vilib path (from string).vi"

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)

What I'm wondering is, if an event is handled in multiple event structures, will all of them receive notification when the event occurs?

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

Here's a couple INI entries:

XNodeWizardMode=True (try right clicking on an XNode now!)

XTraceXNode=True (um, I forget what this did actually...it's been a couple weeks)

Of course, I personally prefer:

ExternalNodesEnabled=True

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

Well it's not the use people here are interested ;-).

Well, sorry, from the previous posts I got the impression some people was simply opening the xnode instead using it in a diagram.

It's how you made them! As far as I know there are only two possibilies:

- You got a license from NI somehow (and have signed an NDA or someone has on your behalf) and then posting this here could get you in trouble.

- You hacked LabVIEW to not do a license check anymore or something like that and then you are also in trouble in at least certain countries on this globe who think that even thinking about circumventing anti-copy protection is a major crime.

Ouch, come on... Do you really think I would do something illegal? And even worse, do you really think I'd do something illegal and posting it in a public forum?

Creating an xnode is really easy and doesn't need any license. A Xnode is just a type of library and can be open, modified, etc with scripting.

And, as Jimi says, a xnode file is just a XML file. You can extract it from the llb, open it in a text editor, change what you want and returning it to the llb.

About the abilities... that's even easier . The ability VIs just need to have the correct connector pane, and you can find that connector panes in the xnode example that comes with LV82 (search for *.xnode in your LV82 installation directory). Not everything is exposed, but with some trial-and-error and knowledge of the old External Nodes is not so difficult. So you can create new ability VIs without problems (they are normal reentrant VIs).

About linking a VI to a library, it's answered in this same forum, in a question about linking VIs to a Xcontrol, IIRC. You have the library reference and use the "add item from memory" method.

So, I ask you, members of the jury, must this man go to jail for all his life?

The answer is "probably yes, but not for this"

Saludos,

Aitor