taguilo

>OK guys, sorry about this, I don't want to argue endlessly.>I don't know why my code does NOT work when I use the ident>100, and it WORKS when I use 20000... But the most important>is that it works, and that everyone is happy.>>Eric>Eric, MINIPANEL has an ident of 20000 as you've noticed, and I'll try to explain why this works as it does: First, there isn't an exact define for MINIPANEL in gauges.h panel #defines, because MINIPANEL is a special keywork only recognized by FS panel interpreter, and has not direct relationship with the standard gauges.h defines. The W key is associated with a "change view" mode that cycles between main panel (MAIN PANEL); its derivatives ..PANEL_ALT1 to ..PANEL_ALT9; MINIPANEL and main panel off (invisible); all of them related to main 2d panel view. Alternative panels 1 to 9 won't cycle if not defined in panel.cfg, but MINIPANEL will always cycle. You can define your own MINIPANEL window and add as many gauges as you wish, even leave it with no gauges. If you don't define any, a default configuration is taken from minipanel.cfg located in Gauges folder, and depends on aircraft/engine type. Specific gauges are loaded from Minipanel.cab located in the same folder.MINIPANEL has the particularity that is not displayed as a selectable option of Instrument Panels in View menu.If you use an ID of 100 (IDENT_MINI_CONTROLS_PANEL), the window will be treated as a regular popup window and NOT as a MINIPANEL reference.Hope this makes sense and helps a bit :-)Tom

I understand the default path is that in where the calling gauge /dll is located. Then for example, if it is located in Panel, you should do "../aircraft.cfg", if in the same directory, "aircraft.cfg" directly; and for example in a subdirectory, just "./subdirectory/file"The idea is "etc" for direct path reference, "../etc/" for up indirection and "./etc/" for down indirectionTomEDIT: etc for down indirection and "./etc/" for up indirection I guess :-)

Hi Bill,Did you try?:CHAR totalpathname[MAX_PATH] ="D:FS9AircraftEaglesoft Liberty XL2aircraft.cfg";I always use in path names, but for std file io, haven't tested GetPrivateProfileName yet...Tom

>for example, if modelling an RB-211 engine, I would>need to create N3 'out of nothing' because FS does not>provide an N3 parameter.>>-Dai>Actually on that engine type N3 is the same spool as N2 in FS, so is this last one who needs to be recreated "out of nothing" :-)Tom

>>As for execute_calculator_code... all depends... your>statement is not 100% correct. All depends on the way the>custom var is treated inside the module itself. The GPS>doesn't behave well... in my opinion. ;)Actually my statement was for using execute_calculator_code directly like the same as to retrieve AVars. I agree the behavior could be different depending on how the custom module is designed. In fact, XML gauges that instantiate Custom classes do instantiate gps copies as well using execute_calculator_code calls from inside the dll.Anyway, in our C gauge example there is no real need to apply this function being so simple to replace it by property calls.Tom

>>>I can not reveal specific code as what we've done is>proprietary in nature. I can simply tell you that>IGaugeCCallBack is most definitely useable as is.>>If you're not understanding why I repeatedly say that all you>need is to use IGaugeCCallback... I strongly suggest you read>up on class objects and inheritance. You are missing the most>basic concept of object-oriented programming.Well, thank you Ed, not for the lack of support but for insisting me to look into IGaugeCCallbak. That was the key, you were right and I solved the problem with a bunch of code lines. I must add that the initial key is to register IPanelCCallback with "fs9gps". The rest is very simple. No need to construct another class or so, at least for basic approach. I'm glad that you were wrong and I'm not missing basic concepts at all :-)TomPS: As I stated before, execute_calculator_code cannot be used to retrieve custom vars.

>>>>>Yes Bill I know, but those are for traffic info, and of>course>>not the same used in the gps class. For these ones we would>>need the base class with virtual functions to retrieve gps>>specific properties. I know people close to ACE team must>have>>a copy of this header...;) >>>>Tom>>>>Nope. There is no fancy header required.>>You can utilize the base class and use the methods contained>in that class to read/write what data you require. This works>for the traffic as well as the GPS.Good. Can you give me then a near example, or at least a prototype on how to retrieve the value of "FlightPlanIsActiveFlightPlan" using an IGaugeCCallBack class method? I REALLY hope you can......Tom

>>It is in the FS9 SDK. Here is the .h file though, along with>the .doc 'spaining it's usage.>>For FS9 usage, you also need to place the TrafficInfo.dll in>the Modules folder.>>For FSX, ACES has supplied a new fs-traffic.dll in the FSX>root folder which apparently has the same interface inside,>but a new name... ;)>>Yes Bill I know, but those are for traffic info, and of course not the same used in the gps class. For these ones we would need the base class with virtual functions to retrieve gps specific properties. I know people close to ACE team must have a copy of this header...;) Tom

Yes, of course, but IGaugeCCallback is the abstract class, you can't do anything with it but contruct a derivated class and insert there the local functions that would retrieve gps properties (ie FlightPlanIsActiveFlightPlan, etc). To acomplish this you need a header of the gps class containing those functions as virtual.Tom

>>It may well be that the simplest method would be to use the>IGaugeCCallback as described in the TrafficInfo.doc file in>the FS9 SDK...Yeah, I guess that would the simplest way, building a derivated class from fs9gps and retrieving data with ConvertStringToProperty,ConvertPropertyToString or Query. The problem is I don't have a header for the base class :-( Maybe you know somebody who has a copy ?...:-cool Tom

