shoneill

QUOTE (psychomanu @ Apr 3 2009, 04:39 PM) Your preferences are not the sole deciding factor in whether something is good or bad practice. Stacked sequences are bad. Shane.

QUOTE (Aristos Queue @ Apr 3 2009, 01:35 PM) So why not take it off the main structure palette. Put it somewhere obscure so that people will switch due to the "annoyance" factor. Like a dedicated "deprecated" palette or something. Shane.

QUOTE (psychomanu @ Apr 3 2009, 12:12 PM) Just wanted to make sure you're aware of the pros and cons of stacked sequences. I have also thought about this kind of thing in the past, but I generally avoid stacked sequences like the pest, so in the end, I just couldn't bother about it. You could use a FOR-Loop with a case structure inside (Wired to the i terminal) as a stacked sequence replacement. You can then have shift registers. Shane.

If you can wire up things with the error terminal, you shouldn't be using stacked sequence structures. If you MUST use a sequence structure, use a flat one. Shane.

QUOTE (Aristos Queue @ Apr 2 2009, 10:27 PM) Nice of you to tolerate my (essentially tongue-in-cheek) request. :worship: I'll be looking forward to this.... Thanks AQ. Shane.

QUOTE (Aristos Queue @ Apr 1 2009, 02:17 PM) Can you reply again to this message tomorrow with the same content so that we know it isn't an april fool wind-up? This would be cool! Shane.

QUOTE (Vladimir Drzik @ Mar 31 2009, 02:50 PM) Well, why don't you save the control as a normal control instead of a Typedef. Shane.

QUOTE (neBulus @ Mar 25 2009, 08:46 PM) I reckon it's the most efficient way of getting it done. I can be a bit of a grammar nazi at times, but it pays off when writing Resumes. Spelling mistakes in a Resume is like stamping "throw me away" on the front page in big red letters. That and having a proper idea of where your strengths and weaknesses are and applying for jobs accordingly. Simply applying for "any old job" usually doesn't work too well. Lying about your work permit status is just looking for trouble. Shane.

QUOTE (zmarcoz @ Mar 25 2009, 07:23 PM) With 1000 resumes sent you can't have spent much time personalising each one before sending.... I always take time to highlight the parts of my capabilities which fit any given job I wish to apply for. This can take up to half a day until the wording is right. Having said that I never had to send more than, say, 10 resumes before getting a new job. If you're not even getting called for interviews, then there must be something clearly wrong with your resumes. Maybe you should post an example with personal details deleted (name and age and so on). Do you include a personal cover-letter? That can be really important. Shane.

QUOTE (Yair @ Mar 20 2009, 11:19 AM) Thanks. I wasn't so far off so.... Another small part of the puzzle filled in. That's the difference between a "proper" software developer and a wannabee like me. Shane.

QUOTE (Aristos Queue @ Mar 20 2009, 04:00 AM) Assuming the child itself doesn't call one of the removed parent VIs I presume. Shane.

