Delphi and SimConnect

[Guest Jacky Brouze]

Oups ... said something wrong ... DeletedA+Jacky

[Guest scotthendry]

Hi All:As promised, here's my version of what Dick has kindly provided. The callback works and also I have it responding to windows messages sent by simconnect. It has been tested with Delphi 7As always, your comments and suggestions (+ve and -ve) are welcome.http://forums.avsim.net/user_files/165044.zipBTW: Dick, how did you create SimConnect.res?

[Guest KenAdam]

Scott,I think I got most of the double/single, DWORD/LongInt issues sorted out (though I was left with one "unsigned long" where I'm still puzzled as to why it is declared as that)I didn't like the header construct much, but I don't like repeating the fields explictly everywhere either (the C version embeds then without having to get all the declarations the same). I'm still thinking about how I want to do this.It seemed to me that the "header" portion was only likely to be refernced before you established which type of record you had, and once you (re-)mapped the correct type you would be unlikely to access it again. In that case it would not matter that these (essentially spaceholders) were in a subrecord.You'll note, as pointed out by Jacky in an e-mail, that some of the "header" elements have the wrong type - I'd missed that some are derived from the "event" variant.I'm not sure which of the enumerated types you are referring to - the parameters are defined as DWORD, and I pass Ord(Enum) - I did this to keep the example as close to the SDK version as I could.In practice for real software I'd probably just pass a named constant. (Though the enumerated type trick does enure that the values in any group are unique).Hopefully we can eventually get one version of "SimConnect.Pas" that we can all agree on.My short term aim was to get FS X driving a real aircraft Digital Map/Situation Awareness display ready for a demonstration and I got that far today (having only received FSX on Wednesday). Getting the initial version from Jacky gave me a good start.Netx week I want to try and convert more of the Examples (in my "spare" time" to verify more of the headers (and provide a starting point for others).I'm not sure my current version is "fit for human consumption", but it seemed better to get it out soon and encourage feedback/cooperation.Ken

[Guest scotthendry]

Ken:Sorry, I didn't mean to imply that YOUR version wasn't "fit for human consumption" only mine. I tend to be a very messy programmer. As for the enums passed, again sorry 'bout the implication, I didn't actually see that in your code but was passing it along as (**Siren sounds***) Warning to all and sundry as the original C++ header uses enums extensively, and I thought I could save somebody some grief somewhere along the line.I agree with your sentiments about dereferencing the header elements once only, but I still think it's better to have the repeating fields for code readability (just an opinion). I tried to emulate what the C code does by declaring the structures as classes, but came a gutser on that as the dwSize field got swallowed somewhere by Delphi. Jacky has a nice demo program that illustrates what happens.

[rhumbaflappy 113]

Hi Ken.Yes, you're on the right track, I believe. A single version of SimConnect.pas would be great. Between you, Scott and Jacky, I think that could be done. Experimentation is going to be the key, as some elements of SimConnect may not be exactly what the SDK proclaims. If you read some of the SimConnect C++ and FSUIPC posts in various forums, you'll see what I mean. Pete Dawson ( FSUIPC )is the best source for info here. Even though he doesn't deal with Delphi ( or C++ ), he knows the Simconnect structure better than anyone outside the Aces team.Dick

[Guest KenAdam]

I didn't take your reply to say there was a problem with mine - I was saying that I think there is!Quite a few things still need to be sorted out, and I hope that getting more of the examples to work will highlight that.The problem will be keeping track of what doesn't actaully work as advertised in the C version, so as to avoid tryiong to fix it in the Delphi version.Ken

[Guest scotthendry]

Ken & Jacky:If Ken hasn't already accomplished testing the examples, I propose:(a) Using Jacky's header as the "standard" as Jacky has a very clean and readable programming style(:( We divide the examples between the three of us to test and report back on any problems and proposed fixes/workarounds.Comments? Suggestions?Dick, I specifically did not include you in this, as you expressed a preference in an earlier posting, not to be involved further with Delphi. On a personal note, I cannot thank you enough for getting this thing started as I for one would not have known how to do what you did regards the manifest file.

[Guest KenAdam]

I've noted that it is possible to use a variant record to cover all these related types (only two fields need to be renamed to prevent duplicate names).This means that the received paramater can be of this (Pointer) type and then no re-casting or extra indirection is required.The downside is that the nested "case"s within the variant mean you'd have to look at the orignal non-variant equivalent to work out which fields are valid for each type!I've added this type to my version, but I'm not certain that I'll use it.Ken

[Guest KenAdam]

Scott,I'm reluctant to do this, since there are many types in Jacky's version (at least the last one I've seen) which need to be corrected, which I have already done in my copy (of Jacky's version).Also I've added Delhi-style T.. and P.. equivalents which I prefer (and Jacky doesn't)I always format all of my files using DelForExp, which has a "Borland" setting that enforces the Borland submission standard code layout. I have long since given up debating on whether one coding style standard is better or worse than another (I used to be Chief Software Engineer for an Aerospace company, and it always amazed me how many "religious wars" this topic could kick off!)I do find things much more readable when everything conforms to the same standard though. Personally, I find the style of the original SimConnect.pas less readable, simply because it is different.From what Jacky has said (in e-mail) I think he is too busy with his own schedule to do work on the examples (and converting them probably doesn't help what he is trying to achieve).I intend to work on those examples that directly help my project first (Tagged Data was most critical for me) before hopefully moving on to the remainder as time permits.The examples that are next on my list (in no particular order) are:AI Objects and WaypointsAI TrafficClient EventRequest DataSet DataTracking ErrorsHTH,KenP.S. Did you get an explanation of how the manifest file came to be?

[Guest KenAdam]

Jacky,Firstly, no need to apologise for your English - it is fine!1.1) Fine - probably rules out the (cumbersome) variant structure method I experimented with.1.2) Having both is what I intend/want too.1.3) I don't feel strongly about the "header" either way. The variant record that I've created meets your objective (and mine of not repeating the same declaration) but is pretty unreadable due to the number of nested cases required, needs two field name changes and conflicts with 1.1 above. Pity there is no "clean" solution for supporting inheritance in records. I have yet to find an example where I need to refer to a subfield of the header, so it makes no difference to my code either way. In my latest version, I've done a global replace of the "header" with a commented block declaration, that cross-refers back to where the declaration comes from for clarity.2) I never write in C or C++, and avoid them whenever I can - but this has resulted in me translating a lot of source code to Delphi so that I can develop it further. I'm therefore comfortable with doing more of the examples.I'll post the latest version, with another couple of converted examples soon.Ken(Who can't type for toffee, and always forgets to check for mis-types until after hitting Submit...)

