Rolf Kalbermatter

Our friend flran posted them somewhere else on this board. Aristos himself had revealed them at some point by posting a password protected file on the NI site. Of course it didn't take long until someone peeked past the password. But this implementation is definitely to be considered part of the unfinished attic in LabVIEW, with many rusty nails sticking out everywhere and possibly causing you nasty pains. The IDE doesn't necessarily know. In fact the older Visual Studio IDEs did nothing like that, the only thing they knew about was syntax highlighting. But many IDEs (Eclipse too) have nowadays special syntax check modules, that basically contain the entire syntax parser of the compiler already in order to provide such just in time error indications. It's not that the IDE is doing something that is trivial, it's that it pulls in the entire compiler parser to do this. A void wire logically doesn't yet exist in LabVIEW although the LabVIEW internal typecodes to know a void datatype, which is used for various internal things already. It is not an unknown type but a type carrying no data at all.

Hmm, for some reasons it would seem rather strange to support the retrieval of HWND across machines. The HWND really only has any meaning on the system it was created. And if you use the OS Window you are setting yourself up for big troubles once you move to LabVIEW for Windows 64 bit. I suppose you are doing some remote work where you retrieve the handle and pass it back to another function or whatever on the same remote system. The proper way to do such things would be to have the actual handle twiddling all done on the target machine and expose that VI doing this, over the VI server to your other machine(s).

The issue is rather complicated. I can fairly easily add support for filenames in whatever codepage your Windows system uses as default OEM codepage currently (which is how ZIP file names are supposed to be stored while LabVIEW uses the ACP itself), but there is no simple way to allow support for arbitrarily named files not currently displayable in that codepage. Those files can be correctly seen on modern Windows systems with NTFS filesystem since the filenames get stored as UTF-16 there, but LabVIEW's file functions still are 8 bit codepage based. If you try to open a file in LabVIEW containing characters not currently displayable in the current system codepage, LabVIEW fails fatally since it can not reference such a file at all. So in order to allow LVZIP to compress a directory containing such files into a ZIP file and vice versa, the entire directory enumeration and such would need to be done outside of LabVIEW in the C code in order to allow using the UTF filename feature in ZIP files. But adding an entire ZIP/UNZIP utility to the C code of LVZIP seems a bit like overkill to me. So the question is if it is enough to support foreign characters for the system the file was created with, and an optional setting to force Unicode filenames in the archive. But if you try to archive or unarchive files with characters in the name that can't be displayed by the current Windows codepage, then LabVIEW itself would catastrophally fail when I pass those names to the LabVIEW file IO functions. Also note that the same applies probably for Mac too, and Linux I don't even have an idea yet how to solve this. For the cRIO and Pharlap systems it most likely is not even an option. It's to bad that the LabVIEW developers didn't change the internal File IO API to use Unicode IO functions and extend the Path variable to support Unicode internally. Being a private datatype anyway there would be very little issues with backwards compatibility since whoever has relied on internal details of the Path datastructure would have been going out on his limb already.

I'm not aware of any conditions that would disallow transfering the ownership of a LabVIEW license to someone else. And in most places such a provision in the license agreement would be null and void. However you need to make sure that you do get the ownership. Simply buying a CD ROM and a license serial number from anywhere might not really give you any rights. I would insist on a document that names the serial number, states the previous owner and also grants an irrecoverable transfer of ownership of that license and serial number to you. Otherwise you may try to register the software at NI and then get told that you are not the rightful owner and when disputing that, the previous owner suddenly may claim to still own the license. I do know for sure that NI does actually care about ownership and has in the past contacted us about licenses that we have originally purchased and sold as part of a whole project, when the actual end user did register the serial number as their own, since the registering entity did not match the purchasing entity.

Indeed, the zlib library or more generally the zip addition to it do not use mbcs functions. And that has a good reason, as the maintainers of that library want to make the library compilable on as many systems as possible including embedded targets. Those often don't have mbcs support at all. However I'll be having a look at it, since the main part of the naming generation is actually done on the LabVIEW diagram, and that may be in fact more relevant here than anything inside zlib. There might be a relatively small fix to the LabVIEW diagram itself or the thin zlib wrapper that could allow for MBCS names in the zip archive.

