Leaderboard

Somewhere in my harddrive is buried a library which scans the opcodes of a picture and applies translation, scaling and rotation. The text rotation and scaling and bitmap operations are a bit involved, and I never bothered to deal with rotating greyed out rects, (other rects are converted to polylines). It is kind of cool, but I would probably not get too close to "real" code with it since it is deep into hack country. What it also did was delay me from doing what I really should have done earlier, implement a real OOP drawing library. Implement a few basic shapes (start with the LV Picture primitives), and a group or collection object. Each object gets an origin, angle and scale and methods to translate, rotate and scale. Now instead of blue squiggly wires everywhere you get (blue in my case) class wires everywhere. And then you can reach nirvana, retire the LV picture functions altogether. The render method of the objects can be overridden to be LV Picture, SVG, eps, Canvas, .NET, whatever. Once you see a few anti-aliased lines, circles and text you will never want to go back. IE (easiest browser for ActiveX integration) is closing the gap with the better browsers on handling HTML5 and SVG, it simply unleashes a whole new world. Rotated text caused problems last time I tried with IE so it is not all systems go quite yet. But it is getting close. Of course, it not only has to be fixed in the browser, but fixed for long enough that it becomes reasonable to require users to update. But I digress, you probably need to get to point b from point a so Norm will likely be posting an opcode parser in the not too distant future. I'd post mine, but the bitmap and rotation handling bloats it considerably and the fact it comes from LV3 or 4 makes for interesting reading. [it says a little about LV3/4 and a little about how I programmed when I was using LV3/4 (not to mention it started as a hack).]

Here are the latest GDS builds http://goop.endevo.net/GDS/GDS_4.7(R1U)_2010.zip http://goop.endevo.net/GDS/GDS_4.7(R1U)_2010-64.zip http://goop.endevo.net/GDS/GDS_4.7(R1U)_2011.zip http://goop.endevo.net/GDS/GDS_4.7(R1U)_2011-64.zip http://goop.endevo.net/GDS/GDS_4.7(R1U)_2012.zip http://goop.endevo.net/GDS/GDS_4.7(R1U)_2012-64.zip http://goop.endevo.net/GDS/GDS_4.7(R1U)_2013.zip http://goop.endevo.net/GDS/GDS_4.7(R1U)_2013-64.zip If these pass the testing, we'll rename them and release them as GDS 4.7 Cheers, Mike

You're going to have to understand C pointers if you ever want this to work. The concept is simple: a pointer is a integer that contains a memory address. In a struct, a pointer takes up only the amount of space necessary to store that integer. You then need to allocate space somewhere else, initialize it with some value, and update the pointer to point at it. The size of the struct remains the same regardless of whether it contains a pointer to an empty string, or a pointer to a really long string, because the struct itself contains only the pointer. This should answer your question about whether you need to include the string lengths in calculating the buffer size.