QUOTE (neBulus @ Mar 19 2009, 09:37 PM) Thread is getting a little off-topic.... Dynamic dispatching (to the best of my knowledge) is determined at compile-time. An object with a parent class "polygon" will always cast up to "polygon" when used. It will have the methods from "polygon" available when used. It cannot be instantiated with something other than "polygon" as parent. It reminds me of a passage from "kung-Fu Panda" (funny place to get an OOP quote I'll admit) QUOTE Shifu: But there are things we *can* control: I can control when the fruit will fall, I can control where to plant the seed: that is no illusion, Master! Oogway: Ah, yes. But no matter what you do, that seed will grow to be a peach tree. You may wish for an apple or an orange, but you will get a peach. Although dynamic dispatching is determined at compile-time, the usage of it appears to allow run-time associations. Instead, it allows run-time determination of which compile-time relations are to be called (if that makes sense). The dynamic dispatching "table" so to speak is determined at compile-time unless I've misunderstood something. So it may be "handled" at run-time, but it can never exceed the scope laid down at compile-time (unless there's a bug somewhere of course). The fact that we can use a plug-in architecture like this (A great benefit of LVOOP IMO) is based on the fact that the inheritance (and the associated dynamic dispatching) for a specific class is pre-determined. If you take the same class, remove the inheritance and then try to load it as a plug-in, it will fail (right?). Given that the methods and name of the parents match, we have an addition to the dynamic dispatch table (I don't even know if there is such a thing, but I think that was to help visualise what's going on) is simply expanded. The content of the expanded part is again pre-determined from our compile-time associations. The SIZE of the dynamic dispatch table however can be changed at run-time. An interesting question is: what happens if I use a class which inherits from a different version of my parent class? What if there's a method VI more or less in the new Parent class, will the plug-in architecture still work? Is there ANY flexibility in the run-time dynamic dispatch (or inheritance) linking? I don't know if my post makes any sense whatsoever to anybody except myself..... Please note that I may have all this back-to-front and inside-out and maybe even upside-down..... Shane

I did actually learn (more accurately, I was taught) OOP in C++, but only many years later did the penny drop on the one issue I had serious trouble understanding. Inheritance. As soon as I realised that Inheritance was something dealt with at compile-time, it all became clear. This happened when dabbling with LVOOP. All those years I could never get my head around OOP simply because I never noticed (or my books never actually said) that Inheritance was basically static when compiling. I was never able to understand how run-time inheritance changes could possible be handled sanely and this really put me off OOP because I had the feeling I just wasn't "getting it". LVOOP is for me the perfect somution for "same same but different" type of code. I realise that won't make sense until you're actually understood LVOOP, but for me that pretty much sums it up. Common framework, uncommon internals. Shane.

If you run a program from a project is runs in a separate LabVIEW instance. This means that you will not have naming conflicts with VIs from outside the Project. For example, if you have a VI called X.vi in your project (A) which is different from another X.vi in a different VI (B) which is currently loaded in LabVIEW the differences are as follows: Without a Project: You load the new VI (A) and instead of loading the correct X.vi, it links to the existing X.vi in memory (B). If youhappen to save the program now, you have a cross-reference. With a Project: You load the new VI (A) and the correct X.vi is loaded into a separate application space to the other (B) X.vi. No cross-reference. This fact alone is enough for me to use the project for basically everything I do in LabVIEW (Except Q&D trials). Shane.

QUOTE (zmarcoz @ Mar 17 2009, 04:48 PM) Just remember, like UI vs GUI, a lot of the things you might think you don't know might just be down to semantics. If a job you're applying for requires something you've never heard of, then you're most likely not the right person for the job. In the worst case, ask them what exactly they mean by term X or Y. I've done that before and have found out I uderstood the principle behind something even though the name they were calling it was unknown to me. That's what I get for being self-taught. Shane.

QUOTE (Cat @ Mar 17 2009, 02:05 PM) ^^^^^ ¦ ¦ ¦ ¦ ¦ I agree with this! Shane. Ps Except maybe for the topic of "pointers".....

QUOTE (Cat @ Mar 17 2009, 12:36 PM) Yup, keeping things in the old Irish spirit..... TBH, I think Patrick's day is celebrated much more abroad than in Ireland, even in years where the economy isn't self-destructing.... Shane. PS Oops, I'm not wearing anything green.....

QUOTE (Cat @ Mar 17 2009, 11:55 AM) Happy St. Patrick's day. Funny thing, being Irish, is that neither myself or any of my friends or family bother wishing each other happy St. Patrick's day. Seems to have a life of its own..... Either way, enjoy your beers (or Stout to be more accurate re: Guinness). I prefer Murphy's myself though..... Shane.

QUOTE (zmarcoz @ Mar 17 2009, 04:49 AM) I can't believe somebody can be used to programming LabVIEW and not know what a UI is. But perhaps English isn't your first language and it's called differently where you are so.... to find out what UI is, search for "UI" on wikipedia. To know more about noise reduction techniques, you kind of have to first know about the signals upon which the techniques should be used. Noise reduction in optical systems is different to digital systems is different to analog systems..... Shane.

QUOTE (zmarcoz @ Mar 16 2009, 04:42 AM) Some basic algorithm knowledge is always a plus, as is some knowledge of software engineering principles. Other than that, a solid knowledge of what makes a good UI and what makes a bad UI is pretty useful.... Shane.

QUOTE (Yair @ Mar 14 2009, 06:12 PM) Followed by: QUOTE (Yair @ Mar 14 2009, 06:12 PM) If you guys don't like the sequence structure because of its size, all you need to do is use the diagram disable structure which has a much thinner border and which I believe can have a single frame. seems self-contradictory but I think I see what you mean. I really think using the diagram disable structure instead of a sequence structure is perhaps not the most transparent solution. I suppose we could always wire up single sequence structures with some random wire ourselves to mimig what we've been talking about here....... The only difference would be the wire which seems too small a difference to warrant NI doing any real work on it. Funnily, I never actually thought of doing it like this before...... Shane.

QUOTE (crelf @ Mar 12 2009, 09:25 PM) Chris, that's almost exactly what I was thinking but I wasn't able to come up with a decent description and I'm too lazy to do a mock-up in a drawing program. I like the idea of a "node-specific" container indeed...... Shane.

QUOTE (Dan DeFriese @ Mar 10 2009, 03:17 AM) I could see two advantages here..... 1) A null wire would most likely take up less screen space. Whenever I DO need a sequence structure (I needed one yesterday for instance) I find myself wishing for a 30" display so that all that screen real-estate I just lost wouldn't annoy me so much. 2) A null wire could link only those functions which are required to run sequentially while leaving all around them to run in parallel. Sometimes there are only a couple of things which are supposed to be serialised by a sequence structure but you kind of need to pack everything in so that the code is in some way readable. By interspersing normal code with some sequential code (linked by null wire) I think we have more finely-grained control over exactly which functions are being forced into serial execution. I also think a null wire should NOT connect to a connector pane, but should connect to a container which contains the VI in question. Sequences of these containers (Use the current Sequence structure for example) can then be linked by null wire, forcing further sequential execution. This would then give a natural connection to existing sequential structures in LV. Like a modular flat sequence structure where the individual frames are linked by wire instead of being glued together..... Will this introduce complexity into the LV IDE? Yes. Will it be complicated at the beginning? Yes. Can the same thing be achieved with sequence structures as they currently exist? Yes. Will most people use it? No. I don't know if it's worth the time required to implement it, but I think the idea in itself has merit. Shane.

QUOTE (335x @ Mar 5 2009, 08:55 AM) Well, you're referring to LAbVIEW as G, which is pretty good for a starter :thumbup: The picture ring has a terminal on the block diagram. Connect an integer value to this and it will display the image loaded at that index. No property nodes required. As for timing you need to have the portion of the code writing to the terminal as part of the function so that whenever a specific part of the function is reached, the index is updated accordingly. If you need to update from more than one location (depending on your code) then you'll need to use local variables. Shane.

QUOTE (crelf @ Mar 3 2009, 07:47 PM) Cool, hope it works out. I remember AQ mentioning something about LVOOP implementation where every operation in a program is done http://forums.lavag.org/A-weird-way-to-improve-your-object-oriented-programming-skils-t11413.html' target="_blank">WITHIN the object, i.e. not using ANY standard functions like "Add" or "search 1D Array" and so on. It really made me think about how to keep EVERYTHING inside the class boundaries. I think his example was really extreme, but it certainly helped me "see" proper encapsulation solutions where it otherwise wouldn't have occurred to me. Shane.