Sign in to follow this  
n4gix

How To program XML to C Interfaces

Recommended Posts

Hi all of you,basing on the work of Andreas Drawe I wrote a bit down to implement FS9-modules with "C:...:..." style interfaces to XML gauges just like e.g. C:fs9gps:.... or C:fsview:view.Arne Bartels

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Shucks, I got all excited because I misread your post...I thought you'd discovered a way to implement some "XML only" functions in C guages......such as loading the terrain map the XML GPS can display... ;(

Share this post


Link to post
Share on other sites

Don't you think this way round is not interesting enough <g>? And please have a bit of patience. The other way round is under development .Arne Bartels

Share this post


Link to post
Share on other sites

Hi Arne,Could this be a way to have variables for strings, the L-var:string doesn't work in xml as you know.Eugen

Share this post


Link to post
Share on other sites

Yes. E.g. C:xmlinterface:stringval of the example module is read/writeable.Arne Bartels

Share this post


Link to post
Share on other sites

Arne,Could you create "Str-Vars" in xml like you do with L-vars or do they need to be declarated in the c-module ?Eugen

Share this post


Link to post
Share on other sites

>Don't you think this way round is not interesting enough>? And please have a bit of patience. The other way>round is under development .Thanks, Arne... If I were into XML gauge coding, yes it would be "interesting enough..." ;)As I am hoping to include the "terrain map" in a GDI+ version of the Garmin G1000 (as well as the Avidyne Entegra Ike Slack is working on), that is of more immediate interest. ;)

Share this post


Link to post
Share on other sites

Unfortunetaely I didn't get it to work properly. Here is a bit of sample code. Usage: add ALL .cpp files, but ONLY CCustomDraw.rc as rc file to a new gauge project. "CCustomDraw!custom" is a C implementation of the GDI drawing in my above mentioned example, it works. No wonder, since I set up the methods "on the other side", so I exactly new which parmaters were needed."CCustomDraw!fs9view" implements the "C:fs9view:view" method. It does work in a way, but the position data relative to the FS window is needed. All I could get was the position relative to the panel bitmap, so there is usually an offset to the view (if the panel bitmap isn't upper left aligned). Note: it isn't GDI, it is a new view window at the gauges place, therefore no combination with GDI is psossible."CCustomDraw!fs9gps" implements "C:fs9gps:Rose", it looks wierd, some parameters aren't fixed yet, but at least it shows up. I wanted to implement C:fs9gps:Map, but didn't succeed (IGaugeCDrawable::Draw alwasy returns FALSE, and nothing shows up). If anyone wants to play with it....Arne Bartels

Share this post


Link to post
Share on other sites

I declared them in C module, that was the point of the exercise.Arne Bartels

Share this post


Link to post
Share on other sites

>I wanted to implement C:fs9gps:Map, but didn't succeed>(IGaugeCDrawable::Draw alwasy returns FALSE, and nothing shows>up). If anyone wants to play with it....>Arne BartelsThanks, Arne. I'll take a close look at this and see if there's any hope for what we'd like to achieve, although it seems already that it will not be possible... ;(We may have to implement "Plan B" whereby we access and display external georeferenced bitmaps, such as is done by FSM Moving Map...

Share this post


Link to post
Share on other sites

Maybe not imporssible, but still something missing. I noticed that C:fs9gps:Map uses some more flags via IGaugeCDrawable::GetFlags(). The other have only TAKES_DC or nothing, but this one also uses NO_TRANSPARENCY and DOUBLE_BUFFER. Maybe the drawing element needs extra info or, I used wrong params in the() Draw call. I abandoned, because I don't really need it and I have other things to do, not that it is impossible!Arne Bartels

Share this post


Link to post
Share on other sites

>I abandoned, because I>don't really need it and I have other things to do, not that>it is impossible!Thanks, Arne. I appreciate immensely the information provided thus far. I'm certain that it will be useful either to me or others... ;)I fully understand the limitations of one's time, as I have already far more on my plate than I can easily handle myself. With no less than five projects being simultaneously developed by ESDG (and being involved in some capacity with four of 'em directly!), I have precious little time available myself! ;)Thanks again!