[rhumbaflappy 113]

Hi Ken and Scott.Here's a good explaination of the manifest resource file:http://delphi.about.com/library/bluc/text/uc111601a.htmThe Simconnect manifest itself is found in:"C:WINDOWSWinSxSManifests"Mine is named:x86_Microsoft.FlightSimulator.SimConnect_67c7c14424d61b5b_10.0.60905.0_x-ww_429211e9.ManifestWhew!I made a copy of it and renamed it to my Delphi project folder as "SimConnect.exe.manifest"I then made an RC file named "Simconnect.rc"

1 24  "SimConnect.exe.manifest"

And compiled it as a RES file using the Borland tool described in the article.Should simconnect versions change, the original SidexSide version should still work with our programs. That's the point of SxS versions.Should we wish to make code with the NEW versions of SimConnect, we'd need to make a new RES file, and a new Simconnect.pas, for each version. But no need for that if your code works fine with the old version, as it should still run. In this way, it should be possible for many programs and DLLs to work simultaneously with different versions of SimConnect.I think this RES compilation method can allow you to use WindowsXP SP2 buttons, and the like, that are not normally part of Delphi or C++ Builder programs. Just find the manifests, make an RC file, and compile the RES.Dick

[Guest KenAdam]

Dick,Thanks for that - I had seen the refernce to the side by side folder, but not yet had time to follow it up.I notice that the manifest includes "10.0.60905.0" which is the FS X version/build (whereas Simconnect is 2.0.60905.0).I wonder if this means it will break with any updates to FS X, and not just to SimConnect.Regards,Ken

