jgcode

SORRY! It was late when I posted, and I was excited just to be back on LAVA and I forgot... [running out of excuses...] Done now tho

Asbo I like your style! FWIW I always use and always wire through the error terminals . Because I am of the opinion that I never know in the future if they will be needed, and if they are then all the work is already done. Edge cases is if I am really, really sure (normally for reuse functions). I like what you have done as I like the fact that if the error in is not currently used, but I can give the developer a visual indication of this on the BD. In the future if error handling changes I just update the icon, but the connector pane and how its wired does not have to changes - that seems quite safe to me.

Cool! No probs.

Yes, I think you are taking the name too literal. They are called QSMs cause when you open up the NI manual it calls the design pattern a QSM (I don't know who came up with the name). As a side note the traditional name for the String Based QSM is the Queued Message Handler which is exactly what the JKI QSM is based on (string based). Now I understand what the "Function Machine" term was referring to. But I think NI have coined the phrase Multi Functional VI (MFVI) already (sorry mesmith!) which is basically the(their) State Machine pattern combined with a FGV pattern - which when you look at the QSM is fundamentally what it is (along with the ability to queue itself). I agree the terms are confusing, bear with me here: I hold state information in USR (FGV) and runs different States based what wired into the Case Structure. The JKI combines the User Event pattern as well (all of this is NI terminology). Now when I say state information this is really the state of the objects in the application. This is normally implemented as a cluster (or class) of objects - but it only just acts as a container. When I say States, I am really referring to Commands (so I agree with your expression of this). In terms of using States versus using SubVIs - I guess this goes back to our conversation about documentation in the CLD wrt MFVIs vs LVOOP: In that you can create single a single VI with many states or you can create a lot of subVIs (and I was discussing which would be faster/easier based on the time limit). So this is what I refer to by State and is why I talk about interchanging State with SubVI and when is the best time to use one of the other etc.... I find it comes down to management and how many different files I want to manage. I normally like to try to keep the QSM light on files (subVIs and typedefs) as long as its neat, whilst I prefer lotsa subVIs for my functionality and encapsulate that using LVOOP. So yes, maybe calling it a State Machine is bad? But it seems quite strongly part of the nomenclature of LabVIEW now to change it! But by all means go for it - although I have to teach it, so I will have to stick to it In terms of when you talk about State in this context - I usually try to encapsulate this inside an object. So in terms of your Soda Can example the Soda Can object would manage its own State. Having a QSM managing many objects' States would be very difficult. But these objects (may) needs to live inside a GUI - this is where I use QSM a lot - as the architecture for the GUI. But the QSM is not handling the Soda Can's State, it's simply calling and running the Commands from e.g. the User Interface. In some cases it will be up to the Soda Can what to do based on its internal State. I have found the QSM a great architecture for the GUI, and scalable too. From you images it looks like you have a string Command from a Queue wired into a case structure. Is this not some form of QSM (in the above sense)? It also seems you have taking messaging a step further and implemented the famous design pattern that Paul-At-Lowell raves about (he was threaten to post this recently, but this is the first LabVIEW example I have seen). So I am not familiar with it, and only know what I have read in HFDPs and wiki. But if you would like to, please feel free to post more on this as I am very interested in this as it seems you have a higher level of abstraction here. This raises the following question of interest about your style and application including: 1) How do you handle smaller GUIs. For example if you have a small application with a main GUI and 5 smaller dialogs (for data entry etc...) do you use this pattern (and separate GUI and Engine) for all of them? 2) What about really basic dialogs? 3) In the example you posted it seems like there is a great deal of work gone into the messaging, do you have a reusable framework to build from? Cheers -JG

Hi Martin Not sure why a VI opens when you load the LabVIEW Project - it should not load any VIs into memory, only check dependencies (I think). But there is a Show Front Panel When Loaded option in VI Properties that you may have checked causing this? Cheers -JG

Hell no dude, I am here to learn homie... And solid feedback/discussion is why I post here for. I have been trying to digest your code, and haven't had time to reply. Note: Even if I got shot down in a pile smouldering flames, I wouldn't care as long as I can take something away from it. Thanks for your time posting all this stuff, i'll replay in details soon.

Thanks for your feedback Abdullah and good luck with your exam! In case you didn't know, National Instruments taught that method in their Intermediate I Course. I thought it was a nice way to handle the requirement of stopping the application on an error. And decided to implement it given the time constraints. I think this is a great point, and something I strive to do. However, it would be really great if you could post your code, or rather images of your code, to demonstrate how you would solve these issues (or similar ones) writing simple code. I always love to see how others are thinking and their style.

