Jim Kring

Try it with a Cluster instead of Tab Control: Put a SubPanel in a cluster and replace the SubPanel with another SubPanel. Then, delete the Cluster, and the SubPanel terminal will remain on the BD.

Now, press the RUN button to crash LabVIEW...

Yup, Norm, I think a CAR is in order.

Michael, if you are in the current LabVIEW beta program, maybe you want to submit this, so that it'll be fixed in the next release.

:thumbup: Cool detective work. It sounds like you found a bug (not a feature). Actually, the SubPanel must have a terminal since it inherits from the control GObj. NI is just being sneaky and hiding it. This reminds me of how you could get RufNum constants onto the block diagram (pre-7.0) by adding them to a cluster typedef that had and instance already on a BD. Yup, that crashed LabVIEW a lot...

Well, I tried it out and it seems to be fixed.  :thumbup:

However there is a place for both implementation methods. I usually use sub-panels as part of a larger user interface approach. I prefer my sub-panel call to be non-blocking so my caller can go about it's business. This is why I prefer the VIServer implementation. However from an ease of use standpoint the call by reference is much better.

Michael,

I agree with you that both the CBR node and the Run method have thier place. Same thing with synchronous vs asynchronous SubPanelled VI calls (Run method can be either blocking or non-blocking depending on the "Wait until done" argument). However, I was simply referring to the fact that the two primitives (CBR node and SubPanel method) should not be called in parallel, since this causes a race condition that LabVIEW has already choked on (at least in Beta). I looked at your example, and you are forcing these primitives to execute sequentially (via data flow), so you're OK :thumbup:

Cheers,

-Jim

Hi Clara,

    There is a more direct route to accomplishing what I think you are looking to do. The attached image should get you up and running.

• Create a "Call by reference Node"
  
• Right click on the Call by ref node and select "VI Server" and then "Browse"
  
• Select the VI that you are looking to throw in the sub panel
  
• Right click on the reference input of the Call by reference node VI and create a constant
  
• Disconnect the reference from the input and wire it to the input "Type specifier" of an "Open VI Reference" vi
  
• Wire the vi reference of the open vi reference Vi to the Reference input of the Open by Type Specifier
  
• The Image attached should show you the rest.
  

This solution requires you to learn a little about using the call by ref node if you don't have prior experience with it, but it is the most straighforward and clean way to accomplish sending inputs to a vi you are opening in a sub panel  :thumbup:

Norm and Clara,

:!: I discovered a bug during beta testing, which is caused by calling the CRB and SubPanel methods in parallel (as done in your example, Norm). This has been fixed (I hope), but it is probably better to 1st call the SubPanel method and then invoke the CBR node. You can take a look at the attached example to see what I'm talking about and to test whether the bug is really fixed.

Regards,

-Jim

Download File:post-15-1075853833.zip

Use the Flatten to String function. Then get the length of the flattened string.

Whew... that was a long one... almost a week (Nov 18th - 24th). Again, Jack (or Michael), any word back from the Info-LV folks?

-Jim

Chris,

This is nice. It also supports FTP URLs. However, I tried it on Linux and I get Error 1181 - "Protocol unrecognized by DataSocket"

-Jim

I've posted a hack the simulates a cluster frame color change. Not very elegant, but may be good enough for your application now.

How hard is it to get NI to add these properties the the list? They have to be there, just not exported. Does LAVA and OpenG give the two of you enough celebrity to call the developers and get this into 7.1?  

The easiest way is to submit a support request on NI's website, or to submit it as a "bug" during the beta program. It might be easy, it just depends. No, I don't have any extra pull ;-)

Thanks again,

-Jim

Nope, I have to change the cluster's frame color. I am trying to automate a user task.

Thanks,

-Jim

It looks like there is another outage that started on Friday 10/24/2003...

Jack, any word back from the Info-LV folks?

-Jim

Does anyone know if there is a way to programmatically set the color of a

cluster's frame. You can set the background color using the Cluster.Color

attribute, but I can't find a way to set the frame color.

Thanks, Jim

G'Day All,

   I've got some software (written be a previous employee) where two VIs running on separate PCs that communicate using VI server.  The first VI (let's call it the reader) opens an application reference to the writer PC, and then a VI reference to a VI.  Then, references to all of the indicators are returned, and the VI on the reader PC is able to read the name, type description and flat data of the indicators using an invoke node.  This all works well when operating under the LabVIEW development enivronment, but when the writter is built into an exe, it all falls over.  It *almost* works (the name and type descriptions of each indicator is returned correctly), but I'm getting an empty "flat data".  I've checked the characteristics of each node that I'm using, and they are all available under the run time engine (both read and write) - has anyone got any idea of why this is screwing up?

Chris,

Is the Front Panel of your target VI preserved during the build process? If not the FP controls may not "exist" and therefore not have thier own data space, even if you can get references and type descriptors. This sound like a realistic scenario, so mabye this is the easy solution to your problem (I hope so :-). You can force the app builder to preserce a VI's front panel by putting an owned property node (implicitly linked) on the VI's block diagram that is linked to a front panel control (rather than setting the parameter in the build settings dialog).

