| Beatle's's profileBeatle's BlogPhotosBlogLists | Help |
ACES Studio team member blogs
Blogs/WebSites of past ACES team members
Flight Sim MVPs
Links to Flight Sim related Web Sites
|
Beatle's BlogJune 30 Function OverloadsHey All, In the C++ native client’s documentation, some of the function descriptions list default values for some of the function parameters. In C++, this means you can use a shortened form of the API function and the default values will be used. While .Net/C# doesn’t currently support default parameter values, it does support function overloading, and I have used that ability in the new Managed SimConnect Client library to provide overloaded functional equivalents for the C++ shortened forms (I’ve used the same default values as listed in the C++ docs, so you can reference those for API specific defaults). So when working in Visual Studio, pay attention to the IntelliSense popups, as they will list all the available overloaded versions. I’ve also added a few “specialized” extra functions for dealing directly with the User Sim Object (basically, these functions don’t take a dwObjectID value, they internally use the constant that specifies you want to talk to the user):
The parameter list for these APIs is equivalent to their non-User specific versions, except the dwObjectID param isn’t included in the list. Another variety of overload I’ve used is to accept different types of data to the same API call. The Text function uses this ability to provide a version of the function that takes a regular string (same as the C++ version) and also a version of the function that takes an array of strings (this version useful with the SIMCONNECT_TEXT_TYPE.MENU flag so you don’t have to embed nul chars(‘\0’) in your string.
A couple of samples The MapInputEventToClientEvent function is a good example. It’s full blown version contains 7 function parameters, but the function is valid with as little as the first 3 parameters defined. In the original managed wrapper, you would always need to enter all 7 parameters like this: sc.MapInputEventToClientEvent(Groups.GroupID, “shift+a”, Events.ShiftA, 0, SIMCONNECT_UNUSED, 0, false); but with the new client library, you can use the shortened form: sc.MapInputEventToClientEvent(Groups.GroupID, “shift+a”, Events.ShiftA);
The Text function can be used to display both scrolling/paging text across the top of the FSX/ESP display and to display a 1 up to 10 selection dialog. With the original managed wrapper, you would have to define the string for a selection dialog something like this: string strSelectionDlg1 = “Dialog Title\0Selection Prompt:\0Selection 1\0Selection2\0Selection3\0\0”; but with the new client library having an overload that takes a string array, you can define that same selection dialog this way: string[] strSelectionDlg1 = { “Dialog Title”, which is much easier to read.
Stay tuned for more If you notice any overloads missing or just want to suggest some additional overloads, drop a line in the SimConnect forum on FSDeveloper.com. And keep an eye here on the blog for additional info on the new Managed Client Library.
Tim “Beatle” Gregson June 24 Initializing and Connecting[This is the first in a small series of posts covering some of the new/different parts of the client library compared to the version in the official SDK. In this first installment we’ll cover Initializing and Connecting.] I don’t use the SimConnect.cfg file with its index based selection of a set of connection parameters; for one, that just flat out wouldn’t work for a Silverlight application, and there are several other environments where that doesn’t work well. So instead, I just take the server information directly via the Open() function. You application is free to use whatever method it wants to query/store this information. Here's some prelim docs for the constructor, open, and close functions. Constructor (Desktop version of client) new SimConnect(object syncObject, bool bSerializePackets); Where syncObject
bSerializePackets
Constructor (SilverLight version of client) new SimConnect(object syncObject); Where syncObject
Open function (Desktop version of client) Open a local connection using the default named pipe void Open(string strAppName); Where strAppName
Open a TCP/IP connection (IPv4 or IPv6) void Open(string strAppName, string strHostName, Int32 iPort, Boolean bIsIPV6); Where strAppName
strHostName
iPort
bIsIPV6
Open a TCP/IP connection (IPv4 only) void Open(string strAppName, string strHostName, Int32 iPort); Where strAppName
strHostName
iPort
Open a named pipe connection void Open(string strAppName, string strHostName, string strPipeName); Where strAppName
strHostName
strPipe
Open function (SilverLight version of client) Open a TCP/IP connection (IPv4 only) void Open(string strAppName, string strHostName, Int32 iPort); Where strAppName
strHostName
iPort
Close a connection void Close(); June 22 Announcing a new Managed SimConnect Client SDKHey All, Today I’m releasing the first public beta of my new Managed SimConnect Client SDK. This SDK can be used to build managed SimConnect clients, both desktop (Console, WinForm, WPF) and web (Silverlight). For the impatient, here’s the download link:
And here’s a more nicely formatted version of the ReadMe file included in the download: Welcome to Beta 1 Enclosed is the SDK for the Beatle's Blog Managed SimConnect client library. This SDK can be used to build both Desktop clients (Console, WinForm, & WPF) and SilverLight clients. The client libraries included are built using the Any CPU setting, so you should use this setting in your own projects, unless some other requirement of your client needs a different setting. The client libraries included are written in 100% managed code with no dependencies on any existing libraries/DLLs/etc (except for a minimal number of .Net FrameWork libraries). Benefits of new client library:
A note on Silverlight Support The SilverLight runtime imposes several restrictions on socket communications. SilverLight applications can only open a port in the range 4502 through 4534, so you will need to modify your SimConnect.XML file to open one or more IPv4 ports in this range. Here is a sample SimConnect.XML file: <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="SimConnect" version="1,0"> <!-- Global (remote) IPv4 Server Configuration (SilverLight compatible) --> </SimBase.Document> Another restriction is that in order to make a cross-domain connection (which would be any SimConnect connection), the machine you are trying to connect to (the machine that Flight Simulator/ESP is running on) must be running a Silverlight Policy File server on port 943. See the Samples section below for a simple Policy File server that fills this requirement.
Client Library Files
Solution Files
Basic Sample List (those in SamplesBasic.sln)
Enhanced Sample List (those only in Samples.sln)
Documentation At the moment, the documentation consist of this readme file and the sample projects included in this SDK. Please keep an eye on my blog for future posts related to the new client library. Please use the FSDeveloper SimConnect forum for questions, suggestions, and bug reports. Wow, look at all the cobwebs in here<cough/><cough/> Yes, it’s been quite awhile since I last posted, sorry about that. Quick catch up, Aces got shut down and for the time being, I’m still employed at Microsoft. Just a quick post for now to blow out the cobwebs (and make sure Live Writer is setup correctly). I should have some more interesting posts in the next few days. <cough/><cough/> Tim “Beatle” Gregson July 21 In-Process DLL SimConnect Client SampleHey All, In my last blog post, I mentioned we had a new download area with some new samples and that I had a couple of samples that needed some minor cleaning up and then they would be posted there. Well one of those has been posted there, the In-Process DLL SimConnect Client sample (actually, it was posted almost 2 months ago, I'm just now getting around to blogging about it :-> ). I wrote this sample because I noticed we didn't have any in-proc DLL samples in the SDK. First off, what does that mean, In-Process? It means that the DLL SimConnect client is loaded within the ESP/FSX process space instead of within its own process space like an external .EXE based SimConnect client. This has some good points and some bad points (depending on what you are trying to do). The good points are that you register a callback function once, right after the SimConnect_Open call, and that callback will get called directly by the Server Side SimConnect code when messages are available for your client. This bypasses all of the networking layer (ie no TCP/IP, no Named Pipes, you get a direct function call into your code from the Sim side code). This also means you don't have to run your own HWND based message pump, you don't need to use a background thread with an Event Handle, you don't need to use a timer based query scheme, etc - in other words, it makes life much easier. The bad points are that you can't really do standard windows based UI this way - well, you can but its not guaranteed to work (DirectX and GDI get into fights with each other sometimes, especially in full screen mode) unless you put the Sim into Dialog Mode first. You can still add menu items, use the SimConnect_Text function to display both scrolling text and simple "select one of the below" style dialog boxes. Another bad point, in some folks eyes anyway, is you can only use C++ to write an In-Proc DLL client. Also, since your client is running within the ESP/FSX process space, if your client code goes nuts (causes a fault of some sort, or goes into an infinite loop) you can take down the entire Sim. So, if you want to write a client with lots of UI and/or you want to use managed code, stick with an out-of-proc EXE style client, but if you can live within the above restrictions, then an in-proc DLL style client may be the way to go. Things that would make a good in-proc DLL style client:
What the sample does The sample is fairly simple in what it does. It adds a couple of menu items to the AddOn menu (Show Weather Menu and Show Time Menu). Selecting one of these menu items will use SimConnect_Text to show a "Select on of these options" dialogs, the weather dialog allows you to query the dialog from either the current location or from SeaTac, the time dialog lets you set the time to either 12:00 Local or 00:00 Zulu. Selecting one of the weather reporting options will query for the Metar string at the requested location, and then use SimConnect_Text to display the Metar string as a scrolling message across the top of the screen. Selecting one of the time set options will, surprisingly enough, set the time accordingly :-> Hopefully a few of you will find the sample useful. If you do, or you have any questions about it, drop by the Microsoft ESP Forum to discuss it/ask questions. Tim "Beatle" Gregson |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|