No! I mean this: Ultimately we're all trying to create good software that meets our customer's needs. More so the trying to create good software (much more fun). Pardon my ignorance - what is a function machine? I tried to google it but came up blank. I have not heard the term before. However, passing arguments is a requirement IMO. Otherwise there is no way you can e.g. set the UI to Set Cursor Busy then Do Stuff then Set Cursor Idle in a Macro. But again you shouldn't abuse this (arguments). So you should not use it to pass data, as in application data - that can get buggy. And it is just as bad as using e.g. locals to store data. All application data should go into the State Cluster so it can be used by another state. Or more specifically (for me) I like Objects within the State Cluster only. I use the argument feature for messaging not for data transfer (I hope my distinction makes sense). By-val is always safer and easier to debug. Well, there are a couple of things I need to think about if the UI is going to go off and churn away for x seconds. 1) Firstly, do I really need or want the User to be doing anything else on the FP whilst this is happening? If the answer is no I don't want them to, then I just Set the Cursors busy and disable the FP whilst the thing churns away and does what it has to. Then I enable the FP once done. I probably don't want to give the user the option to queue a heap of things at one time. 2) If there is a requirement for an Abort function then: a) Should that operation run in its own separate Process? b) Should I separate the UI from the Engine - will that suffice? c) Can I use the natural loopingness of the State Machine to run the process and check the UI for the Stop as well? These would be functionally dependent on the app itself. None of these are show-stoppers to do. Programming 1) and 2c) is less work then 2a) and 2b) and then I would normally add another QSM to do this. Yes you have. Allows, yes. Encourages, no/maybe. Can these flaws be totally eliminated or through good programming can they altogether be avoided? Is any design bullet proof? I guess that is no different to everything else - even for the most evil of things: globals, sequence structures etc... Everything has a place IMO - (some more that others tho). But the blame should not be on the QSM, more on the programmer. I don't have a cut and dry response for that. It depends on the application. Sometimes its easy to use states, and if the function of the VI is simple there is no reason (for me) to be creating a bunch of subVIs and even typedefs I have to maintain. So I try to avoid that initially. Normally for data entry screens, or simple screens that is what I do. Normally for the Main VI/GUI I can see from the design it is required or I guess and put in the extra work up front. Of course that is what refactoring is for. I haven't not been able to, or had major issues with, up-converting a simple approach to a more complex one. That one of the other things I really like - its a really scalable approach. I always learn the best lessons from the mistakes I make. Well then how to you stop the execution of ABXYZ? If ABXYZ are separate States you could insert (into the Queue) an Abort between anyone of them. Plus then if you wanted to create ABYZ or XYAB or BAZ if would the case of having five states then creating the required Macros. No need in creating more SubVIs - which would be a bit more work for the same result. The benefits would increase if if you add more Letters to this. Adding one more state then writing another Macro is easier and more readable then more SubVIs. Additionally it would be much less work if you ever wanted to change the order of things - just cut and paste strings rather than blocks of code. And you can always modularise that approach too - stick a Macro in a Macro. That way you can reorder from a top level (Macro) and maintain correct logic or you can rearrange the order of the SubMacro and it will persist across all calling Macros. Yes, but other than simple apps, apps need to be able to message between parallel processes, listening for asynchronous events etc... The above approach would be very restrictive? As long as messaging is logical and has an interface it should be easier to track and debug. I.e. search for this VI as messaging can only happen through there, better yet, Events allow you to create Static messaging (datatypes defined at edit time) which can be (more work but) safer than e.g the single interface with a variant datatype. So there is usually no way around it.

This is a really good discussion (aside from the wanger references of course ) - would you mind posting up some example pictures of how you like to do it also? I think that would be helpful (for me at least).

Take off your shades... it not so dark over there

Just quickly - when I say "Macro" it doesn't have to be an actual Macro it can just be prebuffering (queuing of States). Use a Macro when those Queued States need to be called in more than one place Yes, having States queue up other states is where cracks start appearing in the great wall. The Macro should drive the QSM. E.g. Button Pressed - do this, then this, then this, then this, then this. Then this should never decide to then do that or maybe this, or maybe that? etc.... I don't condone logic like you outlined above, that has headache written all over it. Why not have just one Macro: XABYZ If you ever want to run a different sequence then create a new Macro e.g. XYZ I think you also highlighted an issue with a global queue - if any one can stick stuff into it that is not that best design IMHO. If it has to go though an interface that is always going to be much saver. It can then be vetted by the Process. The JKI QSM queue is always internal to the Process (its by-val), and therefore can prevent bad stuff from happening. I also find using LVOOP on top of that is where more re-usability comes in. In terms of you saying "stick it in a SubVI". It helps it all to be much cleaner. Can you ever really control for this? If you know how to 100% stop douche bag programmers from making dumb decisions please let me know. I am pretty sure I could come in and wreck yours or any application very quickly if I wanted to regardless of measures taken Its called discipline (refer to douche bag comment above).

Unfortunately that is not much of a challenge - as I already try to program like that (try being the highlighted word)! I either put the logic in the case or stick it in a method/integration VI) if it gets too big or messy. I strive to map each function/input to a single case (ideally). I am thinking we are trying to achieve the same process here, I just prefer attributes of the JKI QSM to do it. The Macros are handy as I can then call UI update methods if I have to on a single button press etc... and I get to share statefullness with the UI Structure. I do have States that contain reuse states, but I try not to let this get out of control (there's that word again). Because I agree with what you are saying: Stick it in a SubVI for reuse - not in a State. I used to abuse this concept and ended up with the most complicated logic and state transitions and a mammoth number of states that was a nightmare to work with etc... Since then I have been to State Machine Rehab and will not lapse back into my former ways.

Damn, I might get shot for posting this here, but the NI Forums just had a major upgrade. Looks pretty sweet thus far... Read about it here [JG ninja rolls & ducks for cover...]

Is that sarcasm? If not see here (I only use Opera for browser testing).

Allow X-Control/X-Control Reference as a Class Data Member

[idea posted to the Idea Exchange forum]

Do you have a personal preference over which display method would be ultimately advantageous - or are you happy from a user perspective of the current implementation?

Hi Joachim There are no attachments with your post. Cheers -JG

Hi Paul Are you able to, and do you have the time, to post up examples of your Command Pattern and State Pattern using LVOOP? Cheers -JG

Haha! I was thinking this exact same thing when I posted up the Idea - but I wasn't game enough to write it Kudos for balls!

Display Qualified Name in Inheritance Dialog Box for LabVIEW Classes

I guess only because its not "in your face - obvious" as the eye is drawn to the list. I would obviously prefer a qualified name although I like the idea of it being nested, I think that would be nicer than one long name? Regardless I have posted this an an Idea

Classic!