jgcode

Just to be clear I don't agree with the above programming methodology although to be honest, thats what used to do when I started using LabVIEW but I consider it a very bad way to program now (as I am sure I have mentioned before). It is an assumption I guess that is made when talking about using QSM etc.. I may have dialog boxes shown based on the that state of possibly multiple classes within an application. I guess in this case, and for a simple example, it would be based on the configuration of the application and an event occurring rather than an enum e.g. attendedMode = TRUE AND exceptionOccurred = TRUE. But you still need an architecture that sits behind that dialog box - the engine/process that runs it. And using whatever implementation, I agree, it's function should be solely to present information to the user and possibly allow for user input, not affect execution logic. Using your presented example: If the system is running in "Normal Mode" and an exception occurs that you want to present to the user then I image in implementation could be as follows: 1. Pass Object as an input for the Dialog box 2. Run method to format information to string (possibly do this before passing to Dialog) 3. Get Exception string from Object 4. Display String in Dialog Box 5. Allow the user to enter a Comment in a "Comments Box" 6. If User presses Ok, Set Comment information to Object 7. If User presses Cancel, Set a predefined, default Comment (to indicate it was cancelled by the User) / leave blank etc... 8. Pass out Object that now contains the Exception Information and now a user Comment Depending on other State data the Application logic may decide to 1. Discard this data 2. Log this data to a network share 3. Log this data locally Now if the Application was configured to attendedMode=FALSE then application would make the decision not to show the dialog box in the first place, would instead run methods to format the Exception data to a string and maybe Set a default Comment to indicator not attended etc... But the application would be still be using the same Class methods called by dialog box - so that functionality is encapsulated and reusable Therefore, with all functionality encapsulated, it has nothing to do with the Dialog or it's implementation. Its separated. Put simply, the Dialog should call Get methods to access Object data and Set methods for User input etc... So all the above options have absolutely nothing to do with how the data is displayed to the user. And the architecture of the Dialog used (to display the data to the user) has nothing to do with the Application making the decision to: 1. Show a standard dialog box 2. Show a high contrast dialog box OR 3. Do not show a dialog box. 4. Other (expanded for more functionality) Now I am sure you can implement the Application Logic using advanced design patterns that incorporate LVOOP - and that is what I am really interested in (and what the community is calling for at present). But I still consider the QSM an important building block of my application for example, in order to implement the Dialog Box you get a new requirement (and for want of a better example) that says "the User Comment must be at least 20 characters long" (as management think this will make the attending user less likely to just press "a" <enter> and carry on). Therefore when the Dialog is open the User types in a Comment that is 10 Characters long. Your dialog (e.g. on a Comment Value Change Event) would then 1. Check the entry 2. Decide whether it was valid (>= 20 CHARS) 3. If valid enable Ok Button 4. If not valid display some text (contextual help) on screen that is a message saying why it failed In order for the Dialog Box to do either of the above, one way would require it queuing a message to itself in order to either enable the Ok button OR to display some message based on the result of the validity check of the Comment. Therefore, using a QSM would be a great way to do this IMO, and it would be an easy way to sequence these methods/commands/states. And I also see no difference using a QSM or splitting this out into two loops in the same VI whereby a Producer (User Event loop) sends a message to the Consumer (Working Loop). Whilst this may have the advantage or simple design, it is more work to implement and it has limitations in sharing statefullness between the two loops (as they are combined). The JKI QSM implementation can be considered a Producer/Consumer combined in a single loop. Additionally as this UI functionality is encapsulated within the QSM it can be broken down further it required based on changing requirements etc... It can also be reused throughout an application (depending on if it runs in parallel, but considering a standard Dialog) just like any other subVI/method etc...) So maybe in order to implement the above: 1. I start by creating the Dialog using a QSM without the need for any SubVIs, Typedefs or additional classes as it is so simple and its quick. The UI works and I don't need to spend that much time on it. 2. Changes occur to requirements and I refactor to make it tighter, using subVIs for reuse, typedef etc.. 3. More expanding features means that I need to start using classes or possibly x-controls to encapsulate UI functionality etc... 4. A new requirement means I really need to take it up a notch and do something advanced e.g. a skinnable UI for Standard and High Contrast views that would need to share an engine/process for functionality reuse etc... Now this maybe implemented a totally different way, but one way could be using multiple QSMs whereby the original QSM gets strips of FP objects and become the engine/process in a UI Class that would now have two UIs (both implemented as QSMs). Thats the thing I like is the flexibility of it all when I use the JKI QSM. If I would have started with option 4 when I really only needed option 1 (and for example, it turns the application only ever needed option 1) then IMO would have wasted a lot of time (the customers and mine) on implementing something I didn't need. I am also not bottled-necked in my approach as I can refactor the implementation at anytime to account for requirement changes.

HA! I'll keep that in mind - I have visions of a NSWmen charging like a bull at anything red maroon (I am from the West Coast so no dramas there)

