Leaderboard

I came across this thread: http://lavag.org/top...qr-code-or-not/ and decided to dust off my old QR code generator, clean it up and see if it would be useful. I had no access to the formal spec-sheet, my info came from a combination of wikipedia, textbooks on Golais fields (fun stuff), and a lot of reverse engineering. As I remember things I am trying to actually document the code this time around. QR Generator_v2.llb

HI, Today, this ADD-ON for LabVIEW has been added to LabVIEW TOOLS NETWORK! see http://sine.ni.com/nips/cds/view/p/lang/en/nid/210605

There are 2 types of ActiveX controls: windowed and windowless. Windowed controls create their own OS window and completely handle drawing inside of that window. Windowless controls get messaged by their containing window when it is their turn to draw. Guess which kind the media player is. In order to draw anything on top of it, we would need to create a partially transparent window on top of it. You could do something with a second VI that is set to be partially transparent and positioned over the media player.

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. 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).

no No NO! Having code span more than the available screen resolution isn't inherently bad, and anyone who tells you so is a fundamentalist1 itchin' for a fight I don't have any problems with code that scrolls in one axis (ie: left/right OR up/down), and it's often impractical to code some architectures without doing this (eg: FPGA, ActiveX or any other property-/method-based work, some UI designs). It's when you need to scroll in more than one axis that I get cranky. PS: I love having 2 monitors: one for FP, the other for BD - awesome when you're debugging. 1. Each to their own. I don't have a problem if anyone feels the need to have their code fit on one 640x480 screen, but I prefer to be practical, which means my time is more valuable working on things useful to the world than crusading (often only if with themselves) for something like this.