Jump to content


  • Posts

  • Joined

  • Days Won


ShaunR last won the day on July 22

ShaunR had the most liked content!

Profile Information

  • Gender

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since

Recent Profile Visitors

22,341 profile views

ShaunR's Achievements

  1. I also have not really had to implement undo for a sophisticated application. I have implemented "Restore Ro Default" and limited undo for settings, configurations and such but have not been called upon for the kinds of undo required for things like drawing. I would imagine the same method could be used though. I used the SQlite Savepoints for configurations and a default table which could be copied to the main table for "Restore to Default". The latter is an example library in the SQLite Toolkit for LabVIEW. Other similar operations can also be realised like restoring the state of the UI after exiting (form position, controls etc) but that's not really what you are asking here; just an indication of the usefulness of these approaches. Addendum: There is a description of a method for Undo/Redo using SQLite triggers. Automatic Undo/Redo Using SQLite They over complicated it by doing it in an "Object Oriented" fashion but I might use something similar for the redo while keeping the savepoint method for undo.
  2. 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.
  3. 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.
  4. A paean to the utility of JSONText.
  5. @Aristos Queue Off topic I know. But whatever happened to AQ Character Lineator INI Serializer/Deserializer Didn't that do JSON?
  6. 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.
  7. 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 .
  8. No. Welcome. Well. I might yell at you if you write it that way in a CLFN and wonder why it doesn't work
  9. 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.
  10. The call is not thread safe. Don't do this.
  11. 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?
  12. 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.
  13. Nice. Is an XControl in the works? You know, for science
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.