The Workman skirt would be handy for going onsite with tools It takes a real man to wear a skirt...

Really? Damn that sucks, ...making choices much harder...

I'll be staying at the Hilton, and will be attending all standard events.

I am under the assumption that both methods presented thus far are valid (depending on what you are trying to achieve/ how you like to program). Anyone care to list their thoughts on known pros and cons of each method from experience?

This is one I want to attend but have a conflict. This is another I want to attend by have conflicts with the tour (which you have diss'd) and I want to check out the new licensing in LabVIEW pres too. (AQ mentioned this too) I am also thinking I need to weigh up which presentations will be available online (preferably online video). From previous years, I am guessing all NI presentations will be available online as videos, and most non-NI presentations have the slides available only Decisions , decisions.... (I really need a clone too!) I am coming in a few days early, so I have some time to site see Austin as I have never been to central US. Cool, if no-one minds if I tag along as I think this will be the best way. What time you do rock up to get down the front? Hi John. I have booked this one in, and am looking forward to it. I am also interested in how to use a LabVIEW Web Service for a larger scale app i.e. experiences/issues with hosting on a standard ISP server (if that is possible) etc... - Is this within the scope of the presentation?

I kudo'd it up on the Idea Exchange too.

For me, a programmatic build method refers to "automation" and therefore I don't normally stand there and watch it however, I do like to track the stages of building with messages to the UI. I used to have a timer running in a parallel thread however, running the NI Builder API locks up everything so the timer doesn't even update at slow rates. Anyways, I don't know how one would access the info from the API (if it was there) maybe by polling a resource in parallel or subscribing to an event? This would add extra complexity to your build process architecture which would be a pain IMO (and that is why I scraped the parallel timer and just get the total build time for interest). If the info is not available then maybe if the entire dialog (rather than just the info) was automated/included in the API; e.g. a parameter that was: Popup Status Window During Build = TRUE; then that would be easier to use in a custom build process? Maybe a post for the Idea Exchange??

I just got mine (in the mail) and I think it looks smashing in green.

I feel your pain on this one. The only thing I try to do is to integrate and build often so it narrows down the cause. Failing that, I usually have to copy the project and start stripping bits out and building 'til I find the issue. Also on rare occasions I have had "bad" files (e.g. a method VI) that looks fine but kill the build. I normally have to delete it and recreate it. I don't like the weird ones (where I can't explain the cause).

Is this feature available in LabVIEW 2010?

Thats a naming convention I have used with the text files before and I like it.

I will say this upfront: the only relevant info I can add at the moment is that I have seen this too in LV2009, and the build, of course, did not work. I can't remember what the exact issue was i.e. why - sorry. But I do know when the issue was fixed I was able to get it to go (I think it was to do with a known LV issue e.g. not allowed to put xctrl ref in a class for build or something like that).

Cool. Thanks for the advice. How much time to guys you make outside of sessions to see everything else (floor expos etc...)?

Thanks Yair, this is the only example I have "seen" with tabs - I will try to find Simon H's post. Yes, there a no subpanels either. The whole experience does not look like fun (compared to using standard LabVIEW)

Put me down (if ok), I would appreciate hanging with the natives to find the best local water hole.

I too distribute classes as .LLBs but I just manage a folder that contains the text files, so never found that a restriction with my application. The text files then point to the plugin class (e.g. relative path) as well as provide any other info I need. Using VIs sound like a good idea too.

Hi Shaun Tomi Mali posted a method for this wrt for plugin classes. It is not exactly what you are asking for, but it will have the same effect (and is easier IMO): Distribute the class with a text based (or similar) config file - that way you only load a small file and not the entire class (which defeats the purpose of a plugin!) to establish its type: http://expressionflo...-lvoop-plugins/ I have used this before and it works very well.

Hi Does anyone have any suggestions/recommendations for design patterns when using PDA type devices and LabVIEW? Obviously screen real estate is tight, so to view data for our app I will need multiple screens (and therefore an Engine/API to manage them). Compared to things I do in standard LabVIEW the PDA environment seems really limited - i.e. no VI Server for interacting with the screen etc... Can any post their experiences/ideas? And anything that would improve the usability of such a UI (i.e. from a user's perspective). Cheers -JG

Howdy! - Anyone got any tips for getting the most out of NI Week? For example a few questions spring to mind: Do the sessions rooms fill up quick? How early should I rock up to get a spot? Are there good seats to get? Should I book a session for every time slot? Or realistically will I not be able to make back-to-back sessions? What time should I rock up at the venue? What places are good to site-see around Austin? Any great places to eat? NI says there is a tour of their campus on Thursday morning - is that well worth a look (but it clashes with AQ's presentation tho ) Any sessions that you recommend? (Eyes on VIs has a list here) Etc... Cheers -JG

Here is a link the NI Week 2010 Community (previously, the darkside was saying that all posting was happening in the 2009 one)

I don't do a lot of image processing but I know a bit of the slang from using Vision: Region Of Interest

Can you not create your own?