DaveKielpinski

Unlike normal event structures, XControls have the odd behavior that you can register them for User Events, but firing a User Event doesn't wake up the XControl. There are a couple possible workarounds, including using a daemon VI to monitor for User Event firing. The new workaround is really simple: just add empty event cases to the XControl, such that any stimulus that fires a User Event also fires the empty event case. If the User Event comes from an actual user interface event, it's easy to find the right event for the empty case. I'm not sure whether the weird XControl behavior could be fixed in a future version, or whether it might qualify as a bug. It sure would be a lot more intuitive if the User Event would just wake up the XControl! There were some old threads about this already (e.g. http://forums.lavag.org/Dynamically-regist...15&p=40302) but I wanted to pull it together. Best, Dave

QUOTE(tcplomp @ Jan 6 2008, 01:16 AM) Thanks for that. It is quite clear. It seems like you work around the basic problem (external User Events don't trigger an XControl) by having the shell VI change the Val(Sgnl) property of the XControl. Then the "Data Change" event fires and the User Events are processed normally. For my application this means that the shell VI is a simple event handler that duplicates some of the XControl functionality. In terms of the self-similar XControl hierarchy I posted about (http://forums.lavag.org/XControl-hierarchy-for-event-handling-t9793.html), this means each node in the tree has to have a daemon VI to wake it up when it gets a message from a descendent. Does anyone know whether the basic problem will be addressed in a new LV version? It seems kind of silly to have some User Events fire in XControls and others not, but maybe there is an underlying reason...

QUOTE(tcplomp @ Dec 4 2007, 05:52 AM) Hi Ton, I've run into a similar problem and am having a hard time with it. Could you post about your solution? Thanks, Dave

QUOTE(Richard_Jennings @ Dec 27 2007, 12:50 PM) Hmm. I may have made this sound more complicated than it is. A message gets passed out from the XControl when a relevant event is triggered (SubcontrolEvent.png). The registered User Event in the shell then fires (ShellEvent.png) and any queued messages are dequeued and handled. I suppose I didn't HAVE to use a queue, but it's more robust. Is there a simpler way to pass messages between VI's? I am only suggesting this technique for relatively large applications (several hundred subVIs) like the one I am working on. In this case there is already a significant problem with debugging by other programmers, which is usually solved by encapsulation. I admit I have only programmed relatively simple UI's in the past, but I haven't found another way to encapsulate event handling in a self-similar hierarchy. Do you know another way to do this? Also, is dataflow really thrown out? Each subcontrol passes its data up to its parent, which collates the data from all its subcontrols and passes up the relevant data to the next level up the tree. The root of the tree looks like a simple control that passes out the relevant data collected from the descendents. The data from the root is dynamically altered by events in the subcontrols, so it's not necessary to recompute the entire root data every time there is a minor change. If the root data is large or complex, this could save on computing resources.

Well, this seems to have gone over like a lead balloon I guess it's either 1) tl;dr 2) a lousy idea Please don't be shy if it's #2, I would really like feedback.

Dear all, I've been thinking about how to cleanly write user interfaces for large applications. One major problem for me was identifying a nice abstraction hierarchy for event handling. Possibly this could be handled in LVOOP, but my attempts on that path have not been very successful. Recently I found a way using XControls and I'd appreciate the opinions of advanced users, especially those using LVOOP. As far as I can tell, an LV control is really a simple event handler with data in it. The events are just hidden - for instance, when you change the control value on the FP, the data corresponding to the control is updated in the BD. That looks a lot like what happens during the "Data Change" event of an XControl. So let's turn it around and take _XControls as the primitive data-carriers for LV, rather than regular controls. From this point of view, a regular control is a _restricted_ type of XControl because it only accepts certain NI-defined events. Now consider a tree structure where the nodes are XControls and the links are provided by a messaging system. Each node's Facade contains an instance of each descendent XControl one level down in the tree. For each possible event in the UI, we create an event handling case in the lowest-level node that is competent to the task. If an event in one node indirectly affects other nodes, it is sent up to the nearest common ancestor by the messaging system. The ancestor instructs the descendant nodes by altering the State of each node through custom properties, so the Display State Change case of each XControl takes care of downward messaging. It's easy to set up a second by-value tree that uses the Data of each XControl as a node and a Data Change event in the ancestor Facade as a link, so you can make a complex data type that is built up dynamically by UI events. There are some nice encapsulation properties to this way of building a UI event handler and it seems like it could be widely applied. I've verified that the upward messaging can be done conveniently with User Events containing queues of strict typedef'd Enum commands. If anyone is interested I will be happy to post code snippets to show what I mean. It might be really nice to have an LV class for the XControls that make up the nodes, but that is beyond my abilities right now. Best, Dave

QUOTE(Götz Becker @ Nov 15 2007, 06:17 AM) Actually, you are perfectly right. The bug I am trying to track down is not related to improper compiling - unfortunately! Thanks, Dave

Dear all, I have an FPGA VI with many subVIs in my project. I would like to compile the entire project at once, but I can't seem to find a way to do this. So right now I have to pull up 30+ subVIs individually and compile them at the rate of about one every 20 minutes, which is really inconvenient. Is there any way to do a batch compile of my project? Thanks, Dave Kielpinski (cross-posted to NI forums)

Thanks Ton! It is good to know about those "Plot Image" properties. Unfortunately the XControl I was envisioning will not work for other reasons. For instance, I wanted to have a graph X-axis with different scaling at different parts of the graph. This seems flatly impossible. I wonder if I am discovering the limitations of Labview. It seems like NI's philosophy is to make Labview the most general WYSIWYG programming interface possible. However, the permutations that fools like me can come up with will just exceed anyone's imagination. Of course it is possible to program in Labview in a way that goes against NI's philosophy, but if you take it to an extreme, you just end up programming in a graphical version of C without all the open-source user libraries. /rant

QUOTE(tcplomp @ Nov 5 2007, 08:40 PM) hmm... I'm only running 8.2.1 for the moment. I didn't find any overlay/underlay features for graphs in my version, and I couldn't find any documentation of such a feature on the NI site. As for code, I can show you lots of it, according to the things I previously tried (listed in my post). But it would probably be too tedious for you. The main problem is not actually overlaying the picture on the graph - I've got that worked out. The problem is that once I overlay the picture on the graph, I can no longer get events associated with the graph. Thanks, Dave

Dear all, I'm trying to create a UI consisting of a graph and an overlaid picture with various decorations. However, I need an event to fire when I double-click on the graph in order to get the graph coordinates for the event. I can't seem to accomplish this when the overlay covers the plot area - then the "mouse down" event can never be associated with the graph, only with the overlay. Solutions I have tried: 1) Change the order of the controls programmatically - the cleanest solution. You can do this in edit mode with the Align/Distribute/Reorder toolbar, but there doesn't seem to be a corresponding property for doing it at runtime. Am I missing something? If not, I think this is a significant flaw in Labview. 2) Move the overlay far outside the front panel window on the first mouse click, then bring it back after the second. This kind of works, but makes for an unsatisfying UI. 3) Use dynamic event registration to disable the "mouse down" event for the overlay on the first mouse click, so that the second click can be associated with a "mouse down" event on the graph. This would only work if disabling an event on a control allowed that kind of event to "pass through" to the next control in line. Unfortunately Labview isn't set up like that, so it also doesn't work. All this is a nice learning experience, but I would rather have a working piece of code right now. Could someone give me a hint? Thanks, Dave

