Darin

Maybe because I'm looking for work. A current skills are important.

I would suggest that your posts here demonstrate more about your character than your LV skills. I am sure a lot of employers would love to hire someone who not only explicitly violates their EULA, but is sure to broadcast that fact to others as well. Figuring it out yourself may have had some redeeming quality, but you simply borrowed someone else's tool to do the work. As to learning anything useful digging through locked vi.lib VIs, my sense is that NI has a lot more to learn from us than we do from them.

By all means poke around under the hood, we all enjoy it. Just don't think that boasting about it around here is going to impress anyone and enhance your job opportunities.

I'd seen, and been intrigued by, Structure and Interpretation of Computer Programs at MIT OpenCourseWare before. Do any of you have any experience with this book/course? Scheme would be an interesting language to learn, and it would help me with Emacs/LISP.

I took that class when one of the authors of the book was teaching it. It will certainly teach you Scheme, an interesting if n

I'd seen, and been intrigued by, Structure and Interpretation of Computer Programs at MIT OpenCourseWare before. Do any of you have any experience with this book/course? Scheme would be an interesting language to learn, and it would help me with Emacs/LISP.

I took that class when one of the authors of the book was teaching it. It will certainly teach you Scheme, an interesting if not useful exercise. It explains why I missed recursion in LV2. You should take it so one more person gets the joke when I say sh#t-bang.

Funky semi-double post from iPhone, no idea how to edit.

As a CS prof once said: To become a good programmer you need to write code every day for two years. To become a great programmer you need to write code every day for ten years OR write code every day for two years and take an algorithms class.

There are a variety of formats supported by PNG, my version of the PNG suite contains 157 different files. The File-based VIs will handle 154 of the 157 files. The string-based one will handle 59 of the 157. Clearly NI has written/licensed a nearly compliant PNG reader, why it is not using the same one in both cases is beyond me.

I was annoyed when I first saw the string based VIs hidden deep in the palettes (having written my own). After some quick testing the crappiness (technical term) was soon apparent so I was glad to have made the effort. The simple .NET solution may be an option for you if you are on a Windoze machine.

My experience has been that the string based PNG VIs can not handle 32-bit images (ie. containing alpha info). The file based VIs are more robust, but still do not handle transparency very well. I have rolled my own PNG VIs, but simply writing the string to a temporary file then reading it is usually sufficient.

I do not remember if it was Gauges, but I remember a similar situation where I was able to change the display via a Property Node that I could not through the Property Dialog. Try Right-Clicking the digital display and Create Property Node -> Display Format -> Format. Pull down to get the Precision property in the same node. Set Format to '0' and Precision to whatever you want.

Did you use a color for the FP that does not appear elsewhere? Using a white or gray could cause some issues.

Follow the example here to use the Windows API to set a transparent color in a FP window.

http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-04-17-2006/m-p/352929#M179807

OpenG candidate?

I tend to view OpenG functions as tidy little timesavers, this is more of a tool so I am not sure if it is a total match. But, I definitely want it to be shared in the same spirit.

That is very nice! Which ISO version did you use? ISO/IEC 18004:2000 or ISO/IEC 18004:2006? Because I if you google good you can find the first one as a .pdf on the web. The second you can't (or well maybe... but then your google skills are better then mine )

Most of the info came from Wikipedia (did not require many google skills for that), and it claims to be 2006. My guess is that the limit subset of features I have implelemented are compatible with the 2006 standard, but my no means is it "up to spec". Of course seeing the spec would be required for that, and that costs $$$.

I have added a thread on the Code in Development Board for those interested:

Already added a few more comments, and fixed one "bug" (more of a cheat) where I was using a mask to fix the bits when encoding the error correction. I changed the EC ring to not have sequential values, now the values correspond to the binary value of the encodings and it is clear that the mask is the one from the spec. (You should not have to worry about this "stuff" to use it, but of course the values L,M,Q,H would never correspond to 0,1,2,3 in the spec).

Since you are open for a .NET solution I am guessing the Windows API solution would also be ok. Combine Ton's example with tst/Yair's example here:

http://forums.ni.com.../352929#M179807

Create a VI with a white background and a green object (2D picture with transparent frame for example) with the desired size (10 px height). Windows will remove the remaining white area from the FP and leave a semi-transparent green bar. Here it is on my Win7 machine:

Dragging is a bit finicky with Ton's example, I may play with it a bit. I have had similar issues trying to fake a title bar in a window.

Yes, but did you make that with LabVIEW?

Shaun is correct, 100% pure G. Not up to spec, no Kanji, no mixed mode messages, just a simple encoder I have used many times to label objects around the lab. Chokes in a few corner cases when I approach the data limit of a particular version, but all levels of EC work.

(I am not trying just to be a tease, but there is a bit of cleanup left to do since I kind of stopped once it was working. I can probably help with the problems in your code though).

I've done most of the implementation for supporting QR codes, but I'm having a lot of trouble generating the error correction codes. There are four error correction levels (L, M, Q, and H). 100% of my tested QR codes have the correct error correction for Q and H. About 50% of M codes have the correct error correction codes, and none of the L codes have the correct error correction data. I can't figure out what's wrong with it. Does anyone have experience with generating QR codes?

Feedback Nodes have amazing potential that NI needs to unleash. The first step is to get this excellent idea implemented.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/An-output-terminal-for-feedback-nodes-that-mirrors-the/idi-p/927458

This would solve this problem (the need to handle the last iteration as a special case), and also eliminate the need to wire the output of the FN through all frames of a Case Structure.

I have been lured many times by the siren song of the feedback node in this instance, so close, so very close, yet in the end, denied!

I like using them to build up dictionaries using variant attributes. Nice tight loop from variant out to variant in. Of course this is only after LV10 when they fixed an annoying bug which affected the combination of variants and feedback nodes (like they went out of their way to target two of my favorite things).

If it keeps you up at night you could use the Mouse Down? filter event, but I also think that both events are handled before the short menu activiation. Furthermore, I have found that in situations like this the behavior is at least consistent, meaning that it either works or it doesn't. It sounds like it worked, so if it were me I would not worry that much about it.

You can dig it up through the Example finder, or here:

..\National Instruments\LabVIEW xxxx\examples\general\strings.llb\Extract Numbers.vi

To get the effect you show in the picture, simply remove both FSS and replace with one big one. I doubt you want that, you probably want to merge the two. In this case I would simply align the two individual structures side-by-side, functionally the same with a lot less pain. Stacked sequences would be a bad idea.

If it ain't broke, don't fix it. If it is broke, start over. You seem to be headed down the path of most work for least return.

Or, as I suggested in the Idea Exchange, simply color your Front Panel black.

I can not test, but I would actually use a positive look-ahead instead of the capture group.

Try this:

(foo[\s\S]*?)(?=foo|\z)

Of course if you append the checksum to the string and run it through the same code you'll see it's purpose. To save the trouble in this case you only have to figure out what x XOR x is.

These controls need a defer update method of their own IMHO.

I think there is a LVIE idea for this.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-Defer-Updates-an-Object-Property-as-well-as-a-Panel/idi-p/1292100