Cheers,

-Jim

Now,  if i did want to use dynamically registered events within this top VI,  then I'd have to have 2 register for events twice?

Yes.

-Jim

Hi:

For you VARIANT gurus, have you run into any problems when comparing a present value of a variant (imagine for example a cluster of various types of controls that was converted to variant type) to a prior value and erroneously not sensing a change (when in fact the present value has changed from the prior value).  I seem to be running into this problem whether comparing the variant data directly or even when performing a Variant-to-data conversion and then doing the comparison.

Can provide an example if needed.  Is this one weakness of using variant data?

Sincerely,

Don

Don,

Yes please provide an example. I'n not sure why you are having problems. But, there are cases where Variants are buggy (LabVIEW bug) in LabVIEW 6.1 and earlier.

-Jim

When developing LabVIEW applications, libraries, and components often ones needs many more features than the Application Builder provides. For example:

* excluding certain directories from the build

* defining custom destinations for specific source directories

* optionally convert destination folders to LLBs (or EXEs)

* adding a Namespace suffix so that all VIs in the built application have globally unique names.

I have created a tool called the Development Environment Application Builder that addresses many of these problems. I am looking for feedback and suggestions from other LabVIEW developers. I want to know what features you need in a LabVIEW build tool.

I have started a discussion for this topic here.

You can get more info and download this project here.

As we all go thru withdrawls when info-LabVIEW is down...

LAVA is considering creating a backup of info-LabVIEW. We are considering an HTML web based mirror on conjunction with the daily eMail. The name would be info-LAVA (or something like that!)

We have the utmost respect for Tom C. and are awaiting his response to our requested. We would not run a list concurrently with info-LabVIEW - this would happen only if info-LabVIEW never returns.

We invite your comments & thoughts on this issue near and dear to our hearts! Please post your comments in the discussion group.

Info-LabVIEW.org does provide web access to list postings. I think that there is concern about web-bots/spiders using such things to accumulate email addresses for spamming. I believe that there are certain precautionary measures in place to prevent this on the info-labview web access tools. This may be a concern in a mirror is put in place.

-Jim

I want to take Labview certification. But im not sure vat to study for that and whatis the exact use of that. Does anyone know if the companies really prefer someone who has labview certification??

Getting certified is a good way to improve your LabVIEW skills and make sure that your really as good as you think you are. And, like any certification, it allows a prospective employer or client to immediately make a reasonable judgment of your baseline ability with LabVIEW. Bottom line, it certainly won't hurt you. But, after you have become certified and are very skilled in LabVIEW, you probably won't need to maintain your certification. There just aren't any employers (that I know of) that only hire certified LabVIEW programmers. It isn't at all like the Microsoft, JAVA, or Cisco certs. But, if you send a resume to a company that uses LabVIEW and values a skilled wire-worker, the certificate might earn you an interview.

-Jim

Thanks Jim. I guess I should move this to the buglist.

Has anyone gotten LV7 to work successfully with Microsoft Visual SourceSafe? It appears that this version of LV has problems integrating with it. I have sent a support request to NI. I can reproduce this on three different computers. Anyone else out there?

I keep getting an error message that says: "Microsoft Visual Studio is not installed". However it is definitly installed...

Michael,

Yes, I am having problems as well. If you really need to get it working, you can edit <LV>/scccfg.ini manually or create it in 6.1 and copy it to 7.0. You still can't "Configure" in 7.0, but all of the check-in, check-out features will work.

-Jim

Michael,

This problem only occurs with cluster constants on the block diagram. It doesn't effect Bundle by Name and Unbundle by Name nodes connected to FP controls.

-Jim

The "Register Event Callback" node is only found on the ActiveX palette, but it works for all event types including VI Server Events (Application, VI, Control) and User Events.  Does this mean that it is a platform dependent feature?  I really doubt it -- it seams to be LabVIEW native.  NI, what's the deal?

LabVIEW Documentation: event source ref accepts an ActiveX automation reference. Click the down arrow next to this input and select the type of event you want to generate, such as Mouse Down or Double Click. References must be to local objects. You cannot wire a reference to a remote object.

Is this a bug or a hidden feature?

Now the next step is to figure out how to assign callback vi's dynamically.  :wink:

This shouldn't be too hard. However, I believe that the callback VI framework requires the reference must be strictly typed and the VI must be reentrant.

The "Register Event Callback" node is only found on the ActiveX palette, but it works for all event types including VI Server Events (Application, VI, Control) and User Events. Does this mean that it is a platform dependent feature? I really doubt it -- it seams to be LabVIEW native. NI, what's the deal?

I did some digging and experimenting and realized you can create a callback for any event. Now that's cool! Check out the attached example. Now the next step is to figure out how to assign callback vi's dynamically.

I have figured out one use for this: defining a callback VI that will be called by reference. Take a look at the ActiveX Event Callback examples. This design pattern actually looks pretty useful. I think that I will explore the possibilities of using callback VIs in my own reuse tools and components.

Now, if only the LabVIEW documentation would have done us the favor of mentioning this...