LOLYer not old enough yet for curmudgeonly.

>LOL>>Yer not old enough yet for curmudgeonly.Actually, he is.No one really knows this... but he was the 13th disciple of Christ. Never mentioned in the Bible because of that fateful mistake of convincing ******* to wear shorts one day. Talk about Middle Eastern fashion faux paux!!!(ya know I lubs ya Bill! ;) )

>>>>Then only difference in all of this is the name. In other>>words, whatever name is given a variable is the best 'clue'>as>>to what the variable represents to the developer.>>Wow, I appreciate how difficult it is to break down a complex>issue and make it so even I can understand it. I applaud you.>>If I may add: And effective and verbose in-line commenting>will save your butt many a time (not to mention being>bookmarkable/highlightable in most IDE's/editors).>>Cheers>ShadI learned many years ago that 'professional' knowledge is simply knowing the 'secrets' to a job. Most of the time those 'secrets' are extremely simple in reality, yet obfuscated by professional lingo to confuse the mere 'commoner'. ;)

>>He's still trying to order the skills online... *ducks for>>cover!*>>*SMACK!* >>You've just been b'tch slapped with a halibut!>>http://video.google.com/videoplay?docid=-2...494&q=fish+slap>>I just HAD to do that for the "halibut!" :-lol Well... looks like fish for dinner!!! :D

>>>>Then only difference in all of this is the name. In other>>words, whatever name is given a variable is the best 'clue'>as>>to what the variable represents to the developer.>>Wow, I appreciate how difficult it is to break down a complex>issue and make it so even I can understand it. I applaud you.>>If I may add: And effective and verbose in-line commenting>will save your butt many a time (not to mention being>bookmarkable/highlightable in most IDE's/editors).>>Cheers>ShadSo very true.If only the original gauges.h SDK file followed such sensible advice on using 'in-line' comments. I find myself regularly delving deep into the gauges.h file in order to figure out how to get at the data I need and to get my gauge DLL to 'produce' code How *I* see fit rather than how all those obscure macros see fit :)Thanks to the sterling work of Arne Bartels, Dai Griffiths and others on the fs9gauges.h alternative header file, things are bit more fathomable, but there are still large tracts of 'commentless' and cryptic parts of the header file in evidence because that's how it was originally written.Comments cost nothing in terms of program execution so I'm not sure why anyone writing code that is plainly going to be seen and used by others should not be sufficiently documented by comments.For example, I'm pouring through lots of OpenGL sample code from all over the Internet in order to get my own OpenGL drawing tricks within a gauge to the level where hardware acceleration can be easily utilised. As such, my C/C++ files are awash with green-hued slashes and explanatory text wherever I'm using concepts I've derived from these sources. As Shad points out, such verbose commentary will always save your own butt when you find yourself returning to your code at a later date to update it with new tricks.One thing I like about Visual Studio 2005 IDE is that if you mark sections of your code using a comment like the following://TODO Need to optimise this blitcopy routinethe IDE notices the TODO text and places that comment line in a helpful Task list section for you to refer to and finish off at a later date. Double clicking on the Task entries in the listing will then whiz you right on over to that section of your code so you can make your edits. I'm not sure if this same feature is in the Visual Studio .NET 2003 IDE but I find it invaluable in keeping track of my code development.That blitcopy reference reminds me. I've read posts in other forums about blitcopying sometimes being required during drawing gauges, particularly those who are bypassing the use of clunky rotating bitmaps and are insstead drawing directly to a gauge surface.I find all the C++ and GDI/GDI+ memory blitcopy routines somewhat inefficient because they all do their copying on a byte-by-byte basis. Modern CPUs are at their fastest and most efficient when dealing with 32-bits (some even 64-bits), not bytes.So I'm wondering if it's not better to 'roll your own' blitcopy routine. This would involve the use of pointers with one pointing at the start of your image source in memory and the other pointing at the destination surface. You then start copying the data from one to the other using a loop that copies entire 32-bit chunks rather than bytes as you increment the pointers.You do have to be comfortable with using 'pointer arithmetic' techniques as you increment these pointers in the loop, but it's not as bad as it sounds :)