typedef struct ENG

[n4gix 4,947]

How would one use the variables directly from this struct within a gauge? I've never noticed this before, and now I'm curious... ;)typedef struct ENG{ SINT16 throttle_lvr_pos; // throttle position (0-16384=>0-100%throttle position) UINT16 propeller_lvr_pos; // propeller lever position (0-16384=>0-100%prop setting) UINT16 mixture_lvr_pos; // mixture position (0-16384=>0-100%mixture position) ENUM16 starter; // starter switch position BOOL16 combustion; // combustion flag (combustion = TRUE) UINT16 n1_rpm; // gas producer RPM (0-16384=>0-100%RPM)

[Guest darrenecm]

Hi Bill.Isn't that just a struct definition and not an instance? I assume, given an instance of it, you could access the members just like any other struct. So if you had an instance declared earlier such as:ENG myEngine;You would read the member values using standard dot operator notation as below:cout :)Also, to be thorough and risking stating the obvious, if you need to access a struct and it's members when you have a pointer to the struct you use a different notation as below:cout << myEngine->throttle_lvr_pos;cout << myEngine->combustion; // etc...I've noted a lot of 'pointers' and 'pointers to pointers' variable declarations in the majority of the gauge SDK header file, so the above may well be pertinent when accessing structs directly when using pointers.Hope this answers your question. If not feel free to poke me in the eye and tell me I've missed your point entirely ;)- Darren

[n4gix 4,947]

Actually Darren, that particular struct is part of the fs9gauges.h file from the SDK (although the SDK names it gauges.h).I'm simply curious what the purpose of the struct is, and whether it might provide a more straightforward way to access the contents of the struct's members... ;)

[Guest darrenecm]

Hi Bill.I'm finding that the SDK header files are extremely cluttered with user-defined types like this. In the case of this struct, the typename ENG is obviously given to the struct so that it totally encapsulates and models an engine and it's attributes under one data type. I would guess this particular struct models a turbo-prop engine. To use the data in this struct directly though you should be looking for the objects that are instantiated using this struct template. I imagine that they're deeper within the gauges header code.What's more likely however is that you'll probably never see this struct used in C code because of the problem of the SDK relying far too heavily on pre-processor directives and macros. As you know, macros and pre-processor 'magic' actually expands into plain C code prior to being compiled. So essentially the macros of the SDK gauge programming commands are writing your C code that then uses all those user-defined data types. To get around this and find out how it's being used so you can plan a way to access it directly, you might want to use the 'Generate Preprocessed File' compiler switch for your compiler. This often-overlooked feature tells the compiler to create a text file containing the 'intermediate' C code that the macros produce prior to compilation. You can then browse through it to see how everything is being called and used in plain C syntax. I believe you have Visual Studio .NET, so to check how the macros are expanding into normal C code, do the following:* Select Project Properties* Select Preprocessor from the C/C++ section* Change 'Generate Preprocessed File" to use line numbers if you want line numbers* Change 'Keep Comments' to Yes.Here's a screenshot (I hope) of the appropriate VS.NET dialogue box:http://forums.avsim.net/user_files/120294.jpgI find the 'Keep Comments' feature useful because the preprocessed file can be quite large and often has lots of white space for no apparent reason. You can then search the large preprocessed file for the comments that mark the start of your gauge source code that the macros have produced.Another way that helps me in my attempts to fathom out what all this macro malarkey is doing is to make sure I add the gauges.h or fs9gauges.h header file into my project under Header files. This means that all the data structures, enums, functions etc in the header file are listed under the Class View tab. This further helps me figure out what is what and how it's constructed. If you get compilation errors when you do this, simply right click on the offending header file and set"Excluded From Build" to Yes.I better stop here before I bore everyone to tears but I'll end by saying that this heavy use of the pre-processor to program gauges is irritating for me. It's a meta-language that is creating C code for you and simply acts as a confusing layer, adding unecessary complexity to what's going on under the hood. I hope the next implementation of Flight Simulator makes a move away from this heavy pre-processor magic and more into the object-oriented realm.God I can waffle can't I? I think I'll go lie down for a bit :)- Darren

[n4gix 4,947]

Thank you Darren, for the very enlightening and informative dissertation. I appreciate your "waffling," and did not find it one bit tedious.Until I began coding gauges for FS, I enjoyed a long hiatus from programming, so my experience ended with that period in history when programmers still - well programmed! - meaning, of course, that flowcharts were the order of the day, and the highest level language would be either Fortran or COBOL, with an occasional RPG routine being called to produce nicely formatted output... ;) Most of the "serious programming" was still done at the assembly level though.

[Guest darrenecm]

Hi Bill.Ah assembly language. I was only ever exposed to that level of programming during the Motorola 6502 days with my trusty Atari 400, and only then as a hobby. I think that's why I never had a problem understanding pointers when I started learning C and C++ recently. Pointers are much the same as the indirect addressing modes in 6502 assembly :)As for your original thread topic on directly using structures like that mentioned, I do feel it's essential to put the macro programming method of the Panel SDK to one side and dissect what native C or C++ code it's actually producing. Once someone gets a total grip on how FS200x interfaces and talks to the gauge DLLs (and vice versa) I believe undocumented functions and other neat access tricks may be revealed. Tricks that may allow us to easily and reliably implement features like moving terrain maps for 'Navigation Display' style digital gauges, extracting elevation and other terrain data from the BGL files for cool Terrain Avoidance Warning graphic displays and more. Maybe even finding a way to get a DirectX/OpenGL drawing surface for accelerated 2D graphics (maybe even 3D) in a gauge window could be possible?I just wish my knowledge of C/C++ and the Panel SDK was at a level where I could tackle this dissection myself. I'm struggling self-teaching myself C/C++ from dry technical books at the moment, never mind the complexities of various API