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

Hi Michael, That works great! It wasn't obvious to me, but maybe it should have been. I'm rapidly converging on code that does what I want, and now I know how to build it two ways! There is one more thing that is peculiar. My basic control is an array of clusters. I am building a run-time shortcut menu and then want to select an item from it. I can build the menu by registering a dynamic event "Shortcut Menu Activation?", with either a reference to the whole array or a reference to a cluster as my source. But if I want to get the user selection by registering "Shortcut Menu Selection (User)", it works only if the source is the reference to the whole array. If instead I drill down to the cluster reference, the event never fires! I have tried this both your way and Ton's way, and the behavior is the same, so I'm pretty sure it's an underlying thing about how LabView handles events. Is there some way that this behavior is intuitively obvious? Best, Dave

With Ton's helpful suggestions, I was finally able to get Ton-style dynamic events working. My overall impression is that Michael's method (above) is very compact, because the event registration type definition is handled implicitly. Ton's method does that part explicitly, but this could lead to cleaner code. I've made a minimal example of Ton-style dynamic events in XControls, similar to the one Michael posted above for his method. Enjoy! Best, Dave

After a lot of tests, Michael's code works well for me... as long as there's only one event I need to register. I tried to extend Michael's code in a simple-minded way to handle multiple events, by adding another element to the RegEvents terminal. Suddenly I was no longer allowed to connect to the dynamic events terminals! I could still select any event I wanted for RegEvents, as long as there was only one event. I don't see why this should be. I made sure the dynamic event terminals were no longer linked to a specific refnum typedef by eliminating all dynamic events, restarting LabView, and replacing the dynamic event code. Still I couldn't connect to the dynamic events terminals. In case this is a basic problem with Michael's method, I've been trying to reverse-engineer Ton's method from the Boolean XControl on the code archive. However, I still can't get it working for even one event. Does the registered event have to be a user event? It seems that way from the code. Also, I could be missing something in the Display State Change event etc. Ton, I'm sure you have many calls on your time... but could I ask for a simple template similar to the one Michael provided? I think it could also help other people in the same situation. Best, Dave

I got my control working by basically copying Michael. Ton's method also makes a lot of sense and I'd like to try it out, but I have to proceed with my project right now. QUOTE(Michael_Aivaliotis @ Oct 11 2007, 08:21 PM) Looking at other examples that don't use XControls, it seems like I should unregister the event just outside the Facade while loop when using Michael's method. However, when I add the unregistration there, the event never fires! Could I please have another hint? I think I still don't understand the underlying architecture here. Thanks, Dave

QUOTE(tcplomp @ Oct 11 2007, 07:16 PM) I tried "Mouse Down" as an event as well, but still nothing. Sorry. Since this kind of thing seems to depend on all kinds of quasi-hidden settings, I'm attaching the whole VI. Best, Dave

I did add another event case to the Facade as Michael suggested, with just a indicator to flag whether the event fired. Still the event never seems to fire! I double-checked my code against Michael's code, and couldn't find any differences. Best, Dave

Thanks for your helpful comments! Michael, sorry if I'm being stupid, but I don't see where the dynamic event shows up in your code. I only see the event registration part. I tried adding a case to the event structure of the Facade to handle the event, but still nothing happens. Also, don't I have to unregister the event somewhere in the code? Ton, I did look at your code, but I need to allow user operations to trigger event registration... I think this wouldn't be possible using the Init ability? Best,Dave ps. The whole point here is that I am trying to implement the hack described by Norm Kirchner in post #5 of http://forums.lavag.org/Events-from-an-arr...ters-t8825.html. The FP of the Facade is an array of clusters, and when a user clicks on a cluster, I need to get the refnum for the cluster rather than the refnum for the whole array.

Dear all, I am trying to use a dynamic event inside the Facade of an XControl. The event registration seems to produce a refnum, but the event case doesn't execute when the event occurs. I don't have much experience with dynamic events, but I read Ton's nugget on the topic. Is this a difficulty with XControls in particular, or am I just doing the event wrong? Thanks in advance, Dave