Grampa_of_Oliva_n_Eden

My wife has been trying to get me in a kilt for years. I believe should found the Anderson tartan available from a place in Cananda, I suspect the same as yours. Aside from the interesting situation it presents in the airport security lines, I have been shunning the idea. You are a better man that me! Congratulations on the mile-stone. Ben

Why not take a leason from the 7-Layer model and look at how packets are transfered specifically, design a generic envelope that you can pack any type of data into adn ID the type of packet. So something like 32 bits message type 32 bits length of the data The first value will tell you what language is being used, and the length tells you how big the data is. A quick check of th first value will tell your software if it can handle the protocol. if it can then look at the data. Just my quick 2 cents, Ben

Search the Dark Side" for the phrase "Controls on the fly" for many threads on this topic. The easiest aproach uses off-screen hidden objects that are placed there durring development and shown/positioned/sized/labeled at run time. That is the easiest approach. The other exteme approach uses a picture indicator to render the images of the objects and explicit code is developed to handle the user interaction with those objects. My latest version of this approach took me about 3 months to design, document and then develop, so to don't run to that extreme unless you have to do so. Try to nudge the requirements such that you can put some upper limit on the number of the possible widgets and use the simplier approach. Ben Discalimer: The approach I described above was first inspired by a post by JPD and is just my interpretation of that idea.

In this above exchanges above a point that has not been made is "What is the app supposed to do?" If the app has no no UI requirements, then it seems complete decoupling is possible. He#$, I wrote one of those 12 years ago before I knew what OOP was. THe GUI only had a bitmap of the folw originally imagined by the customer and nothing else. But then again if a an app does not have a GUI is discusions of decoupling form the GUI becomes a high-tech version of "If a (an) tree (app) falls in the forest (lacks a GUI) will it make a sound (can it be decoupled)?" So continuing on my philosophical trek... Interacting with widgets and devices When I write code to interact with GPIB widgets or DAQ devices, I do not start by switching to kernal mode but rather reply on the methods and properties offered by VISA and DAQmx. The Classes that use those services, are coupled to those services and depnd on them to work and will break if they go away. Provided the app has to interact wiht real devices (simiulation not concidered) the code will also depend on the functions/commands (services) offered by the widget and it will suffer if the used functions go away. Now to apply what I think Feilix was saying... VISA is an abstraction layer that reduces the coupling between code and widget. LV offers a set of virtual objects that allow us to interact with users. If our apps have no UI requirements, then the virtual objects services are not required and decoupling (disclaimer: implementing a global abort in batch type apps, I have not pondered in this context). Three ways to implement a GUI? I'm just musing out-loud so maybe more. Traditional Prior to LV 6i we did not have property nodes and control references but rather we had attribute nodes. We had two choices, use the native LV controls "as-is' and avoid attribute nodes, or "over-ride" the native operation and use attribute nodes to do what was required byt the app. Still attempting the work on my vocabulary... the GUI and the code were tightly coupled. You had to ""ctr-A Ctl-C" to duplicate the apps GUI functionality. Complex LV apps that date back to LV 5.1 or before had very complicated diagrams. THere is an example of of a "bad diagram" over on the Dark-Side that I am convinced was developed in LV 5.1 and upgraded. Cotrol References: With LV 6i we picked-up the ability to move the code that did complex manipulations to over-ride the native behaviour of LV's widgets into sub-VIs. This provided a level of abstraction we did not have previously. We could now write sub-VIs that performed a common function by acted on different objects. They let us implement a layer of abstraction between a class of of widget on the GUI and code that used that widget. Concrete primitive example - Back in 6i, it was still common to poll a cluster of booleans for a command or a mode change. I wrote a re-usable AE that would accept the control ref and return the name of the first boolean true. It could be used on any cluster of booleans blah, blah, blah, It added a layer of abstraction to a a widget of type "cluster of boolean" and de-coupled the code that used it from the actual instance on the GUI. To use this primative abstraction level, the code that used it had to have some knowlege of what object it had to work on (the cluster the user clicked on was tightly coupled to the opeation of the application) "Expert Pattern" (?). In this case the code that used the abstraction layer (AE) "pushed" the control ref to the AE. "With great power comes great responcibility." (I don't know the author) But control references, even in these early days could be dangegerous if property >>> value is used to store data rather than a way to query or update a user. I feel this would be tight coupling and can become quite restrcting. Time goes on... we learn more about control references navigating same and some more complex applications of control refs. Dynamic event Structures - another double edged sword that helps to couple or decouple. I tend to think that dynamic eevnt structure as a powerful decoupling technique. Going back tot those Old apps... If an app was not in "Supervisor mode" we could not respond to a button so the "Non-Suppevisor mode" had to "Not_DO_Something". So turning on and off events feels like I don't have to worry about the stuff I'm not supposed to do since it just does not happen (the event is not registered and just does not fire) so CODE RUNNING IN event stuctures become less coupled to the GUI since events only fire when appropritate. "Code running in" events only run when they have to run adn when they run they do what they are supposed to do (e.g. The "load Design" button does the same thing when one button is pressed in design mode and another button pressed in operate mode). "The other edge" that come with Dynamic events enters when we concider when to register/unregister what, when. The app has to answer those questions and "someone" is responsible for knowing how to find those answers and is therefore tightly coupled to the GUI to implement the non native LV functionality (control don't hide show themsleves, yeeessshhh!). "Somebody" has to do it. This part of the code is coupled to the GUI is coupled to the GUI in the fact that the widgets it hides/shows registers/unregisters have to be available. They don't necessarily have to be a particular widget on a particular GUI. Provided there are are compatable widget SOMEWHERE, it could still work. Example: My lame example above. I could have nested modes of operation tht the operator moves through using a series of clustered booleans. As the modes change the cluster get hidden shown based on the button presses. The same sub-VI could execute on all modes to figure out which button wa clicked and different event cases would caall that sub-VI depending on event registrations. But if another customer wanted to use the same application but wanted to implement it not doing the hide/show thing but rather present pop-ups wiht the clusters, the code runs the same but operates on different yet compatable widgets (I admit I would avoid adding this level of complexity unless the app required it). Another Tightly coupled applicaiton of events is the use of "Event Signalling". THis seems like a tightly coupled situation but I have not thought about that twist yet. So because my wife tells me the pot roast is ready I'lll wrap it up now... The coupling between code that has a GUI and the object offered by LV is similar to the coupling between apps and the widget they control or monitor. We can have apps that are completely decoupled from the GUI if it has no GUI requirements. As long as there are "special requirements" there will be coupleing. XControl are probable an example of decoupling. Take care, Ben

