ShaunR

This is desirable in my apps too. I created a queue wrapper (umpteen years ago) that ensures there is always exactly one of any queue and is created when any queue function is called thereby removing the Init, Do Something. Destroy overhead and memory runaway from creating refs. Destroying the queue merely has the effect of clearing the queue which is reconstituted on the next call, Queue.vi

I gave you closure; move on. The List is here by the way.

Available in the LabVIEW Real-Time module: No (Hover your mouse of the name property)

Attached is a tentative alpha for 2.0.0. As much as I hate the alpha and beta philosophy, I only have one test device so I am not comfortable in fully releasing as it may be tuned to that one device. I usually pull products I cannot adequately test; the choice was an alpha release or remove it completely and put it back in my "cool stuff for me" toolbox. But I said I would do something so lets see if we can get this usable for most people with a view to a release proper. Oh. And I changed the licence to a much more amenable BSD3 .OPP 2.0.0-ALPHA.zip Of course, if you want to send me lots and lots of bluetooth enabled phones, I'll happily support them

I can see it fine.

Here are the upgrade notes that detail the new features. I don;t see anything in there about loading block diagrams in different versions, though.

Sweet. Check back next week for version 2.0.0.

OK. Figured it out. The spec has changed quite a lot over the 5 or so years since it was written-damned progress I've got it working now with some non trivial changes i.e. it works but is a mess and it needs refactoring. So my question is what is your timeline for this? Do you need it by tomorrow, by the weekend? By next month? By next year?

Set the prepend array size to false on the Binary Write

Touche

I imagined you writing that with exactly the look you have in your avatar ...lol.

Synchronous to what? Do you mean adheres to the LabVIEw dataflow that you broke with your free asynchronous messaging?

Debugging them isn't free though

That's why I like the idea of an event on automatic error handling. You can still use the cluster, in fact, you would use the cluster to handle local error and recovery as per usual,if required. There may be a tiny overhead only when a listener is attached but since people nowadays seem to be throwing messages around like confetti; I don;t think they can complain about a couple of really useful ones when something goes wrong..

APIs, quickdrop and most of the other stuff isn't language.Sure. There's a few good toolkits, and primitives that have been added over time but even the language aspects that you've listed; e.g classes and DVRs and most of the others are between 5 and 10 years old (2005 for classes?) and pretty much all the other stuff with a very small number of exceptions is in 2009 (QD, DVR, bluetooth, XML, Web services, Shared variables and yes, dynamic user events) and those that aren't I have solutions for. Conditional tunnels and network streams I might give you but none of what you are talking about is project busting technology. Where's the inheritable FP controls? Where's the event driven VISA? Where's the inheritance that actually inherits methods and properties without recreating them? (I'm looking at you x-controls ). Where's the thousands of events to choose from in the event structure (maximise, minimise, open etc).. Why are there still bugs from 8.x? Perhaps I'm being harsh. It's probably because I've looked every year at upgrading on a wave of enthusiasm. Then I weigh project risk vs features I might actually use it seems there are too few pros once the eye candy is taken out. Upgrade to LV2013 because of a JSON primitive? Almost did but it was a real pain to use than the open source one, so back to 2009.

Don't be too sure. Not much has changed in the language since, probably, the event structure-maybe xcontrols etc. It's one of the reasons I still program in 2009. Recent updates have had some very low hanging fruit when it comes to new features. It's almost as if they are afraid to touch the core. When AQ talks about things nowadays it is generally a user framework of some description. Serialisation, for example, should have been handled by the flatten primitives but AQ came up with the Character Lineator instead (can you serialise objects properly now?). If an error system does come forth, it is likely to be specific to the Actor Framework or some other marotte du jour and require obnoxious compromises when used outside of the framework. That is the fate of all tactical solutions IMO. They can already catch errors at the VI boundary with the Automatic Error Handling and exposing an in-built event in the event structure would be extremely useful. If it could also broadcast and bubble through the hierarchy you would also have a strategy similar to other languages and you wouldn't have to code anything except filtering in the handler and how you react to the events. Additionally it would be completely backwards compatible.

woah. Never seen that one. That's all kinds of useful. I don't like that is an express VI (hidden design time config) but I can work around that with a polymorphic VI, Going to have a play and see how it pans out. Error handling has never been adequately addressed. Everyone goes for a tactical solution to what is essentially a strategic problem. I've always thought it would be nice if we could capture the Automatic Error Handling of a VI with an event or two. Then we wouldn't need to error guess problems so much by knowing where to put an error dialogue or error cluster check on a wire. Every VI would effectively have an On Error event with zero coding and the VI hierarchy could enable bubbling..

I got as far as thinking it required a session parameter which is used in later protocols but I no longer have access to the OBEX spec which is behind a pay-wall. That's not to say it can't be done, it just means it will be a lot, lot harder to find information and some protocol sniffing.which was where I was at when if fell off my radar. I'll have a another look at the weekend to see if I can do anything.

No release, no judgement. You've released...Doh!

It is something I've said on numerous occasions. Nice someone is finally agreeing with me For example. You can immediately reduce the number of VIs and code size in a LVPOOP project by between [anecdotally] 25% and 50% (50% if its just a small object with only accessors). Only by putting a boolean for get/set rather than using individual VIs for accessors. Oh, wait. We could make it a typdef enum get/set instead of a boolean to make the code more readable. Oh. Now we have an AE......Doh

Hi Honey

The Idea exchange is where you need to float ideas like this. Add it to the list.of other people who have requested zoom and been denied. The current feeling is that if you think you need zoom; you are not making use of sub VIs (and don;t ask us to maintain your code )

I managed to track down a later paper from 1983 called Implementing Atomic Actions on Decentralized Data where David P. Reed extends his original paper to talk about using Pseudo Time specifically for distributed atomic actions. That is, an action and a failure of that action is atomic across multiple remote sites.

Ah. I must have missed that (the deletion). The example just created one ove every enumeration with all controls when I tried it. There are a few directories of this in my temp directory now...lol. I must have opened a slightly older one. I'll take another look to see how you defined that that terminal had to be deleted on that VI. Polymorphic VIs are very useful. I wouldn't throw the baby out with the bathwater. The pros just have to outweigh the cons. Sometimes you don;t need to do a full factorial polymorphic VI if you are just grouping individual functions that already exist into an API. There is no explosion of code then. You ae just consolidating into a single VI for convenience and labeling. It's when you do adapt to type that things get out of hand as it is basically "Save As" then make a tiny change, rinse and repeat N times.