-
Posts
823 -
Joined
-
Last visited
-
Days Won
25
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Norm Kirchner
-
-
Well, Thanks all for the support and the love...
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.
-
Well using the Cluster will be much easier to figure out what element was clicked but if you must use an array, you should register the "array element" for the mouse up event and the math will be much cleaner when trying to calcluate which element was clicked because you never need to use the mouse click position, it will simply return the left/top position of the control clicked upon
See below
-
Of course there is, register each of the controls for mouse events.
Keep in mind that you should use the Register Events Node to wire an array of references for the event, then within the event structure it will retrun the reference to the individual ref from the array of ref that actually fired the event, look at the lable or any other defining information to determine which one fired the event.
Dynamic methods like this and many more will be discussed at NI Week session E15
Session Title: The Art of Creating Dynamic, Flexible LabVIEW Applications
Session Speaker(s): Norman Kirchner, Gerald Albertini
Session Schedule: Thursday, August 10 @ 10:30 AM, Room: 11A/B
-
Sorry if this is off-topic ...
My presentation is Thursday at 10:30, Room 15.
Richard
www.jembedded.com
You son of a gun. You're working my corner. That's my time slot.
We'll have to arm wrestle at the pub crawl for attendees.
Session: E15
Session Title: The Art of Creating Dynamic; Flexible LabVIEW Applications
Session Speaker(s): Norman Kirchner, Gerald Albertini
Session Schedule: Thursday, August 10 @ 10:30 AM, Room: 11A/B
-
Great idea Mark!
I will be presenting and a few others here in my group @ Texas Instruments will be presenting also.
Here is my information
Session: E15
Session Title: The Art of Creating Dynamic; Flexible LabVIEW Applications
Session Speaker(s): Norman Kirchner, Gerald Albertini
Session Schedule: Thursday, August 10 @ 10:30 AM, Room: 11A/B
It's all about creative methods for creating dynamic LV programs
Hope to see you all there!
-
I've found that the specific AX control i'm working w/ does not have a typelib key (IID) within the CLSID section.
Breaks the flow of the first program because it assumes it's there. But I used the TLI program to easily to find the TYPELIB ID
-
Attached is the TLI object.
See if it works for you, I'm still checking out your code
Thanks for picking up the gauntletDownload File:post-208-1151421789.zip
Just for my ref
How did you find out how to parse the TypeDesc info??
-
There is an activeX object called "TypeLib Information Ver 1.0"
I do not know how this go onto my system, but you can get all the guts through this interface.
If you can tell me how to get to the registry location of THIS AX object, i'll dig and let you know how to get it.
care to post your prototype?
Tell me if you discover a better way of retrieving that three parameters, of if you need more info on my "experiments" .Saludos,
Aitor
-
Now, in the type descriptor you do have the CLSID of the ActiveX class, as it appears in the Windows registry (starting from position 12, I think), so I'll give it a look.
If that works then thats my solution!
I need to create these from scratch.
-
I bet you can't figure this one out.
I'm looking for a way to programatically "Select ActiveX Class" for a created Automation Refnum.
The only direction I can see right now, is hack into the type descriptor / andor create one from sctratch and use the create contorl from type desc vi to make it.
Any ideas.
The purpose is to create an "All Objects" vi that has a refnum for each of the possible, not just creatable, objects.
Thanks
-
Do you work off of multiple monitors.
I saw the same error. Suppose it's old news now anyways.
Wow.That's some seriously impressive LabView code.
*edit*
I wasn't sure if it was just my laptop at first. But I get this same error on another desktop with M3nth's code:
Error 1 occurred at Property Node (arg 1) in Water Intesity.vi->Making_Waves.vi
Possible reason(s):
LabVIEW: An input parameter is invalid
---
NI-488: Command requires GPIB Controller to be Controller in Charge.
When I continue though, the code seems to run fine.
-
Someone has to hack the site and put the Captain Moustache ~,~ on all of us.
and no, I don't think I'll ever grow up.
-
As a result of your report, we've identified an issue that can occur when calling remote VIs dynamically (and in particular, when using the call by reference node) when the call by reference node resides on the diagram of an Express VI's configuration page.
Please let me know if this seems to summarize your situation, or if you have seen these "hangs" in other situations as well.
To be brief, Yes this summarizes the issue.
More specifically, it generalizes the problem even further beyond what the dynamic call, calls into (my case exe), (your case anything )
using the Run VI method instead of the call by reference node, but this can get quite cumbersome in a hurryDefinetly not an option.
Now a the note on the details: I think that this forum(maybe another thread) is a reasonable place to discuss the mechanics of why. It would increase the understanding of the community as a whole to another part of the LV guts and therefore allow the community Gurus to assist in helping others and give us the chance to make "furture proof" creative/sneaky code.
-
For a little more detail on the.... details.
The call is into an EXE.
Using VI server to open an app ref to the exe
Then open a ref to a VI loaded into memory, but not running in the EXE
Call by ref node to that VI in the EXE and wait for it to return.
Don't get hung up on the fact that it's an exe, because the same behavior happens if it's a running VI also.
But not consistently in either case.
Isolation of the problem is underway, and it's difficult to know if it's trying to re-compile or not but we'll look towards that as a focus point.
SIDE NOTE: Thanks to all the NI interaction on LAVA & other forums for those of us staying out of the NI Dev Forum for whatever reason. It's great to have the horses mouth feeding from a few troughs.
-
Actually you should be able to right click on the XControl and show block diagram. Then it should open the instance block diagram. You'll have free control over probing the diagram from there
-
What kind of limitations are there when working between different application instances.
This is a directed question.
The behavior that I am seeing screams of thread locking, but better stated context locking.
I am dynamically executing code in another context that is loaded in that same context.
But what is happening is that the dynamically called code will not exit. It just sits there, locking the vi that is called in the original context (NI.LV.Express)
The details are numerous, BUT the question is simple.
Do the different contexts interact in a way that one context can stop another context from execution?
-
-
-
-
How about something like this that takes advantage of multiple sliders?
Download File:post-208-1142455412.vi
Ask and ye shall receive
- 1
-
-
-
Any reason why theirs is so slow?
-
Problem solved.
The object must have it's label visible and unique if it is something generic like a bundle by name.
The Art of Creating Dynamic
in NIWeek
Posted
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}