ShaunR

Possibly in this case as it has searching. But we wouldn't have to write parsers if the current primitives were useful I don't know what the current status of the G toolkit is, since the last person that took over maintenance and release is no longer active on this forum. That's fair enough and I'm sure appreciated. However JSON Schema - if that's your target - isn't an edge case. Your Lineator would be the place to implement that, so I'm confused by the comment "long way to go" for a library that I think is pretty much feature complete.

Indeed. I don't know what AQ is referring to with CL (Command Line? Common Lisp?) but I have a feeling he has an eye on the library supporting JSON Schema-another IETF brain-fart which made HTML a nightmare until they ditched it and brought us XML. They have a habit of taking nice simple solutions and "formalising" them them into bloated, complicated solutions that nobody uses. I think the library is pretty much feature complete at this point-maybe some data types missing but can't think of any off the top of my head - so this sounds peculiar...unless JSON schema is your target. R

A paean to the utility of JSONText.

@Aristos Queue Off topic I know. But whatever happened to AQ Character Lineator INI Serializer/Deserializer Didn't that do JSON?

Source

Refactoring and re-architecting are slightly different things. The main difference is scope, intent and risk but how you achieve them may be similar. Refactoring is to improve maintainability, readability and complexity. This has less risk to the overall behaviour of the software and sub VI'ing will do this effortlessly. Re-architecting is to improve the logical operation of how you achieve external behaviours. It's to improve modularity, interoperability and cohesion . This is a much riskier proposition. You cannot re-architect spaghetti code without first refactoring but while you

Then you are already more advanced than the average programmer. What you will see? Or how long it will take to make it right? Sub VI, sub VI, sub VI. Look for reuse. Take a very small section and make it a sub VI (only one click). Clean it up. Nibbling old code from spaghetti to sub VI's has huge benefits. Don't do it all at once. A little clean up goes a long way. Do a sub VI every week or month. I can guarantee you've rewritten the same behaviors and data manipulations many times in the past; probably even within the same application. As you create the sub VI's you wil

No. Welcome. Well. I might yell at you if you write it that way in a CLFN and wonder why it doesn't work

Yup. All Windows GDI functions have thread affinity (aka must call in the main UI thread) so it wouldn't matter if you called GetTextExtentPoint32 directly, you would still have to run it in the LabVIEW root loop.

The call is not thread safe. Don't do this.

I wouldn't put 99.999% of any code written today on a satellite-and that includes my own. Go back 20 years and I would swear by any code that was written would have zero bugs otherwise it would not have been published. The reliance today on "updates" and "beta" versions is a detriment to all software. It's like psychologists creating models of human behaviour and expecting it to model real life...with updates. Call me cynical but I think software robustness is a far-cry from what it used to be. But that's progress, right?

I know what you mean. I have the same view about ActiveX and .NET. But XControls aren't as bad as those technologies and, although a lot of work to make them robust, they are worth it is some scenarios.

Nice. Is an XControl in the works? You know, for science

ครับผม

I did something similar a while ago. I eventually put it back in my private toolbox due to a lack of interest.