shoneill

More like the Application property "All VIs in Memory", then loop over "Open VI Reference" and get their execution state.... Abort those you don't want to leave running and don't forget to close your references properly....

I would say that you need a base List class for each different datatype you want to support. If you do it via inheritance then your String class still has a method to insert Objects which can violate the "String" idea and might lead to problems elsewhere. It's just not a clean implementation. This (in current LVOOP) requires more or less a COPY of the base class for String, DBL, LVOOP Object and so on. If you want strict typing to a specific LVOOP class, then you need a base class for that otherwise your back door "LVObject) will remain open always. Either that or simply input EVERYTHING as an object. Write a set of simple wrapper classes (Yeah, it's a pain) and simply use the LVOOP insert everywhere. You can define the Methods Insert (String) if you like, but I would have them use the LVOOP method in the background. Templates create (if I'm not mistaken) new entities from a generic data type which shares no inheritance relationship to it's cousins. This is similar to simply replacing the datatype of the base class in your example. Instead of having some "void" datatype, simply create a template class with String and replace as required. Would it be nice if this could be automated / sped up with LV, sure. That's maybe a good suggestion for the Idea Exchange. For me Templates are (regarding the end result) similar to my first point above (Different base classes for each datatype). Sometimes we get so LVOOPy in our heads we try to do everyhting WITHIN the Hierarchy. Sometimes the answer is to copy the hierarchy and be done with it. Create the new classes as required instead of trying to cover all bases from the beginning. And yeah, I'm always traing to over-inherit such functionality myself. Just my 2c. Shane.

And using a class instead of input fields doesn't work because.......

Your proposed enforcement is an illusion. Due to the code not having any interface representation it may never be executed. Not being able to compile a class just because of a missing VI prototype which is (quite possibly) never called seems seriously flawed to me. Your proposal sounds like my wife. She often not only wants me to do something (lets think of this as the interface) but she also wants me do do it her way (your enforcement) even though this has no bearing on the start or end status of the operation. I've never had the spontaneous idea that this was a good thing. When finished, if she asks me if I did it "her way" then of course the temptation is to say "Of course dear" event hough you know it's not true. If a class is in the position to do WHAT you want, why is it important that it does it your way?

I think here we may have some significant common ground. Regarding overloading: From a user point of view: If you already have a specific object wired up in your program (with static "Init" function following the object constant) and you want up change the object type then you also have to go and search for the "Init" function for the new class, it won't update automatically because it's got a different name. I don't actually care what name it has, I'd just like such operations to automatically find the related VI for my new class. I would inagine some secondary identifier for class functions aside from the filename, like "Ability" or something which would allow the IDE (And only the IDE) to perform such swap-out operations on otherwise unrelated class functions. That's all, it's not a major headache, it's not a showstopper it's just behaviour I run into all the time where I think it could be solved so much easier. Shane. PS I think there's some common ground between this idea and Jack's also. Adding "Ability" tags for static VIs and telling child classes they MUST IMPLEMENT those abilities reaches the same target without having to have functions with the same name and different connector panes, no?

I don't see a FPGA reference being passed between the nodes being used. The image os of the host VI and not the FPGA VI, right? OR did the snippet simply create property nodes for your terminals.... That's kind of confusing me a little..... How does your host VI look? Shane

If I re-read your posts a few times I get the feeling you want to limit the types of messages a given actor can send and receive within the AF, is this correct? I've posted the same question and I've been called mad for wanting something like that but for me it's the main reason why I do not use the AF. I want to know at edit time if I'm trying to send an actor an incompatible message or not and the current AF does not allow for this because the message queues are too loosely defined. In my experience you need to use a staggered inheritance to achieve what you want with the interface being re-defined at each inheritance level. This means that all Boolean actory implement the boolean interface which accepts boolean messages. If you try to send one of these to a Numeric actor, you get a broken wire. Please see HERE and subsequently HERE for my take on this. Shane

This will also only work if the methods thus defined are private scope. Otherwise LV cannot concievably know which versiont o execute in a real VI due to the inheritance probability for any given object control or indicator. This ambiguity is normally handled by DD but since you explicitly don't want that, the handling must be performed by limiting the usage of the VI to the class which defines it. I also don't quite understand the sentence: "Also tried using classes, but then the same problem exists, just with a new abstraction layer added!" Can you elaborate on this a little? Shane.

PPS One thing I WOULD like is the ability to have static class methods with the same name but different connector panes. That would be übercool.

I have an immediate aversion to this idea but I can't quite put my finger on the reason "Why". I think the combination of non-DD and the "Must implement" will simply lead to massive code smell where programmers just implement the required VIs as empty husks and do the rest of the work in the rest of the child class. Why not have custom data interfaces with a dynamically overwritten "Do" command. This enables custom front-loading while avoiding the code smell of the "Must override" function essentially being useless becuase the code does not need to be called at all. Shane. PS Or emberace OOP and just make your variable input an object isntead of a primitive. Remember what AQ says : Everything should be an object. Of course then the task of "showing" belongs in this class and not your notifier class. Always tell an object what to do instead of asking it for details and doing it yourself.

Absolutely nothing about OOP requires a by reference design. Even if 99.99% of OOP Implementations DO use references, it does not change the matter that the very nature of OOP does not demand either by value or by reference idioms. Shane.

Ok, now I get your "inline" comment. No problems. The data sent between the main loop and the parallel loop is negligible. It's basically a simple status set and a subsequent status read (which I will do via a simply Queue read and write which shoukd be fast enough). I want to tell the parallel process to start and then in each loop of my main process check the status accordingly until it's finished. The parameters required for the parallel process can thus be completely separated from the main loop reducing complexity I think. I'm trying to go a minimal "component" route. Nothing's implemented yet, I'm just in the thought process. Shane.

You can't inline a DD vi. Alone the overhead for calling a DD Vi is prohibitively expensive in our system. We're pushing a RT system to its limits. The actual code WITHIN the DD Vi is quite fast but we can't afford to have the DD overhead each cycle, hence the handoff of parallel-process handlers. The parallel processes (Different objects) would receive and respond to the exact same commands fromt he main loop, would use different criteris to evaluate the time to move to the next stage (for example). Therefore they should be transparently hot-swappable . If the actions were atomic, it would be no problem. Shane. Shane.

Paul, that's pretty close to what I'm looking at but my question is about the details of replacement. I don't want the REceiver to change while the sender is waiting for a command to finish because this leads to some swkward situations. I think I simply need to initially allow both to run in parallel and have some kind of "Get Receiver" at the start of any set of commands which must be executed on the SAME receiver and only when a receiver has no open listeners, can it be closed after receiving the "close" command. That way and pending commands will be finished before any real handoff takes palce. I essentially don't want the sender to know what type of receiver it's communicating with. I don't want it to have to know, I want plug-in receivers. Shaen.

I'm considering a change to some of our code running on a RT and have a question. I'm thinking of generating LVOOP-based "services" on the RT whose DD VIs are called in parallel to the main processing loop and communicate via queues or some other as yet undefined asynchronous mode. The reason for this is that the individual DD calls are WAY too slow for us to be calling in every iteration of our main loop. So assuming I would have this up and running, I would of course like to investigate the option of changing the object for a given service "on the fly". How does one go about this? I would assume that the new object instantiates itself in parallel and then "takes over" the processing of the service requests. Of course the current state of the object to be replaced needs to be considered but my question is if there is an established method for doing this. Does anyone have experience of such a process handover, or even know what this is typically called? Shane.

Been there, done that. I almost totally wrecked a LVOOP project by trying to add then to lvlibs. A single mistake (I don't actually know WHAT the mistake was) led to all mixed-up relationships and a profusely cursing programmer. I'm wary of lvlibs since. Shane

Can you post some code so that we can see HOW you're doing it? Shane.

I'm from Europe (And have been to eastern europe) and I would have to say that I've never seen this formatting before. Can NI output this with standard formatters? Shane

%H:%M:%S %d.%m.%Y

@cowen, this I didn't know. I've certainly never passed a clone it's own reference.... Seems really counter-intuitive.

+1 for Bug.

I had the problem with an XControl which I was peppering with events to show that XControl value updates often lag behind the calling VI. Doing this I saw that when queuing up many events fast enough, the order became mixed up. I DO remember making a post about this on the NI site but for the life of me I can no longer find it. I have found a link of mine which points to nirvana, so maybe my post was removed for some reason... Here's a post from someone else having the same problem essentially. Shane. How do I edit my posts? The link I wanted to place int eh last post is not really related. Please ignore me while I go insane. Thank you. Shane.

In rare cases the event queue can get muddled if the events are sent more quickly than the timestamp resolution can take care of. This leads to the events possibly being received IN THE WRO_NG ORDER. This is within the same event queue, and can be provoked even with the same event. It has been reported and apparently the timestamp will include a more robust mechanism in future to avoid this.... In this regard, the queue vs events comparison gets a bit weird as the order in a Queue CANNOT be muddled (AFAIK). Shane. Ps I'm still a big event fan though.

Erm, Jack this is not technically correct. Once an event fires, the naked event refnum IS exposed as part of the data within the event structure allowing foolish of malevolent programs to destroy the user event refnum. I have an idea on the labview Idea exchange to remedy this but it has almost zero traction. Shane.

I don't know why people are hacking around on the poor old unsigned integers. They're a positive lot and never have anything ngative to say about anyone.