shoneill

This is the best thing I've heard about LV in quite a while. Great stuff.

I'm having similar ponderings regarding a toolkit I'm (was) working on. I wanted to offer up basic functionality in one package and then enable building up on this for extensions to the framework. I also wanted to keep some dirty secrets for myself, so it pretty much mirrors the topic being discussed here. IF we stick to the absolute naming, can we introduce new code levels (I'm using many classes) by allowing the declared friend also declare its own friends and thus expand the code base? I'm pretty sure I'm not expressing myself correctly... In other words, how do we make libraries portable yet extendable. A further issue is how to provide some pseudo-private functions (by abusing the friend mentality)? Shane

So stability will improve in 2011 right? Any chances of getting improvements in the 2010 SP?

I already find 2009 to be less than it should stability-wise. This news about 2010 makes me wary. If I may plug an idea of mine on the dark side.... Shane

So the bottom line is that it doesn't work, it shouldn't work and it won't work.... OK. Just needed to hear that so that I can accept the "constructor" way of life. Thanks Shane PS Just to clarify. I wasn't looking for multiple default valeus for a single class but a different default value for each class. I see how multiple constants for a single class with different default values would be horrible, but that's not what I was looking for. I only want each child class to have its own different default values. This would have worked with the special tagged VI AQ mentioned....

I remember reading about this before, but the big black border (BBB) is kinda ugly..... Can I save this in some form to allow dropping it onto the BD via a Palette or something? Shane

Well, yeah I know (it's what I'm doing at the moment) that but it would be so nice to be able to just drop a constant on the BD and have it run from there without requiring a constructor.... At the moment I have a function to create the object with the appropriate values being set within. Shane

I have a LVOOP project where I have a parent class with all of the data required and many child classes which have custom accessory to this data but no data of their own (with child-relevant parsing built-in). When I drop a child constant, since I have no actual data within the child class, I cannot have the class default to different data than the parent and the parent always has default data. My question is how I can create a child object constant with parent data corresponding to something else than the default values? Shane

Your answer reflects pretty well where I am in my thinking at the moment. I had the feeling I was slowing myself down by taking the "cohesion", "coupling" and "encapsulation" ideas WAY too seriously and trying to do everything without coupling any two classes..... This obviously gets very hard very quick. Interdependency is OK as long as it serves a common purpose I suppose (coherent). So coupling is OK as long as the coupling takes place coherently? Shane

Yeah, that answers it for the example I listed. I'm always looking for ways to really encapsulate and abstract as much as possible and when I've got 95% of it done, hard-wiring to achieve something similar to what you were describing it seems like I'm compromising all which went before. Maybe I'm hung up a bit too much on abstracting everything. If everything has been abstracted, where do we go from there? I always tend to try to create re-usable code which is reusable without code changes whereas I'd probably most often be better off assuming that minor changes will be neccessary for minor updates. There are exceptions where a truly generic class can be created, but these are rare I think. Thanks Shane

I'm going to butt in here for a few questions which are occupying me at the moment. I'm not terribly qualified to actually engage in this discussion but if someone could answer a question or two for me I'd be very grateful. I have made some attempts into encapsulating different kinds of functionality into some of my code in the past with varying levels of success. While I'm aware of coupling and cohesion issues as well as basic data abstraction I'm not very up-to-speed with the different design patterns out there. I always run into the situation where I can do nearly everything from within a class (including display and user input by using sub-panels) but at some stage there comes a point where you need to get at the actual data. Sharing of information between different steps of a LVOOP state machine would be one example..... How does one go about solving this problem (Or am I wrong in even identifying this aspect of things as the problem I am having). When looking at the examples Paul has in his PDF linked above I am left wondering (in the case of the "Save" button push for example) where does the object gain access to the data it needs to save..... The object itself does not contain the data right? So where does the data-to-object boundary take place and how does one go about implementing it without eroding the encapsulation of the classes too much. The only way I can think of is hard-wiring a datatype to the entire family of obejcts (QUEUE or whatever) and retaining access to all the data internally but this seems like it's violating the encapsulation from the inside (if that makes any sense). Sorry if my ramblings don't make much sense, but this is simply an area where can see the benefits of LVOOP, but have problems actually envisaging the to-and-fro of data between the "Program" and "Objects". Shane. Shane.

I agree also. I've only wandered into XControl territory a few times but I didn't like the way indicators and controls were duplicated in order to allow for both cases. I like the idea of using a single control and "manually" updating its appearance and behaviour to match an indicator. Seems more logical to me.

LOL. Recursive SIngletons....

A mix of 100% copyright and 0% patents is not a mix. Trade secrets in software? Like algorithms? Sure you can protect HOW to get an end result but not the end result itself (falling back to copyright). If you don't get other protection for an algorithm (like CSS) then anyone can implement a version as long as they don't copy your code. And trade secrets are, by their very nature, only valid when nobody knows about them. If a second company implements something which was previously a trade secret, then it's not a secret any more is it... Seriously, does anyone thing there's a relevant protection for software beyond copyright? Seriously. Shane.

I don't like the term "IP" in conjunction with software. It's copyright (which is enough as the GNU Licence has proven). There are no patents involved (outside the US). IP is a mix of trademarks, copyright and patents. Only copyright applies to software. Calling it "IP" implies there's more to it than that. Just my pet peeve. Shane.

Maybe a (meta)quote from the Big Lebowski might help:: "They treat objects like women, man..."

Congrats, I see your new sub-VI has error handling implemented (Diaper). . Shane.

User Events, Queues, Notifiers. These will all enable you to do what you want. Simply define the method you require and pass a valid reference to the sub-vi as an input. You can then put the data in the Event / Quque / Notifier int he sub-VI and it will be available to be read in your calling VI. It's not that difficult. Search for some examples. Shane.

I have seen things like this before. Especially conflicts can be a real pain in the rear to fix. I often have conflicts (due to messing around in my file hierarchy) which are seemingly cyclical in nature and the IDE gives few clues as to where to start. I had another case today where parallel loops were (seemingly) crashing my program. Hard crashing, LV just disappeared and so on. Occasionally I would get a "not enough memory" error. I removed the parallelisation of the for loops and it started working again. I really really really want NI to focus more on stability. Shane

Just wanted to make sure you were aware of the queuing nature of Events and also the extra 16 Bytes baggage each and every event comes with. I'm also of the opinion that firing a non-registered Event (while not quite being a No-op - it needs to check if it has been registered) whould create minimal overhead and definitely not cause an increase in memory usage. I personally use Events a lot and find them to be cool, but could be much improved. Performance versus Queues is one thing which kind of annoys me. I've yet to hear a good reason WHY receiving an event is inherently slower than reading from a Queue for the same data size. Add to this various timing issues and I'd make a suggestion on the idea exchange but I'm pretty sure it'd get no support..... Shane.

I think your problem is almost expected behaviour. You say up to 500 instances at 50 times a second are being fired. This makes 25000 Events per second. Each user event is a minimum of 17 Bytes (See picture attached) and all events are stored in a queue. This means that if you do not PROCESS the events, then they are being stored in memory at a rate of 500 instances x 50 Hertz x 17 Bytes = 425kB per second. ALL of these events are then available to an event handler (which can lead to a huge backlog of events if not handled quickly enough). It doesn't explain why you would be seeing 3MB/s increases. I'm also not sure if a User event which has not been registered should allocate memory at all either. I would have thought it would not allocate memory since with nothing to process it, it is falling on deaf ears so to speak. Can anyone clear up on whether a non-registered Event should be stored in memory? Shane

shoneill (LAVA) = shoneill (NI) = Intaris (NI)

I used a stacked sequence recently and the next day I got kidney stones! Coincidence? Almost certainly. Do you want kidney stones? Didn't think so. I rest my case. Flawless logic. Shane PS This REALLY happened and kidney stones are one of the very few things WORSE than stacked sequence structures.....