Rolf Kalbermatter

Actually since about LabVIEW 8.2 they sort of are through the badly named Callback functions. LabVIEW 7 didn't have that but CINS had a CINAbort function that could do that, if properly implemented.

Yes! You can not change the buttons for a window once they are assigned, only hide them with the other method. It should have nothing to do with dumping the VIs out of memory, but closing the window (and therefore removing its taskbutton from the taskbar) which has the buttons assigned.

I was refering to a method to retrieve the case labels. That is where I came across this error at some point. It may be in 2011 though, didn't check recently.

Actually that doesn't have to be. It's a logical VI scripting method for case structures, yet it seems the need was never big enough in comparison to the implementation cost that anyone has really bothered to assign resources for this. So yes this may jog NI and it could result in either adding the implementation or fixing the availability of that method in the public VI interface, depending if the implementation is hampered by some difficult to tackle subtleties or not.

They use the MSI API which is basically the official low level API to the Microsoft Installer technology. It's a super complex system based on a relational database system to manage all the packages, versioning, dependencies and what else that a packaging management system needs to maintain. There are probably higher level MSI interfaces based on .Net and ActiveX but the core API is a pure DLL based interface in MSI.DLL but I doubt would be useful to try to interface with the Call Library Node directly. NI uses a DLL interface that was probably developed by the LabWindows CVI group to support creating installers from applications developed in it. I have read some time ago a comment by a former member of the MSI developer group, who admitted that choosing for a relational database system for this, was probably more than a little bit of overkill but that once that decision had been made there was really no way of going back and changing much anymore. The whole MSI technology used is therefore really Windows provided, and the application builder just uses a higher level API that allows the minimum amount of customization to this functionality that is required by the NI application builder. It could of course provide more flexibility but the cost of such a solution is simply enormous, the knowledge to use these options rather high, and therefore unlikely to be used by most. I believe that the OpenG Builder did interface to an undocumented VI to plug into the application builder part of the MSI component and LabVIEW 8.0 changed the entire Application Builder so that the OpenG Builder broke. However at the same time NI documented part of the application builder VI interface so that it was possible to access those methods outside of the project interface.

You are right that callback from Lua code to LabVIEW and vice versa is an integral part of LuaVIEW. However there is a limitation: You can't do that recursively at this time. This is due to the fact that call stack management across those borders is limited and can't be easily chained in a recursive matter, both because of very different parameter interfaces between LabVIEW and Lua, with LabVIEW not even having a classical call stack at all, but also because of complications in error unwinding when backing out of recursive call sequences. I have been looking into relaxing that limitations with a fully recursive call stack management, but the necessary effort is rather high in comparison to the benefits, and that feature also offers a very easy way to create overly complicated architectures that are bound to let a user shoot in its own feet. Variant integration would be great but unfortunately the C side of the LabVIEW variants are not only undocumented but have also varied between different LabVIEW versions.

What's the reason for using gzip instead of ZIP format? Knowing that would give us a better idea about your needs. As to the Python node, you can find that under LabPython. The OpenG Tools don't support the gzip format out of the box. While it wouldn't be impossible to support it, since both make use of zlib internally, it's quite a bit of work. But integrating gzip by using LabPython is really very roundabout. Have you looked at executing the gzip executable through System Exec?

Version difference, varying support by various browsers?

Not exactly like that. Web UI Builder is a project NI already has put up, and your posting is either more or less copying that or building on top of the NI Framework. I'm not sure. One of the biggest drawbacks of Web UI Builder is that it is based on Silverlight. While this is ok if you don't mind locking out more than 50% of potential computer and tablet users, it's a to big limitation in my eyes. I think that initiatives like WebSocket are more interesting in that respect, eventhough they have their problems too. Also I said Open Source, not crippleware.

I stand corrected. For some reasons I believed it would include 1 in the possible range, and wondered why as that made not to much sense at all.

A competitor doesn't need someone like this on board either. Such a person is just as likely to hack their tools, leave after some time in disgruntlement because of one or the other disagreement and put everything up on internet to show them who is the real king. Besides, this poking under the hood is not something their already hired developers couldn't do, especially when all the info is posted so nicely. It's also not something you need a particular CS degree for. Any inclined hack kiddie can do it, if he has access to LabVIEW. Last but not least, no competitor is really interested about the rusty nails in LabVIEW's attic, they rather would want the construction plans of the whole thing. Even if they had, they would need to be very careful, or they are faster out of business because of legal action than they can create a product from it to start cashing in. And if you can't cash in on something it is worthless for every economical thinking entity, which everyone wanting to stay in business has to be. Personally I would be impressed by someone showing that he can pull off an Open Source project. It doesn't have to be a LabVIEW clone

