C++ basic info for MSFS

[Guest Vorlin]

I feel like an idiot asking this...I know loops and if's, variables and such but what the heck is a pelement header and a pelement list?Rather than hand me an answer, is there any sort of guide that starts with the idea that the reader can already write a console app in C++ but has no clue about graphics, the windows GUI, etc. etc.?That's where I'm at. Rudimentary C++ I understand... but what the heck is a pelement anyway?Vorlin

[WarpD 824]

It is 'typical' in C that a pointer variable start with the obligatory 'p'.. thus pelement is a pointer variable that points to an element. An element is something declared in the gauges.h file.It's really simple... just think of it this way:Everything in C is reduced to either a number or a pointer. All variables lie within that realm, and exactly what you're looking at is interpreted based on that.char a; <-- number, seriously!!!char* a; <-- pointer (to a number)pelement element; <-- pointer to a type of structure called an elementC has no actual 'knowledge' that letters and numbers are physically different to the human mind, it treats them as one and the same when referencing them. You can add numbers to characters and characters to numbers.Pointers are just big ugly numbers that represent a physical address in memory.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.

[Guest Mathias]

Vorlin, as your basic question has been answered far better than I ever could: Have you already downloaded and devoured, ingested and digested Dai Griffith'ssd2gau17.zip? if now go get it NOW!!! :)

[Guest Vorlin]

I have read Dai's work twice now... maybe with twelve or twenty more times through it will begin to digest! lolI understand that pelement headers and pelement lists are pointers to elements that are headers or lists.... what I'm wondering is what is their purpose in a gauge the way that they're being implemented according to the SDK?It seems that they denote the order of things, but they're doing so in a way that isn't exactly intuitive. It may be a good coding practice and counter-intuitive at the same time... just like RPN.I'm just trying to get "the lay of the land".Thanks for any and all insight! The above cleared up what they are exactly... now I'm just trying to get a handle on how they're implemented when it comes to gauges. I may be making it tougher than it is... if they simply order things, as I suspect, why on earth did they change from the sort of master list in a single place that the SDK briefly refers to as being used in the past?Vorlin.

[Guest bartels]

To which pelements do you refer? There are two usages for them. One as a parameter in a callback function, simply a back reference to the drawing element it is used with. If you don't use callback functions (like using <Value> elements without RPN), you don't need them. The other purpose is to be the "glue" between the different draw elements of a gauge, like a needle has to be glued (or attached) to background. Since it is possible to use more then one "child" element the "glue" is realized by these arrays of pelements. In XML the nesting of <Element>'s describe the structure of the instrument, in C you have formally independent elements, which are structured by the pelement arrays between them. And on a final note, the C structure is up-side-down compared to the XML structure. The background is near the bottom of the C-file, the top element near the top.

[Guest Vorlin]

Short version: The glue answer hit the spot. Drawing elements in C are still above my C skill level at this point but I was able to understand your explaination because I understand drawing in XML.Thanks Arne!Vorlin

[Guest bartels]

Once you got the formalism, C and XML aren't so different in their principles. Since the goals are the same (twirl and shift bitmaps around to create the illusion of a real instrument), it is no wonder that the means aren't too much different. XML is somewhat more basic and also more flexible in my opinion (C knows it's MAKE_ macroes, where each does a specific job, XML elements can be simple to complicated with several <Shift>'s,<Select>'s,<Rotate>'s, etc.).

[WarpD 824]

>Once you got the formalism, C and XML aren't so different in>their principles. Since the goals are the same (twirl and>shift bitmaps around to create the illusion of a real>instrument), it is no wonder that the means aren't too much>different. XML is somewhat more basic and also more flexible>in my opinion (C knows it's MAKE_ macroes, where each does a>specific job, XML elements can be simple to complicated with>several 's,'s,'s,>etc.). I personally find XML to be cumbersome in coding design. It intentionally obfuscates what is actually happening. I also find XML gauges rather easy to 'steal'. Not so with C. ;)When you toss in GDI+ rendering, combined with the fact they're much, much harder to steal... C gauges tend to win in my book.

[Guest Vorlin]

"When you toss in GDI+ rendering, combined with the fact they're much, much harder to steal... C gauges tend to win in my book."Absolutely... but you have to have the skills to use those tools. I'm still working on that part!Scott / Vorlin

[n4gix 4,947]

>"When you toss in GDI+ rendering, combined with the fact>they're much, much harder to steal... C gauges tend to win in>my book.">>Absolutely... but you have to have the skills to use those>tools. I'm still working on that part!Well, if it's any comfort at all, consider that I only began a few short years ago myself... ;)

[WarpD 824]

>>"When you toss in GDI+ rendering, combined with the fact>>they're much, much harder to steal... C gauges tend to win>in>>my book.">>>>Absolutely... but you have to have the skills to use those>>tools. I'm still working on that part!>>Well, if it's any comfort at all, consider that I only began a>few short years ago myself... ;)He's still trying to order the skills online... *ducks for cover!*

[n4gix 4,947]

>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+slapI just HAD to do that for the "halibut!" :-lol

[Guest Vorlin]

<-- Raises both eyebrows!b'tch slapped by Father Bill? Rut roh!Well, then again I was warned by someone that he can be a bit "cantankerous" at times! lolOh Bill, Re: the email. I got 16 bit 444 to work as a happy medium... no more CTD's.I actually solved the bus issue due to an archived post of yours from last year. Remember this?***************Title: Re: FSDS2 conditional display and FS9 variablesPost by n4gix on Jan 3rd, 2005, 3:38pm ---------------------------------------------------------------------Actually, in practice, the two techniques are still identical in the end...You see, the _L.bmp is only providing a "light source" behind the gauges, but the actual "light" is supplied by the gauge itself...(etc. etc.)***************Now let's see... the semicolon goes at the beginning of every line in C right?Scott / Vorlin

[Guest iholrf]

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

[n4gix 4,947]

>Well, then again I was warned by someone that he can be a bit>"cantankerous" at times! lolNot at all! CURMUNDGEONLY is the correct adjective! ;)>Oh Bill, Re: the email. I got 16 bit 444 to work as a happy>medium... no more CTD's.Great!>I actually solved the bus issue due to an archived post of>yours from last year. Remember this?>>***************>Title: Re: FSDS2 conditional display and FS9 variables>Post by n4gix on Jan 3rd, 2005, 3:38pm >--------------------------------------------------------------------->Actually, in practice, the two techniques are still identical>in the end...Yep... The easiest way for anyone to visualize this is to consider how an LCD monitor works. Unless there's a "light source" behind the LCD, the screen will remain active, but DARK......by using various shades of gray, along with gradients, etc., one may produce any sort of backlighting effect they desire. ;)