ShaunR

Ooooh. Almost forgot. Re-entrant VI's and the cool improvements to them over time (cloning, place inside self etc.)

Especially as you used to be able to change probe properties and resize the controls (like being able to view strings as hex). Or maybe I dreamt that

Well. I think from that little lot that it's pretty obvious that we've reached an impasse on that topic and perhaps it's time to expand the scope of the thread so at least it has some technical content again. But I will finish off off by drawing your attention to the LV help because it was obviously something you were not aware off. So. OOP is great. It's fixes all the ills in the world. It increases re-use so you only need 1 program to do anything anyone will ever want. So might I make a practical suggestion? There is a very simple library in the the Code Repository that would be very easy to convert to OOP and actually (I think) is ideally suited to it (we don't want anything too hard eh? ). Why not re-write it OOP stylee and we can use it as a basis for comparison between OOP and "Traditional" labview? Then we can plug it in to the other things in the CR that also use it and see what (if any) issues we come across in integration. Does that sound like something you can commit to?

Indeed. Sorry. Couldn't resist I could never figure out why people went for these crazy colour schemes. Then I worked for a defence contractor where there was a specification for software user interface colours. When I pointed out that it was a colour defined for "Cockpit" software because of the way colours were perceived through tinted visors and that VDU operators are unlikely to be using the visors. They said "Oh yeah" and carried on regardless

I'm not a fan of the Image type for the vision stuff either. I keep getting caught out even though I know how it works. A lot of vision stuff I do requires acquiring and image then creating various masks and applying them (often one after the other or in various combinations). The UI though, normally requires showing of original images and the results of the various stages of mask applications therefore you end up copying everywhere so as not to overwrite the originals or the intermediate results of a mask. It gets very messy But my pet hate is that you cannot wire a VISA refnum to an event case like you can with DAQmx. But more generally, the "probe window" introduced with LV2009.

I'm. infamous

Polymorphic VIs.

Version 3.0

Marginally And on a very particular edge case issue that no-one else seems particularly bothered by Indeed. And I could probably level the same argument at you, since I do not consider my work flow atypical. Lots of what-ifs in there . Projects haven't always existed and (quite often) I do a lot of editing without loading it. But that's just an old habit because projects haven't always been around and I'm just as comfortable with or without. Perhaps thats the reason I don't see many of the issues that others see since I'm less reliant on config dialogues, wizards and all the bells and whistles (sure I use them, but it's not necessary). User lib? Don't use it; I'm not a tool-writer. I don't have any problems re-using my re-usable stuff, never have. To me it's a bit of a storm in a tea-cup Thats quite funny. The last project I delivered was about 2000 VIs (excluding LV shipped). Only took about 1 minute to load and run in the dev environment (including the splash screen ) . And that could run a whole machine. Well. that (I would say) is a feature of Labview. If the project also did it. then I'd be a lot happier. Sure there is a practical way; load everything in the project. Requiring a programmer to write extra code to mitigate a behaviour is not fixing anything. Suggesting that classes (OOP?) is a valid method to do so is like me saying that I've fixed it by using C++ instead. I was specifically thinking about the fact it deletes the mutation history so being reliant on it not fool-proof. Never But it's a bit cheeky re-writing my comment. . I was not referring to typedefs at all. I was refering to LVOOP in it's entirety. From the other posters comments it just seems that the main usage that it's being put to is functional encapsulation. Of course it's not a "significant sample". Just surprising. I'm not prejudiced. I hate everybody I have seen how it can help me. Like I said before; Lists and collections. I've tried hard to see other benefits. But outside encapsulation I haven't found many that I can't realise much more quickly and easily in Delphi or C++ If it works for you, thats fine. It sounds like a variation on a theme (additions to existing......modification etc) That fits with what was saying before about only really getting re-use within or on variants of a project. No it couldn't. Once machine might have cameras, one might have a paint head another might have Marposs probes whilst the other has Reneshaw (you could argure that those can be abstracted, but you still have to write them in the first place). The only real common denominator is NI stuff. And in terms of hardware, we've moved away from them. Thats not to say there is no abstraction (check out the Transport" library in the CR). It's just we generally abstract abstract further up (remember the diamonds?)

Better there than here

And very welcome you are too I think the main difference between myself and Daklu is that I write entire systems whereas Daklu is focused on toolchains. As such our goals are considerably different. Re-use, for example, isn't the be-all and end-all and is only a small consideration for my projects in in the scheme of things. However in Daklus case, it saves him an enormous amount of time and effort. A good example of this is that I spend very little time automating programming processes because I'm building bespoke systems so each is a one off and takes (typically) 9 months to design and build. Contrast that with Daklus 2 week window and it becomes obvious where priorities lie. Thats not to say that re-use is never a consideration, it's just the focus is different. My re-use tends to be at a higher level (around control, data logging and and comms). You might consider that I would be a "customer" of Daklu. (Hope I've got Daklus job spec right ) As such, I'm in a similar position to you in that the output tends to be monolithic. It cannot run on other machines with different hardware so I don't need "plug-and-pray" features

Indeed. they "behave" correctly. As indeed my procedure yielded, for the reasons I argued previously about containers. But they aren't immune as I think you are suggesting here (remember class hell?). Guess again Yes. That is effectively what you are doing when you use a Tree.vi. In fact. I would prefer that all VIs (and dependent s) included in a project are loaded when the project is loaded (i don't really see the difference between the "class" editor and the "project" editor and the class editor loads everything I think...maybe wrong). Of course this would be a lot less painful for many if you could "nest" projects. [ Intent is irrelevant if the behaviour is consistent (as I was saying before about containers). Although I hadn't spotted the particular scenario in the example, treating a typedef'd cluster as just a container will yield the correct behaviour (note I'm saying behaviour here since both classes and typdef'd clusters can yield incorrect diagrams) as long as either 1. ALL vis are in memory. OR 2. ALL vis are not in memory. It's only that in your procedure some are and some aren't that you get a mismatch. [ Well. there is already a suggestion on the NI Black hole site. To drop the simplicity of typedefs for a different paradigm I think is a bit severe and in these sorts of issues I like to take the stance of my customers (it's an issue....fix it ). But even that suggestion isn't bullet-proof. What happens if you rename a classes VI? [ I think it is probably due statements where you appear to assume that classic labview is highly coupled just because it's not OOP (I too was going to make a comment about this, but got bigged down in the typedef details ). [ I don't think he's against anyone. Just picking up on the classic labview = highly coupled comments. Once thing I've noticed with comments from other people (I'm impressed at their stamina ) is that most aren't writing OOP applications. I've already commented on encapsulation several times, and this seems to be its main use. If that is all it's used for, then it's a bit of a waste (they could have upgraded the event structure instead ). I wonder if we could do a poll? I'm right behind you on this one. One thing about software is that pretty much anything s possible given enough time and resource. But to give NI their due, perhaps the "old timers" (like me ) just haven't been as vocal as the OOP community. Couple that with (i believe) some NI internal heavyweights bludgeoning OOP forward I think a few people are feeling a little bit "left out", Maybe it's time to to allocate a bit more resource back into core labview features that everyone uses.

There are a number of ways you can go about it. It depends on how you want to organise the data and what you want to do with it on screen. If you are only going to show the last five minutes, then you can use a history chart/1 A 1Khz sample rate means about 300,000 samples (plot points) per channel which is a lot,so you will probably t have to decimate (plot every n points). However. It's worth bearing in mind, that you probably won't have 300,000 pixels in your graph anyway, so plotting them all is only really useful if you are going to allow them to zoom in. There are other ways (JGCodes suggestion is one, queues and a database are another). But that's the easiest and the hassle free way with minimum coding. Ideally you want to stream the data into a nice text file - just as you would see it in an array (I use comma or tab delimited when I can). Then you can load it up in a text editor or spreadsheet and it will make sense and you won't need to write code to interpret it just to read it. You can always add that later if it's taking too long to load in the editor. If the messages are coming in 1,2,3,4,1234 etc then that's not a problem. However, it becomes a little more difficult if they are coming in ad-hock and you will need to find a way of re-organising it before saving so your text file table lines up. Hope you have a big hard-disk Oh. And one final thought. Kill the Windows Indexing service (if you are using windows that is). You don't want to get 4 hours in and suddenly get a "file in use error"

Indeed. (to all of it). But its rather a must now as opposed to, say 5 years ago. Most other high level languages now have full support (even Delphi finally...lol). I haven't been critical about this so far, because NI came out with x64. As a choice of x64 or Unicode, My preference was the former and I appreciate the huge amount of effort that must have been. But I'd really like to at least see something on the roadmap. Are these the VIs you are talking about? These I've tried. They are good for getting things in and out of labview (e.g files or internet) but no good for display on the UI. For that the ASCII needs to be converted to UCS-2 BE and the Unicode needs remain as it is, ( UTF8 doesn't cater for that). And that must only happen if the ini switch is in otherwise it must be straight UTF8. The beauty of UTF8 is that it's transparent for ASCII, therefore inbuilt LV functions work fine. I use a key as a lookup for the display string, which is ok as long as it is an ASCII string. I can live with that The real problem is that once the ini setting is set (or a control is set to Force Unicode after it is set) it cannot be switched back without exiting labview or recreating the control. So on-the fly switching is only viable if, when it is set, ASCII can be converted. Unless you can think of a better way?

Ahhhhh. I see what you are getting at now. The light has flickered on (I have a neon one ) I must admit, I did the usual. Identify the problem and find a quicker way to replicate it (I thought you were banging on about an old "feature" and I knew how to replicate it ). That's why I didn't follow your procedure exactly for the vid (I did the first few times to see what the effect was and thought "Ahhh, that old chestnut"). But having done so I would actually say the class was easier since I didn't even have to have any VI's open So it really is a corner of a corner case Have you raised the Car yet? But it does demonstrate (as you rightly say) a little understood effect.. I've been skirting around it for so long; I'd forgotten it. I didn't understand why it did it (never bothered like with so many nuancies in LV), I only knew it could happen and modified my workflow so it didn't happen to me But in terms of effort defending against it. Well. How often does it happen? I said before, I've never seen it (untrue of course given what I've said before) so is it something to get out nickers in a twist about? A purist would say yes. An accountant would say "how much does it cost"? Is awareness enough (in the same way I'm fidgety about windows indexing and always turn it off?). What is the trade off between detecting that bug and writing lots of defensive code or test cases that may be prone bugs themselves? I think it's the developers call. If it affects both LVOOP and traditional labview then it should be considered a bug or at the very least have a big red banner in the help Still going to use typedefs though

You are probably better off logging to a file since you will have a huge dataset.

I'm not sure I would agree that OOP is still evolving (some say its a mature methodology). But I would agree LVOOP is probably unfinished. The question is as we are already 10 years behind the others, will it be finished before the next fad Since I think that we are due for another radical change in program designing (akin to text vs graphical was or structured vs OOP). It seems unlikely. As for a plug-in way of invoking AEs. Just dynamically load them. If you make the call something like "Move.Drive Controller" or "Drive Controller.Move" (depending on how you like it), strip the "Move and use if for the action and load your "Drive Controller".vi. But for me, compile time safety is a huge plus for using labview.

No it doesn't defeat the object of typedefs. Typedef'd clusters (since you are so hung-up on just clusters ) are typically used to bundle and unbundle controls/indicators so compound/complex controls so we can have nice neat wires to and from VIs . Additionally they can be used to add clarity an easy method to select individual components of the compund control. The benefit as opposed to normal clusters is that a change propagates through the entire application so there is no need to go to every VI and modify a control/indicator just because you change the cluster. I (personally) have never uses typedef'd constants (or ever seen them used the way you are trying to use them) except as a datatype for bundle by name. As I said previously, it is a TypeDef not a Datadef. Well. I'm not sure what you are seeing. Here is a vid of what happens when I do the same. http://www.screencast.com/users/Imp0st3r/folders/Jing/media/6d552790-5293-4b47-85bc-2fcb1402b085 All the names are John (which I think was the point). Sure the bundles change, so now the 0th container is labeled "LastName". But its just a label for the container (could have been z5ww2qa). But because you are imposing ordered meaning on the data you are supplying, I think you are expecting it to read your intentions and choose an appropriate label to match your artificially imposed meaningful data.You will have noticed that when you change the cluster order (again something I don't think most people do - but valid), the order within the cluster changed too (Lastname is now at the top). So what you have done is change into which container the values are stored. they are both still stored. They will all be taken out of the container that you stored them in. Only you are now storing the first name (data definition) in the last name (container). If you are thinking this will not happen with your class....then how about this?l. http://www.screencast.com/users/Imp0st3r/folders/Jing/media/672c5406-a56d-4c7a-a177-ab31a3c0cd15 What problem? I think you are seeing a typedef as more than it really is and you have probably found an edge case which seems to be an issue for your usage/expectation. It is just a control. It even has a control extension. It's no more an equivalent to a class than it is to a VI. The fact you are using a bundle/unbundle is because you are using a compound control (cluster) andt has little to do with typedefs. Making such a control into a typedef just means we don't have to go to every VI front panel and modify it manually when we change the cluster. Yup. And if one doesn't exist, I write one (or at least title a document "Design Specification" ) by interrogating the customer But mainly our projects are entire systems and you need one to prove that the customers requirements have been met by the design. Seat-of-yer-pants programming only works with a lot of experience and a small amount of code. It's nothing to do with in memory or not (I don't think). What you are seeing is the result of changing the order of the components within the cluster. An enum isn't a compound component so there is no order associated. Nope. The source is in SVN. OK you have to have a copy of the VIs on the machine you are working on in the same way that you have to have the class vis present to be able to use them. So I'm not really sure what you are getting at here. A module that might expose a typedef would be an action engine. I have a rather old drive controller, for example, that has an enumerated typedef with Move In, Move Out, Stop, Pause, Home. If I were to revisit it then I would probably go for a polymorphic VI instead purely because it would only expose the controls for that particular function (you don't need a distance parm for Home or Stop for example) rather than just ignoring certain inputs.But its been fine for 3 years and if it "'aint broke, don't fix it" I suppose. But it's not used like that and I cannot think of a situation where you would want to (what would be the benefit?) Its used either as a control, or as a "Type Definition" for a bundle-by-name. It's a bit like laying down a queue reference constant. Sure you can. But why would you? Unless of course you want to impose "Type" or cast it. Maybe I don't. But I do know "by-val" doesn't mean it's "data-flow" any more than using a "class" means "object oriented". Like you said. It's up to the programmer. It's just that the defaults are different. In classic labview, the default is implicit state with single instances. In LVOOP its multiple instance with managed state. Either can be made to do the other. It's just the amount of work to turn one into the other. Well that's how it seems to a heathen like me

Does what it says on the tin in LV x64

I already have my own vis that convert using the windows api calls. I was kind-a hoping they were more than that . I originally looked at it all when I wrote PassaMak, but decided to release it without Unicode support (using the api calls) to maintain cross-platform. Additionally I was put off by the hassles with special ini settings, the pain of handling standard ASCII and a rather woolly dependency on code pages - it seemed a one OR the other choice and not guaranteed to work in all cases. As with most of my stuff, I get to re-visit periodically and recently started to look again with a view to using UTF-8 which has a the capability of identifying ASCII and Unicode chars (regardless of code pages) which should make it fairly bulletproof and boil down to basically inserting bytes (for the ASCII chars) if the ini is set and not if it isn't. Well that's the theory at least, and so far, so good. Although I'm not sure what LV will do with 3 and 4 byte chars and therefore what to do about it. That's the next step when I get time.

Indeed. I think for the most part it is true. Especially for OSs However, I have met on numerous occasions programmers who prefer to just use "int" in the code (as opposed to in32, int64, long, double word et. al - there's so many.) and use a compiler directive when compiling for x64 or x32 or even x16 (therefore converting ALL ints to whatever). Seems particularly prevalent when porting. Like you said. Programmers are lazy

Hell hath no fury like a woman scorned (or ignored ) Yes and no. It depends on what exactly you are talking about. Extending a class by adding methods/properties? Or inheriting from that class and overriding/modifying existing properties and methods. My proposition is that is that my method identical to the latter. I assumed you meant the latter since you were speaking in context with a closed component that would be extended by the user. In that scenario the user only has the inheritance option (there are other differences but nothing significant I don't think). Or maybe I just missed what you are trying to say. But it's interesting you say that I can extend the operations. i would have argued (was expecting) the opposite since in theory, although properties are synonymous to "controls". Operations seem fixed. But I'll leave that one for you to think about how I might respond since I appear to be basically arguing against myself Problem? No. It's much more of a problem building an executable with them. There are many more ways to shoot yourself in the foot with OOP. But for the case when you don't have a top level VI there are a couple of "tricks" from the old boys...... Many moons ago there used to be a "VI Tree.vi". You will see it with many drivers and I think it is still part of the requirement for a LV driver (although haven't checked recently). Is it to show everyone what the VI hierarchy is? Well. Yes. But thats not all. It's also the "replacement" application to ensure all VIs are loaded into memory. However, with the advent of "required" and "optional" terminals, it's effectiveness was somewhat diminished since you can no-longer detect broken VIs without wiring everything up. The other method (which I employ) is to create test harnesses for grouped modules (system tests). You will see many of my profferings on lava come with quite a few examples. This is because they are a subset of my test harnesses so they are no extra effort and help people understand how to use them. Every new module, gets added to the test harnesses and the test harnesses get added to a "run test" vi. That is run after every few changes (take a look at the examples in the SQLite API). Its not a full factorial test harness (that's done later), but it ensures that all the VIs are loaded in memory and is a quick way to detect major bugs introduced as you go along. Very often they end up being a sub-system in the actual application. Labview is well suited to top-down design due to its hierarchical nature. Additionally top-down design is well suited to design by specification decomposition. Drivers, on the other hand lend themselves to bottom-up. However. for top-down, I find that as you get further down the tree, you get more and more functional replication where many functions are similar (but not quite identical) and that is not condusive to re-use and modularisation (within the project). I use a "diamond" approach (probably not an official one, but describes the resulting architecture) which combines top-down AND bottom-up which (i find) exposes "nodes" (the tips of the diamonds) that are ripe for modularisation and provide segmentation (vertically and horizontally) for inter-process comms. Is this because you have only made a relationship between typedefs as clusters being synonymous with a classes' data control only? What about an enumeration as a method? Ahhhh. IC. Here is your example "fixed" Everything is behaving as it should. But you are assuming that the the data you are supplying is linked to the container. It isn't, therefore you are (in fact) supplying it with the wrong data rather than the bundle/unbundle selecting the wrong cluster data, It's no wonder I've never seen it. It's a "type definition" not a "data definition". That's why I use the phrase "automagically" Disagree. There has to be much, much more to justify the complexity switch and the ditching of data-flow. I do know when a change will impact other areas, because my designs are generally modularised and therefore contained within a specific segment rather than passed (transparently) through umpteen objects that may or may not exist at any one point in time. Ermm. Nope. You don't have multiple instances of a cluster. We are in the "data-driven" world here. A cluster is just a way of viewing or segmenting the data. It. the data thats important, not the container or the access method. Yes a class has a cluster as the data member. But thats more to do with realising OOP with labview than anything else. If anything the similarity is between a data member and a local variable that is protected by accessors. Ahh. I'm with you now. Sounds complicated I prefer files That reminds me of the "Programmers Quick Guide To the Languages'" entry for C++ (I've posted it on here before) I'm sure

Ooooh. where are they? Indeed. I think most people (including myself) generally think that unicode support = any language support. Although it's a bit of a leap. If the goal is simply to make multiligual labview interfaces then unicode can be ignored completely in favour of UTF8 which isn't code-page dependent (I've been playing with this recently and wrote my own to detect and convert to the LV unicode so you don't get all the spaces). This would mean the old programs would still function correctly (in theory I think, but still playing).

Here ya go