Mathematics is tricky. The round to zero is possible with the floor() operation but is not sufficient. Since Randomize() produces values between 0 and 1 with the ends inclusive, you still can end up with a few potential values outside the range every now and then. Also just as a trivia there are in fact two round() used in mathematics, one rounds 0.5 always up the other towards even numbers. The second is meant to reduce the effect of rounding errors in combined mathematic calculations with multiple roundings occuring.

Well my Dutch is worse . I'm from origin Swiss, with Swiss German, then had to learn French, of which I remember very little, then ventured into English and finally Dutch. So while I'm still fairly good in German, a bit less in English and Dutch, the mix of all these three hasn't helped the grammatical correctness of any of them.

How exact is exactly? If you talk about microseconds you better employ an RT system or some hardware timer. If seconds is enough a little (abortable) wait loop is all that you need.

Using a Method node set to operate on a VI reference and executing the FP.Close method, after everything else in the VI has finished?

Thanks a lot . And if anyone wonders, yes I fixed it as I prefer to fix grammatical errors whenever I can.

It has been well known in this group as well as on the NI groups, that the VI password is not meant to protect your multibillion dollar IP from preying eyes. For several years already. It's been like that for quite a while and there is fundamentally no way to make it really significantly more secure. Security in this sense is anyhow not the right term. It's not about security at all but at most about hiding. So don't bring up the topic of security in this respect as it is only misleading noobs into believing that there has to be a way to secure their code from viewing by others. There simply isn't! It's at most a complication but can never be security. And reality is that looking at password protected VIs can give you a great feeling about your satisfied curiosity but it can not give you real advantage in knowledge, because anything of what you learn can and often gets changed between LabVIEW versions. So building your skills through that is a very short lived success, with potentially huge liabilities later on. Especially if you boast about it, as that might be the extra drop in the water that causes someone at NI too look at it and find that this is a feature that has lived for too long already in the dark and is not worthwhile to spend more time on, so it gets axed completely. So your boasting only makes the potential benefit from being in the know even less beneficial for the long term. There are hardly 10000ds of password protected VIs in the whole world, so it is quite meaningless if one tool can remove the password from 100 VIs per minute and some other one can do 1000. Finding those 10000 VIs will cost you a multiple of that time in the first place already.

I mostly use the 24xx drivers from NI with some minor tweaking sometimes. Might just as well be based on yours.

They are the better ones. Can be tricky to get them hooked up and working through the serial communication, but that is a problem you have with all serial devices in one way or the other. But once they work they just tend to sit there and keep working until the entire system is dismantled, even if that is 15 years later. I had other experiences with West controllers (not my choice). The client having them in his system has to replace at least one of them every half year not only because it ceases to communicate over its communication link, but often even just starts to malfunction in its core task of controlling the process accurately. That is an expensive cost saving!

The old problem of character encoding when it comes to crossing application borders. Why not create two polymorphic VIs. One specifically doing conversion from the current local to whatever the DB is using as default, and one passing the string entirely unaltered for the case where the user knows his data is already in the right encoding. Even more useful although almost impossible to implement fully would be if you can specify the local encoding and the VI does all the necessary conversion to whatever the db encoding is supposed to be. This is already a nightmare to do, when the db encoding stays constant, but if that can be configured too, then OMG!!!

You are contradicting yourself very much here. First you boost the link to that site, only to disqualify it two posts later boosting about your own version that is so much better. 1000 password protected VIs per minute: Woww! Just wondering where you want to get those 1000 VIs. A real hacker wouldn't boost about it and if you are concerned about security you would inform the manufacturer of the software and hope they fix it, but not posting it all over the place.

I guess the thinking is to not show popups, when being controlled remotely, but only when in local control. But it would seem more logical to make the application generally such that popups are not required, or separate the UI for remote control from the UI for local control,

Well I mentioned meanders before. Can't find an english wikipedia entry so here it goes in German. And then specifically the second line in the big picture.

I think your proposed fix is not a fix but just a change of the bug. With the fix as proposed by you you end up with an index in the range -1 to n-1 instead of 0 to n. So you replace the invalid index at the end of the range with one before the range. The -1 should be better placed after the Array Size function.

Do you configure the CLNs to execute in any thread? At least the MoveBlock is a safe function to call like that, not sure about the sqlite functions of course. And it would seem you are doing the getSize() call in any case to determine if the String contains the entire data? Also try to set the debug level in the MoveBlock() CLN to low. Once that works there is little benefit in debugging in that function call. And of course a C wrapper that does the getSize(), DSNewHdl(), getPtr() and MoveBlock() all in one, won't be possible to be beaten by any LabVIEW diagram function.