>>Um, yes... some of the Avidyne's data is retrieved that way.>Of course, I cannot share the actual code, but I can certainly>attest that the method does work!Well, I have serious doubts that there are calls to execute_calculator_code and fs9gps classes in the way we are discussing here -always speaking of .gau/dll gauges, NOT common dlls-In fact, I've found that not even custom classes (C: ) created by myself work, which tends to make me think this function cannot instantiate classes just by parsing their names on the stack. Notice that the stack is cleaned up after each call, meaning it doesn't work by gauge basis but instead by function basis, which gives a logical reason for this behavior.Unless there is someone that can post or comment a way to overcome with this limitation, I would have to stand on my reasons...but will keep testing indeed!Tom

You're right Ed, in this case he should make the code a bit different to work, because the return to NearestAirport is asyncronius.Tom

>>>>PCSTRINGZ lat_icao;>>PCSTRINGZ lon_icao;>>PCSTRINGZ airport_icao;>>Er, lat_icao and lon_icao should be float vars since they are>in degrees... :)>>FLOAT64 lat_icao = 0 ;>FLOAT64 lon_icao = 0 ;>PCSTRINGZ airport_icao;Bill, try to not confuse Russell more than he is by now :-)...take a look again and you'll see that his code is right...Tom

Bill, did you ever try calling a gps value from a .gau/dll gauge?I mean, any kind of execute_calculator_code("(C:fs9gps:etc)",etc) ?I've read so many times this should work, but I couldn't suceed in retrieving even the most basic FlightPlanIsActiveFlightPlan...I must be doing something very wrong then. Would like to see a working example on this too!Tom

>>Any chance of someone posting a bit of working code showing>how to set and get variables from the gps ? I have done a>search, and there are few who have had this problem, but>unfortunately none of them have ever post a soluition :-(Seems it's not possible to retrieve fs9gps class values from a classic .gau/dll gauge, probably because of instantiation issues.I've been able to work with those vars only when called within a custom DLL preloaded through DLL.XML.Anyway, more tests would be necessary to clear all doubts.Tom

>>But the order in which they>>are placed in a gauge is irrelevant, should work fine with>>any. >>Of course. However, I'm a firm believer in 'following the>established recipie' whenever possible, since if nothing>else...>>...it is proven to work! ;)Yeah, I second that. However, I also like to know when there are other options to choose from in different situations.>>It's hard enough as it is having to deal with four very>different XML schemas. I will be SO glad when FSvNext>introduces a more unified approach via LUA... :-lol Bill, I think you've been playing too much with XML...do like me, stick to C++ and everything will go pefect! :-lol :-lol :-lolTom

Bill, if that was the situation, of course it will never work. is one of the basics tags together with , and . None of these can contain any of the others within its own structure. But the order in which they are placed in a gauge is irrelevant, should work fine with any. Tom

Hey Rob, The idea of keeping a transparent panel with Event gauges always visible seems pretty neat. Fortunately I can code that C gauge by myself, being this an easy solution, but actually I am trying to go a bit farther just by placing the Event trapper on a custom DLL and see whether it can be recognized across the entire panelset. Currently I'm in a struggle to make the DLL register the trapper function, with no sucess so far :-(Tom

Rob, unfortunately doesn't work in SP2 as you describe.The must be defined in a gauge that is included within the current panel mode -2D or 3D- AND visible. If you put it on VC, only works in that mode; vice versa for 2D and no way to make it work in VIEW modes or external. A partial solution is to make Event trapping only gauges and place them duplicated in both panel modes...I am near to do some tests using a custom DLL to see what happens there.Tom

Hi,As Rob stated, there is no difference in the order Elements, Mouse Areas and Keys sections are placed within a gauge, which seems logical as tags are interpreted by theirs names only.Unfortunately, the off-view trapping issue has not been solved in SP2 :-(Tom

You could use an approach similar to this:l1 @1 == if{ (L:MyVar:@1,unit) sp3 }@AInd(0) @AInd(1) @AInd(2) @AInd(3) ... @AInd(n) ....%(0 sp1) // s1-l1 is the index %{loop}%( @Array ) %(l3)%!d! // l3 is the value returned by the array%(l1 ++ s1 l2 < )%{next}You may use the : after the name of each Lvar like:(L:MyVar:0,unit)(L:MyVar:1,unit)etcor this method directly:(L:MyVar0,unit)(L:MyVar1,unit)in this case the macro expression is (L:MyVar@1,unit)Should work fine for a limited number of array members (10-20)Tom

LVars don't support string assignments ie if you something like this:'test' (>L:MyVar,string) the content of L:MyVar will be 0.Only CustomVars (C: type) support strings, providing you enable string properties on your custom C++ DLL.Tom

Paul, I still don't get you very well on what you want to do, and what means to you "a list of values or numbers", but I guess what you need is to print the value of each var in a single line, one beside the other, and then scroll the entire line?Something like this, maybe?%(0 sp1) // s1-l1 is the index %{loop}%( @ArrayOfValues ) // Is an array that retrieves the proper var according to l1 index passed and put in , ie, s3%(l3)%!d! // l3 is the value returned by the array%(l1 ++ s1 l2 < )%{next}Tom

Hi Paul, could you be a little more explicit? Tom

Dai, KEY_REQUEST_FUEL is used to require a fuel truck; to fill the tanks there is another event KEY_ADD_FUEL_QUANTITY (these names are the C version, to use them in execute_calculator code you must write their XML version)This event supports a passed value of 0 (no fuel) to 65535 (max fuel); if invoked with no passing value adds a 25% of fuel by default. The major drawback is you can't control which tanks are going to be filled, as the event applies to all of them in once. And like Bill's stated, you can use SimConnect from within your own dll; though it's a bit of tricky to handle the asyncronious flow of data.Tom