Ton definitely has pointed out one potential pitfal in your code. The Panel:Close? event always works for me. if you tell LabVIEW to discard it you have to make sure that your state machine then goes into a clean-up state, that eventually closes the front panel explicitly and then also terminates the state machine loop. If your front panel is the top level VI too, the code after the VI:Close method won't be executed in an executable as the LabVIEW runtime engine will be shutdown immediately after the last window is gone, but it helps when the application is run in the development environment. I have personally only used the Application:Close? event in deamon like applications that do not show a front panel by default. The proper operation when a user requests to shutdown the machine is that Windows sends a WM_CLOSE message to every application window, which will result into a Panel:Close? event in the LabVIEW VI, and then a WM_QUIT to the main instance which will trigger the Application:Close? event. But if you handle all the Panel:Close? events properly there should be no panel (hidden or not) left over at the time the Application:Close? event will trigger. On the other hand adding both Panel:Close? and Application:Close? to the state machine handling and going into a proper VI terminate state when you chose to discard that event, wouldn't hurt either.

To be honest, I'm not sure about my position to Bitcoin itself. I tried to understand what it was about by visiting the forum there, but don't really got a clear picture. From some of the remarks there, it seems to be used by some folks in somewhat questionable ways. But then anything that represents some value in some form, even virtual currency or items in online games, is quickly attracting some folks who have more than questionable intent. So that alone is certainly not a criterium if the the idea of Bitcoin could be considered legitimate. However it seems to me some form of online virtual currency that only exists by the gratitude of people believing that it represents some value. That in itself is an interesting concept and in fact not so much different than even our official currencies we pay with all the time, and probably even more real than derivatives on stock exchange markets. However who controls the creation of that value? In other words how are Bitcoins created? And I'm not so much interested in the technical details here as is already mentioned in this thread by the formula, than the process and procedure that controls the creation. If it could be created by anyone in any number it would obviously loose all value.

With this reasoning any law enforcement attempt would be useless. But as it seems it is usually quite effective without the need to get the death penalty invoked, and to my knowledge even in the US exist states where the death penalty is not even an option as means to enforce the law. And in this particular case, stripping the offender of the monetary gain and some additional fine is usually the modus operandi, with possibly jail for repetitive offenders. Death penalty for copyright violation would seem really archaic to me, and at least here it's definitely not an option. As to the fact that reasoning with stealing money or the work of some writer, certainly has an emotional component, claiming that stealing software or a book by copying it is both legally and/or morally right would seem emotional to me too already.

You realize that the emotional aspect of this thread has really just started when you brought in murder!

Well, copyright was in the first place invented to protect creations, such as writings or even paintings. Maybe some want to claim that anybody can copy a book for instance and distribute it as his own, but I doubt anyone really would want to make that claim seriously. Unless of course you think writing a book is trivial and can not be viewed as an ability and therefore an author has no right to gain anything from trying to sell it. But whoever does that should please start writing their own books first and make them available for free before even trying to make that claim. The application of copyright on software is in many ways flawed but it is the best we have generally come up with so far. It's definitely something not everyone can do, especially doing it good, so it would seem an ability that deserves some protection. Of course it would be nice if that would not be necessary since nobody needs to earn any money anymore as everything in this world is free and available to whomever needs it, but that is not how this world works, as we all know. So why would it be ok to copy software for free and deny the creator a decent income but not to steal money from the rich as they have more than enough of it? Does someone really need Billions of dollars? Do you really want to limit software creation to "free as in beer"? Or do you say that the decision to pay for a software should be voluntary, no matter if you use it to make profit yourself or even just for some leisure time? I think whoever makes such claims should first have a proven track record of providing his own creations under such conditions, before he or she has any right of speaking.

Why do you ask? The right way for a real programmer would be to start working on it not to ask if someone will do it!

I'm not sure but I don't think there is a good way. It may be possible in theory to use the Picture Control to display a PICC formated data stream and with lots of wizardry I'm sure it would be possible to store the PICC as a resource inside the VI itself and reference it from there but that would require so many hacks in the VI data itself that I would consider that a major work even for someone who has access to the complete VI data format specification. The OS clipboard likely won't work since it does not know about this type of format. Yes you can copy picc's between different LabVIEW objects over the clibboard and that is an interesting way to customize controls, but this is because LabVIEW maintains internally its own clipboard which knows about all kinds of internal formats including LabVIEW diagrams, paths, controls, and also PICCs, etc. but it does not transport those formats to the external clipboard and back but instead translates them to a format that the external clipboard officially supports, such as a bitmap when you copy a diagram and then try to paste that in another application including a different LabVIEW process. While on Windows the supported external vector image formats are WMF/EMF, on the Mac it used to be PICT which actually worked quite a bit better than WMF/EMF back then. Why not still use the PICC format? The code is there already, the internal control editor too (eventhough it badly needs some love). Adding another format like SVG may seem like a nice choice, but LabVIEW does not know about it so far, so it would have to be added, and it would not just be an importer/exporter but just about anything where PICC resources are used would have to be touched seriously. So basically anything in the frontpanel. Maybe if they decide to overhaul the control editor and make it a fully featured editor again, they would consider adding a new intermediate format like SVG but not vice versa. I also believe that much of the silver controls was simply done by using the control editor to create new custom controls, but I haven't looked at them yet. Still using classic controls everywhere for internal frontpanels and the system style for user interfaces almost exclusively. I feel the everchanging cry for newer, fancier, simpler, crazier, whatever controls is mostly hysteric. Whatever MS declares as the newest hit, people seem to want to have it, even if it hurts in the eyes.

