ShaunR

it never returned when I did that. this works though. Looks like you need the comparison. for (i=1; i < sizeOfDim(x,0);i++)

Nope, 0-2999. I've never been good with FNs

I32 and y=5

It's been a long time since I used a FN., but I tried replicating your image (in 2009) and sizeofDim(x,1) evaluates to "0". My output array is identical to the input.

Quite right. I stand chastised Pravin. Most fonts are fixed character widths. So if you can find the start and you know the width, you can "cut" each char out and analyse it in isolation.

Microsoft have quite a nice definition of the pub/subs (including observer). the main differences seems to be how the clients obtain their updates and methods of registration. I'm more familiar with the content and topic (list) based since that's basically what "Dispatcher" and RSS are. But I've only used them in context with networking so events weren't applicable. I could see a use for observer invocation in something like LV web-services where you basically want to poll updates of remote devices. But it can be a bit prone to server over-loading if there are many observers.

In LV2010 there is a checkbox on in the properties so you don't have to physically place the code in the diagram. That why I said there is no longer a code boundary (as if you had placed the code in the diagram) however it is still represented as a sub-vi.

Well. I wouldn't be complaining about 7 us to calculate a formula node. Sure it can. It has nothing to do with priorities. As I understand it, when a VI is set to subroutine it means it gets executed sequentiality within the VI so there is no chance that a task/thread switch can occur at the call boundary. As for in-line - in theory the code boundary shouldn't exist, but you can select both subroutine and in-line, so I'm not quite sure exactly what happens. Like I said. I haven't really played with in-line but the VI has to be re-entrant whereas for subroutine it doesn't have to be. Well. 7 us for 20k elements isn't bad. That's 0.35ns per element Any faster and it would have calculated it before you ran the VI

Maybe he already has and is spamming DVD's

What about a "Ghost Busters" machine (temp, pressure, humidity, detect sudden changes etc)

I think your pub/sub definition is really a broadcast definition (like UDP Multicast). I think the observer pattern is just a particular flavour of pub/sub as is "content-based" and "topic based". But I've only ever heard the term in context to events. In other areas I think it's called "List-based" pub/sub.