[Guest scotthendry]

Hi guys:Proposal #2 If we are to create a single Delphi entry point to SimConnect, and I think it's VITAL that we do, we WILL have to come to agreement on some things. In view of your preferences, I propose:(a) That we use the naming conventions as in the original SDK for the reasons Jacky stated.(:( That we use the formatting that Ken prefers for the reasons he stated. I don't want to start another "religious war" "W" has one too many going on just now!© Regards the recurring fields in the records, that we swallow our pride and just repeat the fields in the records. It's not particularly elegant BUT the coding for it will be straightforward, it won't come back and bite us in the bum later on and given that Ken has included the commented fields there anyway, why not just remove the {braces} and "let 'em go".(d) Jacky's wrappers, I think they are a good idea, but can they be kept in a separate file for clarity? The T and P types could be incorporated there as that would be the "Delphi Side" of the package whereas SimConnect_x would be the "interface side".Ken, thanks for the explanation of the manifest file. I don't really understand how it works, but will look up the link you gave after I finish this post.Now I'd like to return to the point of the importance of getting a single version and getting it out there by illustrating what happened to me with FS9. Someone a long time ago did a set of Delphi files to get entry to the SDK for an earlier version of FS. By the time I went looking for the files, they were gone I mean NOWHERE to be found all the links were dead. I would have killed for those files. We are the doorway for the Delphi programmers who don't know enough to replicate what we have contributed to get this stuff going. We can't let this fizzle because we don't like this formatting, that naming convention or those repeated fields. Finally, I propose: If you are happy with this, post your versions of the Simconnect_x file here when you are happy with them, I will put them together and write the example files and test them and post a single version on my website. I will then put links to the files on as many forums and sim sites as I can find.

[Guest Jacky Brouze]

Bonjour les amis ;-)>I don't want to start another "religious war" "W" has one too many >going on just now!MAKE ".PAS", NOT WAR !!! ;-)>c) Regards the recurring fields in the records, that we>swallow our pride and just repeat the fields in the records.>It's not particularly elegant BUT the coding for it will be>straightforwardYessssss !>d) Jacky's wrappers, I think they are a good idea, but can>they be kept in a separate file for clarity? Yes, of course they will ! The SimConnect.pas file won't change anymore (as soon as we get agreed), but my object will ...It is already packed as a separate unit which just uses SimConnect.pas>The T and P types could be incorporated there as that would be >the "Delphi Side" of the package whereas SimConnect_x would be >the "interface side".Not agreed, they could easily be in the SimConnect.pas as they won't change in the future and are totally "transparent" to whom doesn't use them ! They are just equivalences.A+Jacky______________________________Jacky BrouzeEleveur d'octets :-)Sorry for my poor fr-english ... ;-(

[Guest scotthendry]

>Bonjour les amis ;-)G'Day back at ya mate :-)>>The T and P types could be incorporated there as that would>be >>the "Delphi Side" of the package whereas SimConnect_x would>be >>the "interface side".>>Not agreed, they could easily be in the SimConnect.pas as they>won't change in the future and are totally "transparent" to>whom doesn't use them ! They are just equivalences.>>A+>JackyMaybe a misunderstanding here but, I think if we are to keep SimConnect.pas declarations consistent with the original then(a) We should not use T type names in the file (p types would be OK though)(:( If a T type declaration is not needed to resolve a symbol in SimConnect.pas, it should not be in that file and if it is needed to resolve a symbol, it should be renamed to be consistent with the original .h file where possible.© I think that if you are declaring additional types for your wrappers, they should be placed in a separate include file so that the base SimConnect and your wrappers are easily separable(d) Finally, for simplicity, we should keep the declarations in SimConnect as close to 1:1 equivalence with SimConnect.h as the translations and ease of coding will allow "Simplicate and add lightness"