Where would you want to take such a picc? This format was created by the LabVIEW developers for LabVIEW and outside of the LabVIEW development group exist no editors or such who can create this format. I used to use WMF images in the past. But most WMF editors out there where abominable to say the least, and created images that produced rather different results depending on Windows version and viewer used. WMF supposedly is a little better but also a somewhat niche format that most Microsoft applications do support but don't advertize, and only very few other applications claim to support but with varying results. I had some interesting results by using Powerpoint to create the graphics. However eventhough LabVIEW has some support for importing WMF/EMF from the clipboard, it can be tricky to convince Windows/LabVIEW to take this format rather than have Windows advertize an intermediate Bitmap version of the WMF/EMF file, which will cause LabVIEW to use that instead. However I can not comment on how this would work in recent versions as my experiments with this date from LabVIEW 3 and 4 times. I'm pretty sure that this functionality did not receive any face lift since at least LabVIEW 5 because it is in fact an almost never used feature by anyone and NI doesn't spend resources on unused features. And it just as much could have bitrotted over the years, and not work anymore or even be removed entirely.

Most likely because this was not humorously meant but purely logical.

As pointed out by others already, your car analogy has many flaws. For one you can't copyright a colour and even less so the right to change the colour of something. Copyright is about the right to copy something considered a creation in some form or the other. Except the design style, logo and such things there is little that could be copyrighted about a car. Patents is an entirely different thing again but even that is about copying something considered technical art in some form. Both do not apply to the fact if you can paint your car or not. A manufacturer could declare your warranty void or you could loose the right to do liability claims against the manufacturer, if he can make it reasonable believable that your paint job has caused the defect you seek warranty for, or the accidents you claim liabilities but nothing else. Software is an entire different beast. Most licenses, even open source, don't grant you ownership of the software, only a right to use it. It could be considered absurd, but then what ownership would you get? Can someone own bits and bytes, or the letters in a book? Do you own the letters in a book or rather just the paper of the book the letters are printed on? Are you allowed to destroy the book? Yes of course and so are you allowed to destroy the copy of the software on your harddisk or even the harddisk itself, as that is a material good you own. But you do not own the particular assembly of bits and bytes that makes up the software. For one thing because ownership means usually exclusivity but how can you own those bits and bytes exclusively? All material things can only be owned once at any particular time. A particular software exists unlimited times, so the classical property rules are very difficult to apply here. That is why all legal systems have rather adopted the copyright for distributed software than the property right, since many provisions of the property right simply do not apply to software programs at all. If it is a good choice I'm not sure, but adopting property rights instead would certainly not solve those problems but simply create others and possibly a lot more. As you get older you might find out that anything tends to have quantum mechanic inner workings, especially things that appear logically bipolar in nature. What is good and bad may seem very clear for simple minds, but if you go deeper you will find out that the decision about that is very relative and only really is made by the observer, but definitely not an universal police force called God.

Legally you are totally wrong. Nowhere in the license agreement does it say anything about "for profit". Also you may not do it for profit, others using the information you dissect to the public will! In some legislations NI could loose the right to seek payment of damages through the legal path if they don't go after all such activities, independent if it is for profit or not. How many bad guys get away nowadays pointing with their finger: "But he did it first and never got punished, so why should I be!" And the legal system in some places agrees with that logic. Depending on where you live, you may be indeed fairly clear, both because of legal laws in your place as well as being far out of reach of lawyers NI is willing to pay. However you may want to travel at some point and such activity could be a serious liability then. And using an alias in a forum like this is certainly no reliable way to hide your real life identity.

Could be the path glyph. Also they are not bitmaps but vector graphics. The LabVIEW picc format resembles the Macintosh PICT format in many things, but has a somewhat different binary data format.

I haven't really used .Net so far, other than converting some .Net code to Java! And creating a .Net binary module for LuaVIEW for a client in order that they could interface to .Net drivers from within our test application. But specially that last one forced me to learn more about .Net than I ever cared to know. Anyhow I rather write a standard C shared library from scratch than integrating .Net into LabVIEW applications myself.

