JDave

Thanks for the ideas. The NICs are on different subnets, but I was not aware of that usage of StringToIP. Oddly the function shows both NICs even though the TCP Open does not correctly connect. I don't know whether it has anything to do with the XP Embedded, but I am going to just use a launcher executable. I have already spent way too long on this and I just can't make sense of why it is acting strange.

I am having some problems with a LabVIEW application of mine. It is set to auto-run on startup, and the OS is Windows XP Embedded. I am trying to add a NIC to the system to allow for Ethernet communication. That makes two network interfaces, since there is one built-in network interface that is being used for control of some internal RF ComBlocks. The problem I am seeing is when I attempt to open the connection to the ComBlocks I get an error because the correct connection is not made. Disabling the second NIC solves the problem, but even trying to hard-route a connection using ROUTE ADD doesn't. The only thing that has worked has been to have a launcher executable run at startup instead, and then after some delay launch the real program. However, if I put the same delay within and at the beginning of the 'real program', it fails. This all seems to indicate that the OS has not properly initialized the Ethernet connections at the time my application runs. I am almost resigned to just having a launcher executable, but I wanted to check and see if there was some way of querying the active interfaces available. Or if there was some way to force TCP Open to choose the correct interface that would be nice too. Ideas?

Name: Array Point to RowCol Submitter: LAVA 1.0 Content Submitted: 03 Jul 2009 Category: General LabVIEW Version: 8.0 Version: 1.0.0 License Type: GNU Public Potentially make this available on the VI Package Network?: Undecided Copyright © 2006, dsaunders All rights reserved. Author: dsaunders --see readme file for contact information Description: 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. Version History: 1.0.0: Initial release of the code. Click here to download this file

Name: Type Sensitive Popup Submitter: LAVA 1.0 Content Submitted: 02 Jul 2009 File Updated: 04 Jul 2009 Category: User Interface LabVIEW Version: 8.2 Version: 1.0.1 License Type: BSD (Most common) Potentially make this available on the VI Package Network?: Undecided Copyright © 2007, David Saunders All rights reserved. Author: David Saunders --see readme file for contact information. Description: Provides an intuitive interface for tabular controls containing multiple data types. Users can use various controls and datatypes. Users can also use provided functions for registering and looking up type parameters by control (as well as by column, row, or cell). When you click on a cell, a correctly positioned and sized popup appears allowing for a controlled and intuitive input. Appears like it is a built-in feature, not an annoying popup window. Features: - Supports tables, listboxes, multicolumn listboxes, trees, and string controls. - Implements many data types : string, integer, float, color, ring, boolean, captioned string, etc. - Can use multiple tabular controls in same program with no programming changes - Can pre-register controls with certain data types - Register the entire control, or columns, rows, and cells. - Can edit the registered data type by registering again at any time - Allows for different font sizes - Works even on modal windows Instructions: Run the Demo program to see example usage. To recreate -- 1. Drop 'TSPopup.Popup Cluster.ctl' anywhere on your front panel. 2. Create program logic, similar to the demo MANDATORY elements a. TSPopup.Initialize.vi (register for the user event in your event structure) b. TSPopup.Lookup.vi (returns positioning information, looks up any registered controls) c. TSPopup.Show Popup.vi (called in a Mouse Down? event case) d. an event case for the user event output from (a.) e. TSPopup.Close.vi (called at end of program) OPTIONAL elements f. TSPopup.Register.vi (register controls with popup type parameters) g. TSPopup.Update Cell String.vi (provided to show how to change the cell string after popup is completed) 3. Bring the Popup Cluster to the front on the front panel. Otherwise the popup will show up behind some of the other controls on your User Interface. Limitations: - Can't programmatically bring popup cluster to front. Must do this manually. Change Log: 1.0.0: Initial release of the code. 1.0.1: Added another demo using dynamically changing data types in a tree Removed LV version specific event handling (only dealt with LV 7.1) Fixed bug where headers defaulted to have same type as their column/row Fixed cluster scanning from text Fixed ring to default to index 0 if string unrecognized Changed the background event monitor to always be hidden Click here to download this file

