Jim Kring

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

Thanks for the fine example. Actually what I am trying to do is programatically drop a cluster on the front panel and then change the color of its frame. This needs to work for arbitrary clusters. 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

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

Yes. -Jim

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.

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

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

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

According to NI's documentation for the Register Event Callback Is this a bug or a hidden feature?

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

Be careful not to do any "reverse engineering". Its a violation of your software license agreement (Section 3) :roll: If you are interested, please post your findings to: OpenG.org:LabVIEW Docs:Application Builder:7.0 -Jim

Nope, you don't need serpdrv... now you need VISA. All serial port IO now needs to be done using VISA. -Jim

I just ran into this problem a few days ago. Yes, it is amost completely useless. If you are not going to either Call or Run your VI by reference, then there is really no need for a static reference. I believe that you can use "Call by Reference" if the VI is reentrant - but then what is the point? The only reason to do a "Call by Ref" on a reentrant VI is so that you can have multiple dynamic instances of it. Here you can only get one reference to your static VI. I figured that I would hold back my initial disgust by looking for an example VI showing how NI sees us using such a tool, but there aren't any examples (that I could find) which use this new "feature". I give it 5 "Eye Rolling Emoticons" :roll: :roll: :roll: :roll: :roll: -Jim

Here is an example that does this. However, it appears that there is a LabVIEW bug that is causing problems with the reregistration. :? Download File:post-15-1073111573.vi

Joe, Regarding the question of "What's the next step after state machines?", I believe that it is component-based architectures. These use the OOP principles of encapsulation and modularity to aid in application design and maintenance. Although components may utilize highly complex messaging, internally, this complexity is not exposed to the users of the components. If you are interested in looking into using OOP techniques in LabVIEW you might find the links, below, useful. Graphical Object Oriented Programming (GOOP) OpenGOOP - OpenG's GOOP framework I would also take a look at the examples of each of the tools on the Advanced >> Synchronization palette. These are the tools that enable messaging and event driven programming. Messaging and Events enable functionality that is not possible with dataflow, alone. It allows you to define timing and data-flow relationships that are not transmitted through LabVIEW wires. Once you have a grasp of the basic tools for messaging and events, you should invest some time learning the frameworks, architectures, and patterns, which utilize them. Good luck, -Jim