Norm Kirchner

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

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?

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.

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.

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 ) Definetly 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?

Three step Process Go cross eyed Look left And slowly look back to center w/ only 1 eye

You tell me which

Always happy to open a few eyes, now I just need to get everyone looking in the same direction as me

How about something like this that takes advantage of multiple sliders? Download File:post-208-1142455412.vi Ask and ye shall receive

ask and ye shall receive

Maybe it's not an icon anymore.

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.

I'm having trouble getting an object ref of a bundle by name. Seems that I can't quite figure out what the name/order should be.

If the picture is 255 shades of grey, the attached picture will accomplish what you need, minus the 2 for loops. NOTE: Good range for magnitiude control 0-10 If it is a color picture, then you must break out each of the color channels and re-combine them after you have adjusted their values. The dirty version of the technical answer is, you must increase the distance of the current pixel value from a center pixel value Thus making the light pixels lighter and the dark pixels darker