hooovahh

I messaged Michael.

I don't think XNodes would help with this. XNodes are great for making a single thing on the block diagram do different things and encapsulate functionality in it. But there is no front panel connection with an XNode. The best you could do is maybe make an XNode, that internally links to a control reference on the FP. You'd still have the normal control terminal on the block diagram because I don't know of a way to make the control terminal itself invisible. If I could then then that would be a solution, but likely full of hacks and who knows if it actually would work well. And then you'd be dealing with a technology NI isn't interested in making more public. If QControls did have an XNode component, and it could essentially replace the native terminals and references, then I'd suspect NI would be less interested in making it part of the LabVIEW core. One nice thing about QControls today is how it is normal pure G, which as you mentioned might be why it has a hope for being ported to NXG.

Okay to be fair, QControls don't actually extend the VI Server tree, but from a developers perspective the outcome is the same, or close enough to not matter. You drop a property node, and you get get access to all the same things you're used to, and the new things. It looks like a duck, but might not be a duck. I can see why code changes in one place effecting the other can be weird, and for that I can think of a few ideas that are probably terrible. I haven't used them extensively yet, just working on a few ideas, but since it solves so many of my XControl problems, and adds just a couple problems of its self, I'm okay with it. I too wouldn't be surprised if NI doesn't invest in XControls, or an alternative. But then again for current LabVIEW I didn't expect that to get any better anyway.

You are incorrect they do and it is amazing. Here is a slider that I made into a QControl and I have all the normal slider stuff, but then have the extra stuff I added. It isn't perfect, like you can see the "Scale" normally opens up another submenu but in this case it just returns a reference, but with this you can then do the same stuff. Or you can just reference the original control instead of this class and do things exactly like you always have but you won't have the new items.

I just started down the rabbit hole of making a new XControl recently. Oh man such a pain. Here is a little graph I made complaining about the XControl creation process, and the time needed to make something useful. Any alternative is appreciated.

No. For the transparent-ness I customized the control in the control editor, moved the cells a little to reveal the back which was a shade of grey. I colored it transparent, then moved the cells back to where they were, then painted the white cells transparent. For the glyphs, if you have an INI key you get a right click menu on MCLB that is you Enable Glyphs In All Cells, I think the INI is EnableSecretPopups=True. Then you can enable it for any MCLB, and I think tree. It also gives other menus like having parts of a button move or grow with a button as it is resized.

Attached is an updated one with classic and modern MCLB, transparent cells, and glyphs in all cells. MCLB Symbols In All Columns Transparent.vi

Here is a Classic MCLB which can have its cells be transparent, and have symbols in all columns. System controls can't be colored, and the modern one I couldn't get to be transparent. It might be possible but the classic was easy. MCLB Symbols In All Columns Transparent.vi

Why is this a problem? So I make a VIPC with all packages I want in it cause I have pro. I double click this file, pick my LabVIEW version, a prompt then comes up for licensing and I accept all and then it installs all the packages. If you don't have pro you can still go to File >> Open Package File(s), select all the packages, then click Add and Install Packages, and have the same process. It isn't a "one click" install but after the install starts installing the first package you can walk away and come back after all the rest are done. I also have a package for editing LabVIEW.ini functions, editing QuickDrop, adding Right-Click, adding Tools Menu items, adding Help documentation (found in the Help menu in LabVIEW), etc. One thing I haven't done yet but I bet you could do, is make a package that calls into the NIPM API and installs NI run-times or toolkits as needed. It really depends on the amount of effort you want to put into it but I bet you could automate a lot of the process. Still I don't find it takes all day to setup a machine so I'm not sure I'd go through the trouble. The NI Web Install is already pretty good where you select the NI products, and NI drivers to install at the start and then it installs them without having to prompt again. For me all that is then needed after this is to install the VIPC I mentioned earlier.

Yeah this is neat and useful...how much of this black magic is built into LabVIEW and how much did you develop?

Oh come on it was there in 2009...but I can't remember if there were functions or just shortcut support. In either case in that thread I linked, I provided a way of invoking it through the Tools menu since most of the good shortcuts have been taken.

2018 SP1 F3. Edit: I think I might be getting it, I didn't set the owner properly.

Wait, also how do we copy these? I used the invoke node Move, with Duplicate set to True, but the object it creates has a 2px size not 0px.