Making the VI a "subroutine" is the fastest call method (i haven't played with the in-line feature very much but inline+subroutine should be the fastest). What sort of execution times are you seeing? Even a normal call is only 10's of usecs.

I think there are a couple of network Publisher/Subscriber examples kicking around the CR. I'm not sure if they qualify for an "Observer" pattern since some people seem to use both terms interchangeably whilst others use it specifically for events. I think also the "Top-Level Baseline" might qualify too.

Ahhh. IC. Don't bother with PassaMak then 'cos it's mainly UI focused. You have to find the parent that has the attribute you want to cover as many types as possible. Unfortunately, you still have to cast, but you can reduce the cases required.

Deleted-Irrelevant post

If you search for "Constant" on the class name you won't need a case for each type as they all have labels.

Well. The easiest way (If using windows) is probably to load an active X or .net browser into a labview container and when a DocumentComplete event occurs; scrape the page for the info you want.

I did say "similar" . The point I was making is that I prefer to simplify and modularise. The ideal result (for me) is a single VI with a multitude of uses but a simple (2 or 3 parameter) interface rather than a number of VI's, specifically tasked towards specific functions. A ploy is a half-way house to that goal. I've already commented on the singleton (anti?) pattern; many moons ago in an earlier post. They are just irrelevant for classic labview and required to get round a problem of your own making (not specifically you, POOPers in general) There is no auxiliary, or basic. there is just API. My definition of that is that it's a collection of functions to facilitate the execution of a task(s) based around a common theme. Perhaps yours is more strict. But I prefer not to restrict myself with semantics Indeed you can just implement as I do, but for classes that would seem, well, a hack, since you should really be creating an "Encryption" object and passing that as an argument to be used by your read/write VI's. Well. I think we've come to the end of this little exercise and I thank you for your participation in the absence of the OP. People can draw from it what they will, but I think it was a fair example given that it was very suited to both approaches without prejudice. so. Only one other thing to say: . Shopping.Create;Shopping. Alcohol := 10 /* litres */Shopping.Food:=20 /* kg */Merry.Create (Shopping);Merry. Happiness = Shopping.Food * Shopping. Alcoholxmas.Create (Merry);

Quick drop? What's that?

I think going down that route there actually wouldn't be much benefit over using the in-built prototypes from the users point of view. He has a load of VI's in his palette which some of which are interface dependent, some aren't. I think I would want a bit more than just amalgamating the read,write and close VIs for the different interfaces considering the amount of code I have to write. Perhaps it's a personal preference. But I see it as more modular. I've done similar things with queues and notifiers so that I don't have wires all over the diagram and can safely call it from anywhere without much thought. I strive very hard for this type of "node" and it serves me well. Indeed. there isn't an example, but I only really released the library because it's used by other applications in the CR. The encryption is in the API. But I never found a "native" labview compression algorithm and didn't want dependencies on dlls (I'm still looking as I'd like that feature and the stubs are in there). I'm not expecting you to write any more code since I think there is enough to discuss the differences. But I've moded the examples to show you how it works with my implementation. I didn't include CRC as I don't think there would be much mileage as it's unlikely that new CRC algorithms are required and it's not really relevant to all the protocols. But it is a useful utility. The CRC is used in a similar way as the Pack/Unpack instances as a separate entity. As you can see. It's up to the user to use them rather than embedding support at the protocol level. I did toy with the idea of making this transparent too. But that would have severely complicated the ability to turn it on and off on-the-fly. This way, the user decides if he wants to support encryption and only needs to switch by supplying a password or not. However, classes tend to make you think of embedding to conform to the class hierarchy, so making it a stand-alone module isn't the first thought, (although ultimately preferable I think). That's why I asked the question. I cannot immediately see an intuitive way to combine it into your architecture without a lot of work.

It does have something to do with LVOOP since the ease of use is basically derived from overriding a base class. Rather than the user having one VI (or class) that he/she is choosing VIs from, They now have to pick some from the base class and some from the other classes. This doesn't sit well for me as it (in my mind) it breaks encapsulation. What would you suggest to mitigate that? Lets look at it a slightly different way in that: what would happen if I too wanted to make different inputs as you want to do?. I would have to split out the "Listener" and "Open" cases into single VIs (one for each interface) and wrap them in a polymorphic VI. The advantage here for me is that the users choice of interface is decided by what type of control and where it is wired. I'm no worse off than classes but I have more VIs to maintain and test However, that causes me an additional problem in that I can no longer distil all the functionality into one "Transport.VI" that the user simply chooses a function from a menu. I need to split out read, write, close open and listener into separate VIs since you cannot nest polymorphs (read, write etc are separate anyway, but the user doesn't see that). I am, basically, requiring the user to do do the same as you, They have to manipulate a number of VI's instead of just one. OK, I could group them in a Virtual folder but as I add the CRC and packinging VI's I'm getting further from a one-stop shop for comms. So in this case, I have sacrificed the encapsulation derived from my top level polymorph for the ability to type the inputs. Although my Virtual folder is now looking remarkably like your base class. How would you start to add the CRC and packing VIs? They don't fit with the base class template so would you add a new class for each?

That's an interesting comment, since it is usually proposed as one of the greatest advantages to using classes. In this case, however, I agree. There is not much point because both implementations are complicated to the same degree. The goal of this exercise is to look at functionally identical implementations and discuss the differences. You have gone a long way towards that so that we can. (and it is appreciated). Indeed. The difference is adding or modifying cases or VIs. The latter, I would wager, is the reason for Daklus excessive load times.But you also left out that new VIs also require new test harnesses (or modification of an existing one depending how pedantic you are about "white-box" testing) to exercise all the inputs and outputs and that can be quite an additional overhead. The cases only require additions to the input parameters of the same harness so can be scripted (not LV scripted, good ol' fashioned text scripted). The only real difference is how we realise the tasks. You switch by overriding and invoking a VI,. I switch by cases. You're right. I'll have to lay off the mulled wine In this case it is the same. It won't always be, but we have agreed that (for this) it is irrelevant. If we expand further by saying we also want to log opening/closing and listener info. I think you would probably decide to add the definitions to the virtual class for "Open" and "Listener" and would make the implementations completely synonymous (unless of course you want to modify all the open and listener VIs for every class). The difficulty here though is that you (or rather the user) still needs to tell it which one to invoke by laying down a class constant. I did something similar in the beginning using refnums (i.e using type to choose the interface), but rejected it in favour of a ring control as I perceive it easier for he user.

Well. thats the crux of the differences in argument position, isn't it. I never try to make all singing, all dancing APIs that will be all things to all men with a view to abstracting all current and future interfaces. I don't want to add more protocols, nor will I ever at this level. I just want to make it easier to use those ones. I've looked at how I, and others use them and simplified it to a couple of parameters,unified the inputs, and implemented a client server relationships for those that don't have it (UDP). If other interfaces are required, then they will build on this API at the next higher level (similar to what you have done with the UDP). TCP, UDP, Bluetooth and IR have been modularised and simplified. The only burden I'm placing on the user is to use a properly formatted string (which doesn't have a huge amount of restrictions) This is no different from VISA for example.I would in fact say that the the class implementation burdens the user more since now he/she has to cope with multiple VI's depending on what which interfaces he wants to use and supply different parameters depending on the use. This will get worse if you do require the API to support more interfaces that take different parameters and allthough it's easy for you to keep adding classes, the user is getting more and more interface to contend with. I have attempted to simplify and the classes are putting it back in again. If you mean replacing a variant primitive with a class acting like a variant. then possibly. I don't know what the intention was, but if it involves me writing more code; then I'm not a fan. It's not quite ready because it needs a client/server emulation the same as the UDP. But that's not the point. I could also add (in 10 mins) serial, but it would basically be the same as yours (without classes) requiring the user to wire up additional controls. The only difference would be I'd be adding cases instead of VIs. But I disagree that It's a problem with the program. The program is able to write and read data which is it's only purpose. If the API can get the required configuration options from a single input. then the program will work. I experimented with mine and I could do things like make the string a comma-delimited config or pass it a file name to load the settings, but that doesn't translate well to the other interfaces, is very unintuitive and well. Just plain crap. Anything else needsd more controls and requires the user to treat serial differently so that doesn't fit with the remit. But user/component boundaries aside. The really interesting thing for me is that. If (hypothetical because it won't happen) I were to add more interfaces that did fit with my remit for single parameter config. I would only be editing 4 VI's. If there were 100 interfaces; I only need to take care of 4 VI's. My maintenance-base doesn't change. However for classes each new interface requires the addition of 4-5 VIs no matter how similar the interface is. So in this hypothetical case of 100 interfaces, I only have make 400 changes as opposed to oooh... thousands for the addition of your logging example. Classes in LV are replication which isn't conducive to maintenance.