AS the son of and brother to sewing nuts, I recalled one of those "accidents" with them "auto sewing" themsleves. I hope all works out well. Ben

Question: This idea comes to me because I once read that LV was an early inventor of the idea of "time" in programming (I don't remember when or where). Is the idea of "Time" reflected in OOP ? I can't recall running across the speed ever entering into the game. Ben

Many of my apps came to me as "NI said it can't be done" (or antoher third party)due to the extreme performace demands (Real-time NDT is an example). These apps typically can not tolerate using the UI thread (which is required if using property vlaue nodes)to do the updates. Additionally duplicating data is a big no-no since there is barely enough memory for the first copy let alone the copied version. So althought Decoupling and OOP ideas in general are useful when developing, if my apps is the "perfect LVOOP" app but runs like a dog, its harldy perfect. Ben

First time I took it it was a trivia test on LV. There was some coding but not much. THen they re-did it and it was coding test along with some Qs. If you are not a CS type make sure you know the vocabularly. Since then the recert is supposed to be just questions, but I have not sat for that since they changed the re-cert. Remember you are being judged on Architecture not coding. Leave the coding for the developer that gets your design. Ben

We're on the same page. The point I would like to highlight is decoupling, although desirable for flexibility and re-use is not nessarily desirable in all applications and should be carefully balanced with other requirements. Ben

"There is the rub" (Hamlet, Act 1 scene 1 ?) Ben

Extending the pun with a Pittsburgh twist... Years aago I was helping Mister Roger's Neighborhood with a printer problem. It was a unique experience. I came away thinking that acting like Mr Rogers was a req to work there. I told them iswould be couple of days before the printer would work and wa about to cover my head (since that is when customers want to hit you) when my contact replied "That's OK Ben, want a cookie?". So on my return trip the admin assiatanst wanted autographs so i got them sorta what the they wanted. Now the real nut-case in that gang ws Mr McFeely how is actually the author of all those shows. He had an office with pidgeon holes up the the ceiling with all of the old scripts. When he asked who the autograph was for and I indicated one of the secretaries he signed his photo with the message; "Stop down some time and find out how I got my name." Ben

I have done the system that tested out the new fuel pump for the JSF and the sytems that tests the GPS for cruise missles. I document everything with the assumption my audience knows little about software. The final code get deployed with diagrams in the BD detailing the states with each state being very boring. Ben

Far from the GD and adults skipping, LOOPy reminds me of the song from "The Music Man" "Shaboopy". Ben

And since I have to code for LV basics I & II customers, I stick with the references since adding code to get that extra degree of "uncoupling" would not sit well with most of them. Hell, an Action Engine seems "overly complicated" (actual quote from customer) to some customers. Take care, Ben

As far as i can recall, this is the first serious discusion of what Decoupling the UI really means in LV. Question: Is ther anyway to interact with a LV FP without using ActiveX via properties or methods? None come to my mind. So my gut feel for what the term "Decoupling the UI" means in LV has to assume the the use of control refs somewhere in the game. I think I am coming down on the JG side of this discusion since differnt GUI's that provide the same set of controls and indicators (think of these as different classes that expose the same properties and methods) the underlying functions should still operate regardless of how I have re-arranged things. But I am just and old wire jockey and these CS concept are not my area of expertise. Take care, Ben

I am in a similar situation. This thread on the Dark-side http://forums.ni.com/t5/LabVIEW/Strange-Problem-Cluster-of-References/m-p/1110076#M490461 has images showing how I seperated the GUI from the logic. Once i have refs to all of the FP object the underlying code can run under any FP that has that set of objects. Technically speaking the control refs still represnt a dgree of copling that I could work-around but then I get into text based solutions (control names to find refs) that I avoid since it would only open me up for typos and any LV implementation that leads to the potential of typos feels like an oxymoron to me. Take care, Ben

With the right person leading it, yes. Please note: I am not management and I do not speak for them. Take care, Ben

I hve to update my previous staements about LV 2010 seems OK. Friday, I was on-site edittting someone elses code. While dropping ms tick counts in the 30 or so frames of a flat sequence I was experiencing crashes regularly. It took about 7 crashes to get teh changes made. After seeing it for myself, I called the inside sales rep and got the process rolling so the customer can use LV 2009 since he does not need anything new from LV 2010 and he has to get his code finsihed. So with large diagrams, LV 2010 is a real pain. Ben

Thanks for the segway Chris! Data Science Automation is hiring now. We were started by the first person outside NI certified as a CPI, are lead by the 5Th CLA in the world, have two resident LabVIEW Champions and have one of the highest concenttations of of CLA's you can find anywhere. Interested parties should check out DSAutomation.com for more information. But on second thought, maybe that is not what Chris was hinting at. Ben

Thanks for your KillerKiloposts ! Any time I have spare grey matter to toss around I will try to catch-up on your thoughts. Take care, Ben

Many of my apps require high speed as req #1. My slaes team seem to be able to find those projects that "almost work" but perfomance is lacking. There are at least three dedicated developers in my office that are working projects that started out as "fix the preformance" to start out projects. years ago (whwn I was just a wee-G-babe) the big boss lamented durring a meeting "why do so many of our apps suffer from performance?". So now we design for speed and we seldom here about perfomance thses days. The actual work process flow differe little from not keeping an eye on performance. VI development starts out with simple questions; 1) How large are the data sets for this VI going to to be? 2) How often is this going to have to run? If the datasets are small and the code runs infrequently, just code away. If the code could affect performance, approach it delicately. Take care, Ben