ShaunR

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.

It's all great but there needs to be thought about the pros and cons of doing this with polymorphic VIs and classes.The fallout is, that if you take the supplied example, you go from a single VI of 30kB so several VIs totaling ~180kB with no change in functionality. That's nearly a 6x increase in code size with a 7 fold increase in the number of VIs That's why applications take 10 hrs to compile When I choose to use a polymorphic VI, I make that choice very carefully as a trade off between user friendliness (the menus, adapt to type and terminal reduction) and code complexity and size. As I've said before, classes and polymorphic VIs bloat code and cause replication. The worst use would be to effectively just move the enum list of an AE to a poly menu "because it looks better". The tradeoff is the increase of the number of VIs and code size in proportion to the number of items in the enum list with consequences to performance, maintenance, compile times and understanding complexity with no change in function. The gain is a subjective aesthetic for a developer, not even an end user.. The best use is hiding controls unused for an enum item and logical groupings of functions.That is not easy to achieve with automatic wizards as there is no context that can be gleaned from the VI itself. It is very easy to create huge quantities of code and complexity with wizards though. Why, for example does the "Return Settings" need file terminals? How could we tell the wizard to not wire and create those terminals for that enum?

It looks like you can operate sequentially from your examples so another method s to use a simple scripting language. This assumes also that the file format is negotiable or can be translated but results in much more flexible and easier to maintain and understand code.. SR ExcelTest.zip