Share this post


Link to post
Share on other sites

...>As I am hoping to include the "terrain map" in a GDI+ version>of the Garmin G1000 (as well as the Avidyne Entegra Ike Slack>is working on), that is of more immediate interest. ;)>Hi to all of you,it is possible to get the fs9gps working in a C gauge. You'll have to provide your own IGaugeCDrawableCreateParameters and IGaugeCDrawableDrawParameters classes to provide the necessary parameters and link everything together as shown in Arne's examples.In the PANEL_SERVICE_PRE_DRAW event of the gauge callback I use something likeif (timer == 0){ SetupdrawSuccess = pIGCD->SetupDraw(dim_surf, hdc_surf, NULL); GetdrawSuccess = pIGCD->GetDraw(pIGCD_DrawParams);}timer ++;if (timer >= 18){ SET_OFF_SCREEN(pelement_surf); timer = 0;}I don't know if this is the best way but at least it works.I attached a gauge which will show the terrain map and also the AI traffic based on the TrafficInfo.dllhttp://forums.avsim.net/user_files/110228.zipAlexander Drawe

Share this post


Link to post
Share on other sites

>I don't know if this is the best way but at least it works.>I attached a gauge which will show the terrain map and also>the AI traffic based on the TrafficInfo.dll>>http://forums.avsim.net/user_files/110228.zip>>Alexander DraweOutstanding! Would it be possible for you to post the source code for that gauge so I can learn more from it? I'm afraid I'm a bit too "green" to manage on my own... ;)

Share this post


Link to post
Share on other sites

>>Alexander Drawe>>Outstanding! Would it be possible for you to post the source>code for that gauge so I can learn more from it? I'm afraid>I'm a bit too "green" to manage on my own... ;)Better still, please contact me at n4gix@comcast.net as soon as possible.Bill

Share this post


Link to post
Share on other sites

Hi everybody,I need to put a GPS map in a gauge too. Unfortunately I didn't download Alexander's demo gauge before it was removed from the AVSIM server. Would someone be so kind and send me that file to hhartmann at fsfd dot de or just attach it to a new post in this thread (110228.zip was the original file name). Thanks a lot :-)

Share this post


Link to post
Share on other sites

I'm just starting out on getting my head around the SDK to create my own gauges and something has been bothering me from day one.This may be a naive question but if Microsoft has made efforts to allow third-parties to create add-ons for FS2004 by releasing this SDK, how come there is still so much useful functionality hidden away in undocumented dll files? This topic of having a moving terrain map in a .gau C/C++ implemented gauge is a specific example. A terrain map in an XML gauge like the default GPS is obviously relatively easy but why is it such a mystery in a C/C++ gauge? Or how about having the FS2004 flightplanner coloured terrain map shown in a .gau (or even XML) ND type gauge? That way you could use the elevation type terrain colouring for a psuedo TAWS.I'm confused as to why this kind of functionaility is so very well hidden and not covered in the SDK. Is it simply a case of time and effort on the FS2004 SDK authors part that they have't got around to telling us all how to talk to the various dll files that provide so much of the Flight Simulator engine information?It just all seems very inconsistent to me at the moment. Compared to other software titles that allow users to create content using SDK material (Unreal, Half Life etc), Flight Simulator's SDK appears ludicrously limited in scope, despite having the largest and longest-established add-on community. Will this ever change for FS2004 or do we all just have to hope things improve in the next Flight Sim release :)- DE

Share this post


Link to post
Share on other sites

In the case of the fs9gps.dll the answer is simple. MS never intended for anyone to use this .dll for C type gauges or they would have explained how to access it in their SDK.The .dll was programmed to provide GPS functionality for their XML GPS...

Share this post


Link to post
Share on other sites

