Lars-Göran

Name: CLL Dialog File Submitter: Lars-Göran File Submitted: 03 Jul 2009 File Category: User Interface LabVIEW Version: 7.1 Version: 1.0.1 License Type: Creative Commons Attribution 3.0 Potentially make this available on the VI Package Network?: Undecided Copyright © 2006 All rights reserved. Author: Lars-Göran Andersson --see readme file for contact information Description: This library gives similar functionality as Three Button Dialog.vi but with some extra goodies. It doesn't strictly conform to the guidlines for a dialog box, instead it shows my personal preferences. CLL (Common LabVIEW Library) is my way of tagging VIs that have made it into my library of reusable code. Version History: 1.0.0: Initial release of the code 1.0.1: Added version info to the description of CLL Dialog.vi Changed some default values for TEST CLL Dialog.vi Click here to download this file

Hi! Just want to give a link to some code I added a couple of years ago in the Code Repository: CLL Dialog.zip I don't want to join the contest, but maybe the code is worth a look anyway. /Lars-Göran

QUOTE(MATTW @ Nov 14 2007, 05:10 PM) Interesting idea, ignoring the internal queue altogether and instead use an external queue for both kind of triggers. I will try this out. I'll also have to check out the NewVal functionality you describe. Lars-Göran

QUOTE(MATTW @ Nov 13 2007, 07:38 PM) Hi Matt! I think there's one problem with your solution. If a statechart continously generates internal triggers, your external trigger will never have the chance to get into the statechart. What I would like, is to have the InternalQueue exposed to the ouside of the statechart, so that external and internal triggers are handled on equal terms. (The queue then of course isn't internal anymore, so perhaps it should be renamed to "TriggerQueue"). As mentioned before, we will then also have the benefit of rendering the loop around the statechart superfluous. And as you pointed out, if we could get triggers to carry data along, that would be great. I think I would prefer a variant instead of a cluster, to avoid sending data that is not of relevance for a specific trigger. Lars-Göran

Hi all! I have tried to come to terms with the statechart implementation in the Statechart Module, but I miss the option of running a statechart without the notion of iterations. I have experimented with sending external triggers along with variant data via a queue to the internal of the statechart. Here it is dequeued in a dedicated state, where the trigger is sent to the internal queue and the variant is converted to data and put into its place in StateData. Benefits of this model: - The statechart will run (without being in a loop) until an exit trigger is generated internally or received from the outside of the statechart. This is more like the original statechart concept. - You can send specific data along each external trigger. - You avoid this situation: When an asynchronous Run Statechart is waiting for a trigger, it has already read its Inputs making it impossible to send data at the same time as the trigger is generated. The model above seems to work, but wouldn't it be nice if this third statechart type (aside from syncronous and asyncronous) with its trigger/variant queue was built-in? If I don't get any serious objection to this idea, I will post it in the Wish List. Lars-Göran

Perhaps I should rephrase the question: does anyone who's not bound by the legal issues of the beta program any info? //Lars-Göran

Anyone having knowledge/gossip of the LabVIEW Statechart Module? NI made an invitation to a 1.0 Beta Program for this in april 2007. //Lars-Göran