Delphi and SimConnect

[Guest KenAdam]

Scott,I agree with Jacky - putting the T.. and P.. versions in is consistent with the Borland and JEDI approaches to API conversion.(they keep the original too (as I've done and Jacky prefers) so that anyone who wants to use the C-style has access to them).Regarding the "header", I wasn't clear enough :( ; I meant that I had added the declarations instead of the header, but with a bounding comment (top and tail) to show where they came from. (I also added {SIMCONNECT_RECV_EVENT} after "record" to follow the C style of presentation and imply inheritance).Header is gone, late, no more, ceased to be etc if you get the dead parrot picture. This made no difference to the example code or my app.I was planning to create a website to put it all on (have space but not using it right now), but if you have something already set up, that's fine.Perhaps I can replicate it later.I've got the Set Data & Request Data examples working now along with Tagged Data - I'll build a zip of the whole thing and post it soon.(I've been developing my app in the same directory tree, which was a bad idea, so I need to split it all out.)Set Data is interesting since it responds to a FS X key press (and means that a couple of other examples are redundant, but very quick to do).I'm creating the examples the way I prefer to have them - as Windows apps with both the poll and message driven versions. This means they are more complex than the originals, but more representative of the sort of App I'd be creating (and perhaps others).Do you think that there also needs to be a Console version that only does the polling method?Regards,Ken

[Guest KenAdam]

Here are the first 6 examples, all of which are working with the latest SimConnectKA.pas - name chosen to not conflict with any other version you may have, and not due to ego ;-)The examples are Tagged Data, Request Data, Set Data, Input Event, Client Event and Open&Close (just to keep it similar to the rest).To keep the file size down, I've removed the exe and dcu - please let me know if you have any trouble rebuilding them. I use BDS 2006, and I have add-ons like the JVCL and JVCS installed. Hopefully nothing in that stops this building with other versions.Jacky - yes I know about that method, but I don't like the long names it produces. I prefer to be able to format the names any way I want. I've already moved those names along with the ugly variant record into SimconnectSupport.pas which everyone else can ignore.Let me know if you spot any problems (too much cut and paste makes you blind to the obvious)Kenhttp://forums.avsim.net/user_files/165282.zip

[Guest scotthendry]

Ken:>Regarding the "header", I wasn't clear enough :( ; I meant>that I had added the declarations instead of the header, but>with a bounding comment (top and tail) to show where they came>from. (I also added {SIMCONNECT_RECV_EVENT} after "record" to>follow the C style of presentation and imply inheritance).>Header is gone, late, no more, ceased to be etc if you get the>dead parrot picture. This made no difference to the example>code or my app.Looking at your code I see the misunderstanding we've had. What you've done is what I was asking for; that the repeated fields be included in the records, not "headered", not commented out etc.>I was planning to create a website to put it all on (have>space but not using it right now), but if you have something>already set up, that's fine.>Perhaps I can replicate it later.If you are going to be the main developer, and going to publish the files on your site then I won't publish them on mine. There should be only one set of files for consistent source control.>I'm creating the examples the way I prefer to have them - as>Windows apps with both the poll and message driven versions.I agree this is a good idea. I always thought that the command line examples were a bit lame, but I guess they cater for the lowest common denominator in compilers.>This means they are more complex than the originals, but more>representative of the sort of App I'd be creating (and perhaps>others).>Do you think that there also needs to be a Console version>that only does the polling method?Yes to provide for LCD compilers as stated earlier.I still don't like the T and P types in the file as they add a lot of "noise" to the code and make it harder for "newbies" to get a grip on how it works. Please remember that you're not just coding for software engineers.

[Guest Jacky Brouze]

Hi Scott and Ken> I still don't like the T and P types in the file as they add a lot > of "noise" to the code and make it harder for "newbies" to get a > grip on how it works. Please remember that you're not just coding > for software engineers.No, but as they are a kind of a "standard" in Pascal, I suppose that the programmer who is going to put an eye into this kind of file will be able to understand those constructs ... else he would better not try to interact with FSX because he will probably get some other problems ... ;-)Actually, I have no more objections about Ken's file.A+Jacky

[Guest KenAdam]

Scott,I don't know about "main developer"...I don't have a website set up at all at the moment (on the to do list..) and it may be quite a while before I get time.If you already have the space/template etc, it would make sense to post the work there rather than wait for me to get a "round tuit".I'll mirror it later (makes sense to have more than one copy as you mentioned earlier).I don't know if/when I'll get around to the console versions (since I never develop such things).Are you willing/able to produce these?I think that newbies are probably more familiar with the T and P approaches since that is what they see for most of the Borland converted types. Anyone who only reads the SDK info and not the actual PAS file will never know about them.While a manual for the pascal version would be useful, I'm not sure whether it would run foul of MS copyright issues (since it would need to repeat a lot of their info)- is there any reference info on this from other projects? I guess there shjold be some copyright statement at the top of the source file referencing their rights?Ken.(currently converting the AI examples as light relief from writing Web Mapping Service access software...)

[Guest KenAdam]

Jacky,I've been thinking about your (e-mail) suggestion to make the callback type to be "of object".While this makes it simpler to use the method of a form and avoids the wrapper in the application, it makes it unusable in a console application.Of course we could add both as overloaded versions, but the method version is not part of the original MS.I'm not sure which way to go on this.Any one got some opinions to add? Ken.

[Guest KenAdam]

Jacky,Declaring the two types is OK, but when I try to overload the funciton definition, BDS objects to the line which links it to the DLL complaining that "function must have a result type" (even with no actual overloaded function).Looks like I need to add a different API function (SimConnect_CallDispatchMethod?) and then map it to the same DLL entry using "name".Ken

[Guest KenAdam]

Jacky,To do this we can build a separate version of the SimConnect interface which loads the SimConnect DLL at runtime, and raises an exception or returns an error (for the user program to handle) if it fails (i.e. when SimConect.dll does not exist). I've done this before to implement plug-ins and to handle DLLs which may not have all the entry points (different versions of OpenGL for example)I'd probably prefer this solution anyway, so I'll make the changes in SimConnect.pas - but perhaps we also need to keep the straightforward translation too?Regards,Ken

[Guest KenAdam]

Jacky, and anyone else interested,I now have a version of the SimConnect interface working with run-time dynamic loading of the dll.The "trick" is that there is an "optional" attribute that you can apply in the manifest that will allow the app to load so that you can make the LoadLibrary call and get a status back. Without the "optional" it fails at load time, even though you are using run-time dyanmic linking.Ken