Norm Kirchner

If anyone is interested I have started a skypecast ITS SOO COOL The name of the skypecast is "everything LabVIEW" http://www.skypecast.com/ Come on in!! ~,~

I would find it hard to beilve that w/ all the scripting tools out there that it would be impossible... although I have not specifically tried yet. anyone.... Bueller?....Bueller??

I'm thinking also that we could use express technology to accomplish this because it does the creation of a sub-vi for you w/out needing to make new files. For those of you who are savvy to the express world. We have the ability to modify the source when running the configure vi. So when the express is configured (either automatically when dropped or when told so by the user) would be to modify the source VI to have the same inputs as the caller and drop the vi-server recursion fuctions in the guts. oooooh I'm liking this.

I just had one of those eureka! moments when pondering the implementation of recursive calls. I know that it does not take much effor to recurse a VI But what about a vi that automates the process for you and wraps it up into a neat little sub-vi here is my vision which I don't have time to complete but I belive that the community could easily wrap their wires around Create a VI that when dropped into a BD will do the following Create a sub-vi in the same location as the parent w/ some special namespacing drop the necessary blocks for recursion: see picture above determine the parents connector pane and set the sub-vi's pane to the same along w/ the static pane reference Copy the parents icon and do a glyph edit to mark as recursive then do a replace on the parents BD of the dropped recursion vi w/ the one just created So I belive what would happen is the parent BD would have a sub-vi which looked almost identical which allowed for recursive calls!!!! whatdaya think!!!

have it set the screen saver to <None> Now the right way to do that... Not sure, but that's your best bet. Probably some win API function. Do a submit to Info LV and Geroge Zou will probably reply w/ some cool Win32 dll call to do it.

No dice Aitor. I see how you have it working, but I thing that there is some property that will allow you to link an input type to an output type which is what I think we were all expecting instead of an express implementation.

In 7.1.1 I do

Not that I can tell

Sure, it's easy to make the rotation, but how do we determine orientation after the fact and re-intepret the connector order/traversal.

That's pretty neat, but I've always (since scripting )wondered how to handle the rotation of the connector pane. Aside from that, these XML files look like a pre-cursor to something new w/ lv as a whole w/ regards to scripting and porting of VIs

But what should happen when you do this?? a feedback node or something??

Not if I want to ensure that there is no potential for cross linking.

If I do a simple file copy to a different location on the hard drive, the linking will be wrong. The file links are all relative, no? So if I copy to a totally different branch of the HD it'll be searching for each and every file and even it finds a file named there is always the chance of it being the wrong one. So either I need to have everything already loaded into memory do the copy and then open the files again but that gets sloppy. This part would be critical if you include the dependencies within your tool. I would want it to operate like NI export dist panel, where I can select the dependencies item and say exclude all files, that way only the stuff in the project gets copied. Bring me into the beta, I've got a use case all ready to try.

I have a project that utilizes a common codebase. I want to use the export distribution to make a new copy in a differnt location of the relevant files in the project, but still use the common codebase that doesn't move on the hard drive. The problem is that if I don't include these common VIs within the distribution, it looks for them in the wrong location after the export has taken place due to relative path linking. Has anyone used this feature enough to understand how to accomplish what I'm trying. -Norm DETAILS: I'm looking to take the VIs within the project and use them as a baseline. So the export will allow the baseline to remain intact, but create a new copy for the person to build off of in a new location

Does the phrase 'Free Transform' sound like it applies here. This sounds very do'able, but to make it a smooth and robust interface will be tricky. I mean you would effectively have to re-create a picture editor-esque interface where you could draw a selection rectangle around a portion of trace and give drag handles in either direction and also allow the user to select individual points and move those around. You would have to do some fancy spline interpolation at this point to make sure that the data still had a flow to it and didn't get all jaggy on you. I think that it would be a .... wait a minute... 'CODING CHALLENGE!!!' This is a great candidate. Create an interface that would allow a person to intuitively modify the data on a graph interactively. That aside, are you getting paid enough for this, becasue to do it right is gonna be a Job w/a captial J

<ping>

Well since I've gotten some attn. I'll make up a version in 7.1 and submit. Soon to be coming

What do you mean by "Change the Line" on a graph. Change the style or change the data by dragging points around? What are the graphical features that need to be moved to a different time. (I'm assuming you mean time as the X-scale) The quick and dirty answer will be to use the cursors. You can place one on mouse down and the other at mouse up, determine the data between the two, create a duplicate of that data as another trace and allow the person to move that other trace around by some other means like a scroll bar or be really smooth and change the cursor to a hand and allow them to drag it left and right, right on the graph. ooooooh this could be cool if you do it right.

Why did you run the sub? Typically VI's that are labeled MAIN are the ones taht you're supposed to run. The issue is that in LV 7.1 I have observed that running the main will throw an error down in the sub because the child fp (which gives the sub the reference to the graph) was not open. so to keep it really simple Run in 7.1 throws error Run in 8.2 does not throw error Was this difference intentional?

I used to observe that if a FP was not open, properties or methods on controls via wired control references from the closed FP threw an error. I just tested this in 8.2 and all seems well in the world and no error. If someone else has encountered this issue in the past and knows what I

The deep voice was due to the previous night! I gotta get those pictures posted!!!

Well I hate to not take credit for something flashy, but unfortunately this is not a captain feature. This was merely a side effect of using the "dialog" type controls along w/ the right type of "windows xp" style. Gimme a sec while I whip this out.... Download File:post-208-1155654287.swf

Gripe noted, and the post & zip file have been edited. But as far as the Traverse Ref vi goes... Look closer at the path of this VI. This is an NI vi that is packaged w/ LV for what I belive was the VI analyzer. I had a great time presenting and I'm glad you enjoyed it and got something out of it.

Until a better location is proposed, I'll place my presenation here and if you give me a few days I'll start to post the examples too, like all my "Brat Code" VIs Download File:post-208-1155567075.ppt Ok, I just couldn't help myself. Here is the mouseover 'brat' just so you can see how it's done. Download File:post-208-1155579925.zip And for all that attended, thank you very much. I was overwhelmed by the turnout; people standing in the back and even sitting in the aisles. EDIT:Modified zip to include Tool - Get Parent.vi {sorry for missing that one, ran into problems doing source distribution w/ LVLIB}

Wow, who knew that the # of posts gained you status and admiration, I will just have to start posting hundreds of random thoughts in the lounge to support my inferiority complex.