Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by hooovahh

  1. Neat idea editing the control itself.  But that solution is only going to work if you don't mind having no control over the GIF and don't mind looping, and if you don't need to update the GIF at runtime based on an existing file.  The demo I showed saved the GIF as a constant in the block diagram because it is faster, but I have some disabled diagram code that will instead read the GIF from a file.  It then will play the first half of the GIF, then wait for the saving to finish (random number) then play the second half.  Is there a site where simple animations like this can be used for free?  Also back saved to 2016.

    2016 Save Demo.zip

  2. On 1/9/2020 at 12:42 PM, X___ said:

    Not that I could care less, but VIM, which were introduced in ODG (old gen) are challenged by them 

    You can call the non-NXG LabVIEW IDE what you'd like since NI just refers to it as "LabVIEW" but the designator I've seen most commonly used is Current Gen (CG).  But maybe ODG would be better since, well some day it won't be current gen...unless NXG is always going to be coming next.

    Anyway I hate units too and have left them behind.  I feel bad for those that do use them as it is an official real documented feature of LabVIEW, but just has too many places it doesn't work as expected.  It's a feature I feel like the majority of NI and LabVIEW users have forgotten about.

  3. Over on reddit someone asked for suggestions on how to make a sliding UI like you might find on your phone.  I thought it was a fun challenge so here is my very rough draft that could probably be turned into a QControl.  And a video.  At the moment you can only change the settings of booleans and of a selection like the days of the week I show.  I planned on putting code for handling string and numeric value changes but probably spent too much time on this already.



    Android Sliding UI Demo.zip

    • Like 1

  4. I thought this was an interesting exercise so here is my attempt.  OpenG has some image tools and one of them is the ability to open a GIF, but for some reason it crapped out and died with your GIF even after resaving it to something much smaller.  I did find some other GIF API over on the dark side and instead used that.  Attached is a zip, extract it and run Demo Saving Button.  It will show the first image.  Then when you click the image it cycles through the first half of the GIF and waits for the simulated save process to complete.  Once it is complete it rotates through the second half of the images, and then after a few seconds returns back to the first.  Parsing of the GIF takes time so I put in the GIF images as a constant, along with the code to parse the GIF.  I also set the pane to be the color of the (0,0) pixel in the hopes it will blend in better.  Honestly this could be turned into a QControl and be made very seemless.

    Demo Saving Button Gif.zip

    • Like 1

  5. Okay I edited the spec file to start with the following:

    [Package Name]
    Display Name="OpenG LabVIEW ZIP Library"

    Then I zipped the source back up and renamed the zip to oglib_lvzip-4.2.0-1.ogp.  I then installed the package and it didn't say "Upgrade" but instead said "Install".  But after installing there was only one entry and the result was the upgrade was successful.

  6. Thanks, good to know.  I took your 4.1.0 release (maybe it was b2?) and edited it to make a package that was considered an upgrade.  I thought the changes I made were to the displayed name and version.  But now that I try to do the same with the 4.2 release in this thread I can't make it work.  I keep copying more stuff from the existing spec to the new one and it isn't working...I'll keep playing around and let you know if I get anything conclusive.

  7. As always, thank you very much for this continuation.  Inflate/Deflate on Linux RT is important for a side project I have lately so this is awesome.  I did notice that in VIPM if I open your package and already have the previous OpenG zip package installed, it doesn't do an upgrade but instead performs a new install.  It appears that the internal name of the package, or versioning changed in a way that VIPM doesn't recognize it as a new version and will install it along side the last official release of OpenG which I think was 4.0.  I was able to edit the OGP spec file and create a package that convinced VIPM that it was an upgrade.  I was curious if this was intentional to distinguish it from the official releases.

    Oh it seems the old package name was "OpenG LabVIEW ZIP Library", while the new one is "OpenG ZIP Library", I think this combined with some version changing is what I needed to edit.

  8. 13 hours ago, bjustice said:

    Thanks Hooovahh, I've used your TDMS concatenate VIs in a few places.  Really convenient to see this wrapped in a VIPM with a few other tools.  Will install this right alongside Hooovahh arrays

    The VIM Array package is a dependency, and actually included in this VIPC release.  It was just easier for me as a developer than trying to remove the dependency, and easier for you guys if everything is in one file.

  9. I haven't tested everything in there on NI Linux RT but a few of them I have.  The only thing that uses any thing questionable is the Circular buffer has a compression option where it zips the circular buffer before logging it to disk.  I used the native LabVIEW zip API so I suspect it works on Linux RT...but I forgot to test it before posting it.  Everything else is just pure G and I see no reason it wouldn't work.

  10. Now we are digressing a bit but I also have an old piece of marketing I like to show off inconspicuously.  At NI Week the last few years NI has various buttons that say phrases for that years' theme.  Usually people grab a handful of buttons and put them on the lanyard you wear with your badge on it.  I won't go too over board but I'll grab a few and put them on, but mixed in with them is a LabVIEW 7 Express pin I was given years ago by someone that was at NI Week the year LabVIEW 7.0 Express was released.  It is old enough that it is starting to rust on the back a bit but LabVIEW 7 (and 7.1) were my favorite versions for a long time so I wear them.  Last year someone was looking at my various buttons and saw that and asked where they could get the retro NI Week pins and I had to explain where it came from.

  11. One quick comment on the can opener thing.  I might well be using the can opener incorrectly, and I'll try the horizontal way next time, but I think my habits came from an old wall mounted can opener I used at my grandparents for years which was vertical in design.  Also I included an ad for it because the thought of giving a can opener as a perfect gift to the "queen of the kitchen" would probably not go over well.



  12. In the Facade, set the background pane color to the transparent color value.  This doesn't make the facade transparent when developing it, because...well it can't really.  I believe when editing the VI the pane will appear black.  But when the XControl is running in a new front panel, it will have a transparent pane color, meaning it will be the color of the front panel on that VI.  The transparent color value is 0d16777216.


    Also is this documented somewhere or just tribal knowledge?

  13. So when I was playing around with this I would map my build folder, to the www folder of my webserver, with a symbolic link.  This way I would build and it would already be in my web server folder ready to be used.

    Here is a very loose set of steps I did to map a folder from a build to a place that the webserver uses.

    I don't know of what NI uses on the hosting side and I've always just used XAMP which is Apache.  Windows has a built in server too that works well enough for basic stuff.

  14. The "Check your internet" is a catch all error basically saying it couldn't install, and it must be because the internet is down right?...right?  For me I got that error when I had a bad stick of ram in a computer, and it would uncompress a package, and then the CRC would fail.  I'd restart the installer over and over until it worked but the computer had all kinds of other problems.

    The Offline installer including drivers and several other things is a bit crazy.  I mean will the community edition also be 25+GB in size?  I'd usually download the whole developer suite in the past anyway so it is on the order of the same size as that was.  The Web install however was perfect.  It would prompt you on what you wanted to download and then install offline using those things worked great, but no more.

    Sorry I'm not from the 2.x era LabVIEW and the idea of installing it in anything other than the default install location of "LabVIEW 20xx" seems crazy to me.  I suggest embracing the change...from 2003.  Package manager does decide where it goes and I saw several people complain that they couldn't even install LabVIEW to any place other than C:\ drive without editing the registry.

    When I go to a new version of LabVIEW I just leave the one that's already there.  I mean I usually don't upgrade all projects at once and some maybe in the older version so I just install them side by side.  I think the most I've had installed was probably 7 or 8.  I guess what I'm saying is I've never uninstalled a version of LabVIEW, and I would expect problems if I did.  I mean honestly it should work just fine, but I wouldn't expect it to.

  15. 14 hours ago, Aristos Queue said:

    Just locking doesn't suffice:

    It really depends on what you are trying to do so I get that.  For me even just setting the VI file to read-only would be enough, but I ran into a few times when a mass compile would want to overwrite the VI despite it having separate compile code, but that was years ago.  For me the purpose was that a developer would be drilling into the code and not realize they were in a reuse function and would start messing around with it and changing things that will now make the program behave differently on one developers machine, than the others.  A gentle reminder to not mess with something was all we needed.  But I get your points.

    • Like 1

  16. 9 minutes ago, Aristos Queue said:

    That seemed like a useful concept to me. Ever since then, I've been fine with basic security around the password, as long as we make it clear to users that the password isn't intended to protect intellectual property.

    Not trying to derail the thread even more, but every time I hear that argument I say that is why you can lock a VI without passwording it.  Which is what my Pre-Build action on building a package does.  Need to edit it and do a test?  Sure just unlock it.  Drilling down into a VI and not realize it is part of the reuse library?  You will when you see it is locked.  But whatever.

    I still tell the quote from NI R&D saying off the record that the protection you get from password protecting a VI, is about the level of protection you get from tissue paper. 

  17. Oh yeah I forgot about that.  This is the Salt that gets applied to the MD5 of the password.  Starting in 2012 NI started salting the block diagram passwords.  The salt that gets applied is something like the number of all String, Path, and Numeric controls connected to terminals.  I think this does go into clusters and arrays so the work actually needs to be recursive.  This ends up being a 12 byte salt, but I think 9 bytes are always 0.

    Of course you don't need to do all of this, to figure out what the salt is.  I mean all you need to do is guess three numbers, all of which are the number of controls on a terminal so you know that the value will probably be small.  So when I wanted to figure out what the salt was I would just keep guessing until a match was found.  It was easier than trying to look into the VCTP block to find all objects, and then all terminals, and blah blah blah.  If you have a VI that is passworded correctly then the only unknown in the equation is the salt.  I mean lets use this example equation (note that the actual one is different):

    Result = MD5(Hash 1 + Hash 2 + Hash 3 + Salt)

    In a valid passworded VI I can pull out each of the variables from the VI other than the salt.  So I just made a VI that sets salt to 0,0,0, then 0,0,1, then 0,0,2, etc, until the equation matches.

    Fun story:  Years ago we were in a meeting with a few LabVIEW champions and LabVIEW R&D and the discussion of protecting intellectual property came up.  Someone was asking NI about ways they could tighten up their security.  I made a suggestion of encrypting the password with the number of string terminals in a VI,  knowing that this was something NI already was doing.  Another LabVIEW Champion said that was a bad idea since that could be figured out by simply opening the VI and looking at it.  I had to inform them that I said that knowing that that scheme was actually used by NI, and I put that out there to subtly let R&D know we know about it.

    • Like 1

  18. When a VI is in a library, the password is stored in the VI, and in the library, and there is some kind of link in the password of the VI to the library, in the VI.  So if you recreate a VI, and it doesn't have a password but the library does, or if the two passwords don't match, then you will get that error.

    Now that I'm searching for it I can't find much, but Flarn also had some code for getting file structures of a VI.  His personal site had a few things but seems to be down at the moment.


    Just be aware that most of his stuff is viewing and editing the objects in a VI, so I'm not sure how useful it will be.  But he should have some general file parsing stuff.

  19. 17 hours ago, Mefistotelis said:

    I actually only found two readers for VIs, both quite rudimentary: one in Python, other in PHP.

    I reversed the PHP code into LabVIEW here as well, adding just a few features.  Also you've probably come across Flarn's stuff, he has some code for object deconstruction getting into pulling out and manipulating objects in the LabVIEW source.  Which is neat but probably isn't what helpful for what you are doing.

  • Create New...

Important Information

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