Oh I just thought of something that might help. Here is a splitter manager utility which helps with panes and splitters. It can be invoked with QuickDrop and then can do things like set the color, position, and sizing behavior of panes.

Here is a small and borderless picture frame, along with smaller array. https://forums.ni.com/t5/LabVIEW/One-pixel-frame-for-picture-control/m-p/3716581#M1046089

If Flarn does have a truly borderless cluster, then that means there is no edge to click on. A while ago AQ posted a cluster with only one pixel on the top, and one pixel on the left in size. With this cluster if you selected it by drawing the region as you suggested, then you still wouldn't be able to right click a border on the right or bottom because there wasn't one. Sorry I do not know a way to invoke the right click menu, without right clicking it.

Okay so I don't fully know if this is what you are dealing with but I think this has to do with the State Diagram Editor. NI had a toolkit called the State Diagram Editor back in the 7.x era. It was a toolkit which had a graphical UI for making states and defining what made states go where. It had a single ExternalNode for assisting in the code which determined what state it should go to. It wasn't completely required but did make life easier for the most part. NI later saw the value in this type of editor and made a new toolkit the State Chart Module which had some similar functionality but wasn't quite the same. Well after years of complaining (from Ben primarily) NI decided to release the State Diagram Editor. I thought they replaced the ExternalNode with a VIM but now that I look at it that doesn't seem to be the case. You can find the State Diagram Editor on the Tools Network installed through VIPM. Then you can drop down a new state machine and edit it either in the image control (and the code will be updated) of you can edit the code and the image will be updated. Still there are a few things I don't like about it like type defing those enums causes problems and I think crashing.

If you searched for a long time I assume you found the TSXperts demo here which shows using an Arduino in LabVIEW, on a Pi.

Seriously Monnie? Get your act together. Let that be a lesson to us all not to be a Monnie. (I don't actually know a Monnie, and have never heard of this term before but I love it)

Well in playing around with the control I crashed LabVIEW so I'd say this was something that shouldn't be messed with, but pretty neat and something I didn't know existed.

Yeah something like that. The password replacement code I think is still posted online in PHP. I wrote the G equivalent and posted the read-only parts online. It has some pretty useful thing like being able to read information about a VI without VI Server. At one point I was able to figure out what objects are on the front panel and block diagram by looking at the raw VI file. Of course doing this means you don't get the satisfaction of knowing what the password was.

I doubt there is any documentation beyond the help included with installing the OpenG packages. If you open the context help on any VI it should show a description of the VI and what it does and how to use it. This isn't always enough documentation on understanding how a thing works, but the source code is fully there too, so understanding it should be possible if the documentation provided isn't sufficient. The OpenG website itself went into disrepair and had spammers taking it over so OpenG discussions were moved here to LAVA.

Yeah I used to have a list of the passwords I had reversed but I can't find it at the moment. I think there was something about Looking Glass , Jack Black, Jabber Wocky, Axes Of Eval, FP Rocks, and a few others that were random characters and harder to remember. I (probably like you) wrote code to go over the most common word lists for words of 5 characters or more, and for 1-4 I just brute forced all combinations, then after that used a program to reverse MD5s using your GPU. It was slow, painful and each new version of LabVIEW added more and removed some. I bet with the advent of new graphics cards this process could be made easier. There is a method in LabVIEW to add known passwords to a cache, and then not prompt if they have been entered so I thought it would be a neat VI to just run which would make looking at all NI VIs easier rather than writing code to replace and remove the passwords thereby changing the VI which I don't like. Maybe we could make that VI, and then password protect it?

I've done this in the past by leveraging the PictureBox .NET component and VLC. Just have VLC installed which is the same bitness as LabVIEW. Drop a .NET PictureBox and then use some of the code found here, which calls into the VLC DLLs to open a stream and display it. Here is another example that I think works too.

Yup State Machines. They aren't the solution to all things but do worlds to organizing your code and for readability. You can create one single BFC (large cluster) that is in a shift register with the things you want to read and write to like variables. Except you know where these variables are being read and written to, and you have state order to ensure one thing happens after another. Once your code gets so large that a state machine can't help you, you should learn about actor based software designs. Not necessarily NI's Actor Framework but actors in general. Independent parallel running loops that do dedicated tasks. This helps modularize your software so all the File IO stuff is handled in one place, and all your DAQ stuff is handled in another, and all your UI stuff is in another. Breaking up larger problems into smaller more manageable ones is something LabVIEW is good at.