JDave

Good eye. I had a subVI to handle the panel defer, and obviously didn't check the new code quite enough. I will update the VI. David Saunders

Combining this with PJM's method of creating a new Polymorphic VI in 7.1 (clever, clever :thumbup: ) one can create polymorphic VI's programmatically even in 7.1, even with the Full Development System. I kept PJM's original code, adding the following: Attaching generated instances to the new polymorphic VI If selected control is an array, the element data is replaced (not the entire array) David Saunders Download File:post-1519-1156806400.llb

The simplest way (if you want to read it any time) is to create a local variable of the array. (by right clicking on the control, choose 'Create', then Local Variable). Then you can right click and 'Change to Read'.

File Name: Array Point to RowCol File Submitter: dsaunders File Submitted: 3 Aug 2006 File Updated: 22 Oct 2006 File Category: User Interface Converts a pixel coordinate to an array index. Returns an array of indices with a length equal to the number of array dimensions. Also returns if the point is within the content rectangle (not on the caption, scrollbars, etc.) Works on any N-dimensional array regardless of visibility of caption, label, index display, or scrollbars. Designed to be used on mouse events that provide the mouse coordinates. Limitations: Property nodes do not indicate the array border width, nor if the user has chosen to display an element gap. These inputs are thus provided on the VI. Click here to download this file

Are you sure you got the right forum?

I just submitted this VI to the Code Repository, but will post it here considering that with NI Week it may not get reviewed for a while. I designed it as a general tool to do the "Which array element did I click on?" task. It will work regardless of the visibility of the Caption, Label, Index Display, or Scrollbars. Version is 7.1. EDIT: I forgot to mention that it will work on any N-dimensional array. David Saunders Download File:post-1519-1154636554.vi