Dear all, I'm doing some code refactoring, and the guy who wrote the original code had no idea about standard connector panes. So I have a bunch of subVIs that are called numerous times, and the connector panes are all goofy (error in/out at the top of the pane, etc.) Obviously I could disconnect the connector panes and rebind the front panel to the connector, but then I have to go rewire all the subVIs. Is there any way that I can just move connector terminals around the connector pane without unbinding them? Hopefully the wiring in the calling VIs would just move around with the terminal... Thanks, Dave

QUOTE(Chim026 @ Oct 22 2007, 10:56 PM) Now I get it! That's a nifty way to do it. I had just passed the reference in as data and registered it as an event, which was an ok workaround, but I think your way is better. Thanks, Dave

QUOTE(Chim026 @ Oct 22 2007, 05:24 AM) Hi Matt, I'm not really clear on what you're saying... some words seem to be missing in your post. Could you please rephrase? Thanks, Dave

Dear all, I've been building a multi-graph indicator that processes and displays the same data in different ways depending on which graph type is selected (e.g., as a time series vs. as a power spectrum vs. as an autocorrelation). At first this seemed like a good use for XControls, but each graph has different options that the user can change at runtime, and handling all the control options for all the graphs in a single VI seems unwieldy. Also, with an XControl, it seems like I need to perform the FFT on every data update even if I'm just displaying raw time series data, which is not so clean. Now I'm using subpanels for the same purpose, and this is very easy and clean up to a point. I have a single event handler VI that loads a different subVI into a subpanel depending on a user-selected enum, and when new data is received, passes it through to the active subpanel. This event handler works great and does everything I want. Now comes the hard part. My multi-graph needs to live inside a larger VI. Ideally I would like to encapsulate the event handler for the multi-graph in its own VI, and have it load the different graph types into a subpanel on the shell VI. But then I would need to give the event handler a reference to the subpanel that lives in the shell, and have the event handler invoke the "Insert VI" method using the _subpanel reference_. So I have two questions: 1) How do I get a reference to the subpanel in the shell VI? and 2) Can I wire the subpanel reference to a regular Invoke node in the event handler to insert the appropriate graph type? And maybe a third question: 3) Am I using the right approach to this problem? Thanks, Dave