It's comforting, after being away for quite a while, to be scanning the recent threads and see this one. Thanks, alfa.

QUOTE (Jim Kring @ May 27 2009, 10:30 AM) It was really cool to see something I started show up in your video! I am really glad that you were able to finalize it and figure out the scripting magic that I never did figure out. I would love to see what was done; I look forward to that!!Great job with the Framework! It is a great extension to the LabVIEW IDE and to the concept started with VIPM. Keep the awesomeness coming. David

QUOTE (alfa @ Sep 4 2008, 12:05 AM) It certainly matters where you are (and I am SO interested in finding out what percentile you fall into...). If you came up with the idea the only 1 in 1300 people are fully awake, did you manage to do that while not being fully awake? Aren't you inherently including with this theory that you are one of the blessed few? If you are then congratulations are in order. But as Rolf already pointed out, your ideas don't exactly encourage people to congratulate you. Though if about 1300 people read this thread, then you may help the enlightenment of a blessed soul.

QUOTE (Aristos Queue @ Aug 30 2008, 01:27 PM) I don't use libraries so I'm a bit confused by this. If I understand correctly, and if the feature of overlaying the access scope on the icon were developed, C.vi is would show up as public if dropped on a vi within B.lvlib. C.vi would show up as private if dropped on a vi withing A.lvlib. And C.vi would break a vi (possibly different overlay) if placed elsewhere. Is this correct? And that is the issue, that the access scope actually changes based on where it is called? David

QUOTE (crelf @ Aug 29 2008, 09:30 AM) The Icon Editor I created allows for placing images in the corners. It wouldn't be that hard to automatically place the proper image in the desired corner. However, this would probably require knowing the VI ref so you could query. (I haven't looked into this, so I am not sure that it is available for querying...) This is just another reason why it would be nice to know what VI the Icon Editor is manipulating. My current method for getting the VI ref works pretty well, but doesn't handle calling the Icon Editor from an Invoke Node. I use a background process monitoring for the rusty nail VI Activation event.

QUOTE (mballa @ Aug 27 2008, 06:29 AM) I agree that the scripting event is the best that is known out here in the wild. But it doesn't handle situations where it is called through an Invoke Node or from the palette editing area. ThSa even had a comment in his code that handling the Invoke Node was something he hadn't cracked. QUOTE (mballa @ Aug 27 2008, 06:29 AM) I would agree with PJM on this one, If you want to do several different things to a VI : Fix the FP, Set Description, Hide/Show toolbars, and Icon editing then you start with a Main that is designed to do this. Taking an Icon editor and changing it into a vi editor is not the best way to approach this. My current Icon Editor does not do this and I agree that cluttering the interface is not desired, but someone had mentioned that they liked this functionality. I can appreciate the convenience of having the two together if it is not intrusive (perhaps a menu option). However, I also like to have the filename of the VI so that I can parse it and auto-generate some text for the icon. It's nice to only have to name the VI once.

I was hoping to get some discussion on the points I brought up ... But if nothing else, What I really want is to know if there is some way to know definitively WHO the icon editor is 'editing'. This would be necessary for allowing things like editing the description. Can someone from NI point us in the right direction here? Is it at least something under consideration for future versions of LabVIEW?

Regarding 3-Button Dialog: I must say that the issue of performance is somewhat out of place when it is specifically stated that the 3-Button Dialog is a UI. Performance is really important for the work code that crunches in the background. But I have always heard that when it comes to user interfaces, maintainability and speed of programming is always more important than speed of execution. Is the user really going to notice the extra 20 milliseconds? David

QUOTE (LV_FPGA_SE @ Aug 20 2008, 06:25 PM) Good answers!! I would hire you if I could. This being that you also pass the test of having many good posts here on LAVA.