The math would be cleaner if it would actually tell you what the indices of the element were There is still the need to calculate the index using the array position (as shown in crelf's post), and you need to be careful if you use small array elements like booleans. In this case if the caption, label, or indices are showing the calculated index will often (or always) be incorrect. David Saunders

You need to get an list of column indices that you want to sort by. first by column 2, then 1, then 3, then 5 Then reverse this list (5,3,1,2) Then sort in that order as already described. (Sort by column 5, then sort again by column 3, ...)

And that sounds like a definition of marriage. I don't think OO will get you out of that. Let me add my Congratulations!! as well. We are expecting our third in a couple months. Lots of fun, though I must say that an exponential increase would be a bit much.

Of a similar nature, how do you protect applications? I have seen trial periods (does not work at all out of trial period), software keys, nag screens, etc. What are the pros and cons of these and other methods?

I finally found the thread I was looking for here.

I remember some thread about dealing with the different application references found in LV 8. Projects create their own, etc. I searched and searched. :headbang: I have a filename, and I want to open the VI reference but this does not work if the VI is in a different app ref. Can someone point me in the right direction? David

Somewhat recently received a B.S. in Computer Engineering, and a M.S. in Electrical Engineering. I guess I have always been aiming at where software meets hardware which has led me to LabVIEW. I have two years working in the DoD. David

You can also use Shift Right-Click to bring up the tool pallete. From there you can select any mouse tool, including painting. This is also useful on the Front Panel, when you need to get the wiring tool back for placing controls in the connector pane.

I guess my first response is just to agree with what Bryan wrote. Let me explain my thinking, and thus history, a little more. When I first came upon Labview a couple years ago I enjoyed the dataflow and graphical aspects of it, which appealed to the EE in me. As I became more proficient, I was impressed at the ease of code reuse. Some careful design and my VIs become generic, reusable chunks of functionality. Reusable code without writing a whole class hierarchy, this is great. As I had come from a world of C++ and C#, I was enamored with the rate at which I could produce code. No worries about syntax and linkages and namespaces :thumbdown: The presence of queues and notifiers, as well as dynamically called autonomous VIs just hastened my departure from my OO past. Here I could write a state machine that communicates with other state machines and get some real work done. Having the LabVIEW runtime engine was just too nice. When I came across GOOP for the first time, I honestly thought Cool! :thumbup: . I had not forgotten the capability and usefulness of OO. I had just gleefully cast it off when I jumped into LabVIEW programming. I looked into GOOP, found a "crapload of refnums" and decided I would come back to it later. So now it is later. I am looking at GOOP, and it seems odd that the tune I am hearing is all GOOP or no GOOP. Having designed and implemented some IMHO good code without GOOP, it just seems ridiculous to say that with GOOP I could have done it better. I look at the code and just can't see it. For example, I realized I needed a new object in my app, and after copying the agent template I have and adding the necessary work code it took just 10 minutes to place the object into my existing architecture. The design was basically OO A&D but there is no need to instantiate new objects at run-time. On the other hand, I look at some other code I have written and think, a little GOOP could help here. It is perhaps a bit too dogmatic to say that anything other than throaway code should be done with GOOP. There are tools that solve many problems without it. I am not arguing for or against OO. I recognize that it is very useful. It takes care of many issues inherently, allows for scalability, etc. It enforces good design, hopefully. I have sobered a bit from my early reckless abandon. I want to incorporate and use GOOP, but I don't want to throw away what has worked so well. I have an open mind about GOOP. I just want to keep that open mind. David

Throw-away code sounds so negative. I am not quite sure what code you are saying merits to be done without GOOP. I am not afraid of GOOP as much as I am afraid of OOP. I have done a fair share of C++ and C#, and the work of building a superfluous structure around my code often seemed worthless. What I have heard of the GOOP development toolkits (with auto-code generation) gives me some hope here at least. Without the use of GOOP I have built a couple sizeable applications in LabVIEW. With some good upfront design they have turned out to be scalable, flexible, and robust. On the other hand I have worked on a couple tasks where I could see a real benefit in switching to GOOP. The need just hasn't been big enough yet. I think this is one of the main issues. I have dealt primarily with instrument control and data acquisition. Rather than objects I have independent agents that need to communicate with eachother and act on that communication. I see no real opportunity to gainfully implement GOOP here. Maybe I am missing something. And after a brief trip through bidirectional time, I have seen (will see?) that shortly I will be hearing about exactly what I am missing.

It seems that the time to write a user name and password would be very short. You may not have much of an issue there. In summary, you CAN lock the LabVIEW panel because the code sending the name&password would be running in the event structure. You said these would be stored, so there would be no interaction on the panel. Look into event structures if you aren't familiar with them. You cannot lock the user from clicking on things on the web browser (as far as I know) based on your limitations.

The standard file writing VIs open, write, and close the file all at once if you give it a path. If you open the file first and pass the reference to the Write to Binary File, then it can append the data. Look at the help for the Write to Binary File VI. David

I am unsure of what you are asking. If I am correct, the LabVIEW app is sending information to the other application via the API send key functionality. The LabVIEW app is frontmost, thus capturing key/mouse input. At some point the LabVIEW app will be sending information over to the other app, and you want to avoid anything happening while this occurs. But since your method of communication is through sending keyboard data, you are stuck. You can ignore keyboard and mouse events in your labview program by either discarding them with Filter? events are by treating them differently based on some flag set in your program. You can also have your code for the sendkey called within an event structure, which by default locks the Front Panel from keyboard and mouse until the event is done being serviced. This may be what you are asking. If you want to prevent the user from changing focus from your LabVIEW app to another app or Windows toolbar, etc. then I have nothing to offer. David

So at what point does a project become 'large' enough to merit using GOOP over something like LCOD?

So based on your previous post and looking at the map of where you grew up, I presume that people from the nearby town of Dubbo were often teased.

If the files really are huge, then dead space is not much of an issue. It can't affect your overall file size measurably. I know people don't like wasted space, but if you design the file structure that way the "dead space" converts to "reserved space".

I was going to mention that -- I'm glad you did. This could be the main reason to use a temp file, I suppose.

I think it is quite elegant. I have used this and it provides you with a lot of flexibility of naming files after the fact, optionally saving files (i.e. deleting the temporary and not creating the file w/ header), and putting in header comments that reflect what happened during a data run. If this is the environment you work under, then it works quite well. EDIT - I forgot to add that for large files you can write a fixed length blank header as big as you will ever need. A 1k size header on a 10MB file is hardly a drop. Then you can write the true header over the blank one after the fact and resave the file.

You can use a Select block for just two inputs, or a case structure for more than two. Other things can be done, but this is (I assume) what you are looking for.