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. Remember. Many of us only use toolkits like these because NI refused to make the native JSON primitives' fit-for-purpose.

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 are refactoring; changes in architecture may become more obvious. For example. You can't switch from a Queue'd State Machine to an Event Driven State Machine just by sub VI'ing sections of code. So what I described was refactoring. I don't think we disagree that sub Vi'ing improves readability, however, I have also outlined how to improve maintainability and reduce complexity through code reuse - not only within the old code but leveraging the time spent to benefit current and future projects. This is a tried and tested way of making sure hideous but working code doesn't turn into beautiful, not fit for purpose, code and is an argument to justify the time spent refactoring when there is probably no longer a budget for it.

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 will start to notice some of them are very similar. Look to see if you can make them identical. This is a heuristic way of creating code reuse. Then you can start looking for old code that you have turned into a sub VI that look similar to your current project. Your old code is a test harness for your code snippets. It's been proven to work, right? Once you have it working correctly in both old and new; fill out the documentation, icon etc if you haven't already and put comments in it. Then stick it in your special toolbox for reuse. You don't need to publish the modified old code but as you gain confidence in your toolkit, you will merge the reuse code into it. If you change the reuse code, run the old software to make sure it still works correctly. This is called Black Box Testing. Old code is very useful. It's proven code that works. Cleaning it up and sub VI'ing it will benefit your current and future projects too. You will eventually be able to spot reuse code candidates as you create new VI's - the patterns will jump out at you. You will look like you were a master from day one when other people look at your old code. Only you and your source control system will know the truth .

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.

Why not just bypass the the USB-RS232 and talk directly with RS232? Wasn't the USB-RS232 used because there was no serial port, which you seem to have now?

I doubt it. Code monkeys have extreme problems with this kind of test because there are few parameters for them to follow. They are forced to think of a solution instead of being told how to implement one. The interesting thing is, though. Even if they are a code monkey, they may show skills or a propensity to think of solutions in the discussion afterwards that they previously haven't been called upon to utilise. While I don't think that is useful in Cat's case, it very useful if you are looking for a team member that you can cultivate.

You didn't and can't. Unless you are interviewing, there's not a lot you can do. When I interview I get them to do a 30 minute test. It's a test that they cannot complete in 30 mins. I tell them that they are not expected to finish, it's not expected to work, there is no right answer and I just want to see their thought process when tackling a task - just make sure it's tidy enough so I can read it. This is all true. After, we discuss the task. What they thought, what they were and weren't happy with, what issues they think their code has and why they did certain things. Additionally I ask things like how would they improve *my* test. Did it make them too uncomfortable, would they have preferred a specific result/correct answer etc. A good engineer will be able to articulate problems with interpretation of the instructions, the assumptions and decisions they had to make and what they would change now they know the task and we have discussed it with my input. What code they actually write is almost irrelevant and only serves as a common talking point but you'll spot the fakers straight away. You very quickly find out who is an engineer and who is a code monkey.

Well. There's also the Windows PDF which you can send to a printer, if you're feeling brave, but the ones you have detailed are by far the easiest.

This is a 3rd party (and free) solution I've used the past, successfully. Download Sumatra PDF from the website and install. You can use it to print from the command line. . Sumatra Print.vi

To use the PrintDocument .NET interface you need a 3rd party .NET assembly to render it (like Acrobat). Otherwise you'll just get a blank document.

You can register ActiveX controls using regsvr32.exe (located in windows/system32).

NI have said on many occasions that the VI diagram password system is not intended to protect IP - more of a disincentive to fiddle with diagrams (think of operators on a production line). NI's recommendation if you require stronger security is to remove the diagrams.

Nah. You just haven't had a misspent youth like I have ;)

If it's something like Get User Tag.vi or Set User Tag.vi, I can guarantee there is nothing in there that would surprise you.