Then that begs the question what was Microsoft's intention in not providing similar access to the map and terrain drawing functions that are readily available to XML gauges? Large tracts of the FS 2004 SDK documentation is on how to do things in C so it's odd that documenting how to access these functions from that language is absent. Is it that Microsoft intend to drop support of C based gauges altogether in favour of XML? I certainly hope not.I'm not at all convinced XML gauges can provide the kind of performance I want from certain types of instruments. It was a reasonable choice in the case of the default GPS. I believe even real Garmin 530's do not update in 'super-fine, pixel perfect and silky smooth realtime'. For 'performance instrumentation' such as attitude indicators, VSI or high-tech digital 'glass' instruments, fast performance is likely essential.I would also guess that these performance reasons are why you and Ike Slack at Eaglesoft towers are coding that exciting-looking Avidyne system for the Cirrus SR20 project in C - XML just isn't up to it? So quite why, as developers, you are forced down a gnarly path of trying to figure out how to get your C-based Avidyne gauge to show something like the FS terrain map, when it's done so easily in XML, is odd.Can anyone reassure this newbie gauge creator that the time I'm spending learning all this C programming trickery will not be in vain when the next Flight Simulator 200x comes along? Could it simply be a question of the current FS2004 SDK not being totally complete and maybe an updated version will show how to access everything from XML AND C...I certainly hope so :)- DE

Share this post


Link to post
Share on other sites

>I would also guess that these performance reasons are why you>and Ike Slack at Eaglesoft towers are coding that>exciting-looking Avidyne system for the Cirrus SR20 project in>C - XML just isn't up to it? So quite why, as developers, you>are forced down a gnarly path of trying to figure out how to>get your C-based Avidyne gauge to show something like the FS>terrain map, when it's done so easily in XML, is odd.To be perfectly honest, the primary reason for the C, C++ and GDI+ code is one of protecting our investment. There's simply no possible way to keep XML code from being "borrowed" by anyone with access to more than two brain cells and notepad.exe! ;)Well, that and the fact that XML is an "interpreted list of instructions" that must be continuously "re-interpreted and executed," which makes the code slow and cumbersome to run...Now it is certainly a fact that GDI and GDI+ are, relatively speaking, slow in execution as well, but it is likewise true that at the end, even XML "code" is parsed, "translated," then executed using conventional GDI blit techniques. At the end of the process, an XML gauge has simply added yet more overhead processing time and resources to accomplishing the same end result.Since the XML "engine" is wholly dependent on C coded .dll files, I think it is unlikely that MS will completely depecrate the C gauge system in the near future.

Share this post


Link to post
Share on other sites

Bill,You wrote: "XML code from being "borrowed" by anyone with access to more than two brain cells and notepad.exe"Wrong there buddy... It takes 3.. One to keep the heart pumping, One to keep the lungs inhaling, and the other is left for code LOL!! :-)Regards,Roman

Share this post


Link to post
Share on other sites

>Bill,>>You wrote: "XML code from being "borrowed" by anyone with>access to more than two brain cells and notepad.exe">>Wrong there buddy... It takes 3.. One to keep the heart>pumping, One to keep the lungs inhaling, and the other is left>for code LOL!! :-)Ah ha! How could I have been so wrong! Thanks! You are quite correct in that timely correction. *:-*

Share this post


Link to post
Share on other sites

Lol indeed but I would say four are needed. Three for the already mentioned functions and one extra to contain a 'sense of humour'. Essential for those dark hours when your code is not doing what you blasted well want it to. Maybe even a fifth cell for motor functions to enable you to reach for that slice of pizza and the essential bottle of Dr Pepper. Gotta have sustenance to keep your limited supply of brain cells alive after all :)- Darren

Share this post


Link to post
Share on other sites

FS development does present challenges at every turn. A quick look thru any freeware or payware project shows that no developer that we are aware of has been able to implement the base and terrain maps from the default GPS in C/GDI+.We do have a primitive working base/terrain map in C/GDI+ but it is totally unreliable at this point.The fact that no one that we are aware of has overcome this challenge speaks to the difficulty involved:-)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this