What's so special about those pics? If you haven't noticed, they resemble many standard LabVIEW control components, just in a special colour scheme. Ever heard of blue screen stamping and such? Would seem quite logical to use specific colours to identify various parts of a control, such as background and foreground area!

.Net assemblies should not be placed in the system32 folder. The .Net loader will not pick them up from there. Instead they need to be placed in the GAC (Global Assembly Cache) or in the directory where the executable of the calling process is located. In the case of LabVIEW development environment, the better place is the actual project directory as LabVIEW registers that as well with .Net when loading a .Net assembly from within a project context. But if possible .Net assemblies should be installed into the GAC by an installer.

I wouldn't say I prefer it, but I have some fond memories off working on Valid and later Sun Sparc stations using a graphics editor called ged. This was used to design electronic schematics both for PCB and ASIC design. The displays were phosphor screens and had a very similar look. No draggable windows, but a fixed mouse controllable drawing area and a command line entry that allowed to edit the graphic design magnitudes quicker than any menu oriented interface. In fact QuickDrop goes quite a bit in that direction and as some people at NI expertly demonstrated really can be a big improvement in editing speed of diagrams. There was a text script configurable button menu bar on one side of the screen to help use the less common commands, but common operations were much quicker by typing them on the keyboard than trying to find the command in the fixed menu bar and even more quick in comparison to a navigable hierarchical main or even pop-up menu.

NI has in the 15 years or so that the password protection existed, revisited their semi-official response several times. Officially they never publicly committed to helping recover VIs with lost passwords. Unofficially they did make some efforts to help well known customers recover their own VIs, if they could proof reasonably well that it was actually their VI. As that could get easily into a legal and administrative nightmare, they seem to have more than once issued an ukas internally to stop providing this service altogether yet it seems to have surfaced every now and then again, if a customer knew the right person to contact. Supposedly that would be someone rather high in the command chain of NI management. It's not a bad advice at all! Removing diagrams is just about the worst you can do for distributing VIs. If you are not careful and keep several copies of your source code you can end up VERY easily with no source code at all. That I would consider worse than having the source code exposed to some unscrupulous people no matter how precious that source code is. If the source code is not important enough to warrant a %$#$%$#%#$%#$% comment when you notice that it is gone, you certainly wouldn't worry about someone "stealing" that source code, and if it is a multibillion dollar IP, then good riddance if you loose it! Also distributing VIs without source code requires you to provide one copy of the VIs for every (minor) LabVIEW version and platform you want to support. That is just about one of the bigger nightmares to happen in terms of maintenance and support.

I think that is what Ton meant, he just didn't use shell script variable names. And it is probably very much Windows AND VIPM version dependent. Mine is for instance in C:AppDataJKIVIPMdatabases (Windows 7) which would be equivalent to %COMMONAPPDATA%JKIVIPMdatabases. C:UsersAll Users actually shouldn't exist on a clean Windows 7 install, as that is normally called C:UsersPublic instead, but maybe you upgraded Windows 7 from a Windows XP installation?

The way I did this in the past is enumerating the entire contents of the diagram recursively, place everything into a selection, copy it to the clipboard, then pasting it from there into the new VI. Quite involved, and very easy to forget something, so if you do not need this to work with ancient LabVIEW versions, I would look for the Inline method, Darin mentions. Sorry I wouldn't know where it is as I haven't used that so far, but I assume it would be only in recent versions.

- Move is as the name says not meant to copy code around for one thing. - Also you make the mistake to try to copy a TopLevelDiagram into another TopLevelDiagram. For one thing a diagram can NOT contain a diagram but instead is an internal property of some other object, such as a VI or a loop, case or sequence structure. - Please also notice that there is in fact a difference between a TopLevelDiagram and a Diagram(Section) you can for instance get from a loop or for every case in a case structure. They are similar but not the same, since they are owned by two very different objects, as VIs existed before there was a proper object hierarchy in LabVIEW. For another thing I would believe it is there to move nodes around to another part of the same VI, not copy it to an entirely different VI. Clarification: objects existed in LabVIEW from at least version 2.0 internally and were used extensively despite LabVIEW having been programmed in standard C exclusively back then (all the C++ compilers back then were not up to the task of compiling a code base like LabVIEW without bugs and horrible performance of the resulting executable), but that object hierarchy was not exposed anywhere, and was not fully formalized, as C has no means to enforce any object hierarchy formalization and all had to be done by hand and agreement between developers. The first versions of VI Server around LabVIEW 4.0 only allowed access on VI level, and only around 5.0 was the VI server interface to the object hierarchy of frontpanel objects added and around 6.0 extended with what we know as scripting interface now.