Norm Kirchner

Will any of these help you out?

see attached image

Well, my first attempt is not going too well. I made it public instead of private. This means non-LAVA members can join. I also made it 5hrs. I just discovered that you can't cancel a skypecast. So I have to wait until the time expires to start a new one. At that time, I will start a private skypecast and post the link in this thread so only readers of this thread can join.

I hosted the one for the 5 hours and learned a few things. It's ok to make it public, but you need to closely moderate the number of people available to talk. By default, people coming into the conversation are able to talk immediately, rather than by being invited to speak from only being able to listen. This way you can leave it open to whoever but stop the wackos from getting through.

You change the default by setting the option "send all to listen" or something close to that.

~,~

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!!

~,~

Hey that sounds very interesting ! So you can create the correct connector pane constant ! I've been waiting for that for quite some time...

Can you create such a constant given a non-typed VI ref ?

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

1. Create a sub-vi in the same location as the parent w/ some special namespacing
   
2. drop the necessary blocks for recursion: see picture above
   
3. determine the parents connector pane and set the sub-vi's pane to the same along w/ the static pane reference
   
4. Copy the parents icon and do a glyph edit to mark as recursive
   
5. 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.

There are more properties than that. Do you have the private stuff activated?

Saludos,

Aitor

In 7.1.1 I do

I'm not sure if I understand you, but in the ConPaneData property you have that, isn't it?

Saludos,

Aitor

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.

If my memory serve me well, these VIs are use by mathscript. Everything that came with your LV can be used. There are actually gems in vi.lib that are unfortunately not exposed on the palette. In regards to these script VIs, If you can figure out the abstraction NI build over scripting, I see no reason why you should not use them.

Note: Here is a gem I found in that folder as well (Connector Pane Terminal Order.ctl)

PJM

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

It would be very handy for wiring through those shift registers when we add new cases.

I'm still working on the eye-trcker.

Vision system watches my eyes and moves mouse to where I am looking.

Left blink = left mouse, etc.

(Don't hold yur breath)

Ben

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.

I could modify my tool in a way, that you are able to select folders, which shall be ignored during the duplication process. If you are working with prefixes, it should work allready.

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.

So I ran the CtlRefDebug-Sub.vi by itself and removed all of the others from memory. I got an error 1055. So what's the issue?

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!!!

I've tried applying high-lighting color rules to objects in the past; but they don't have a consistent "look" accross all of the colors. Would you mind sharing what you did?

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

Thank you for posting the smart cursor brat. My bigger gripe is that you have password protected "TRef Traverse for References.vi". I would REALLY like to see under the hood of this VI.

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.