timcrews

Pete: Thank you for your response. I would like to "officially" request a WideClient.ini option to specify the window class names, as you originally suggested. You have persuaded me that this capability will not be useful to the general public, so I would use the different class names in my own private SDK modifications to support multiple instances of WideClient on on machine. Would the changed window class names have any negative effects on other interfaces/applications, as you alluded to with the changed window title proposal? Would your startup check against multiple WideClient instances be defeated, without causing additional problems in that code block? Thanks again, Tim Crews GECO, Inc.

Pete: In my previous message I did propose modifying the call to FindWindowEx in the SDK FSUIPC_Open function, so that it would find the specific desired instances of WideClient. These instances would be distinguished by their window title (not window class). I thought this would be a clever approach, because currently NULL is specified as the window title, and this acts as a wild card. This opens up the possibility of making a backwards-compatible change that allows more specific behavior without affecting the previous "wild-card" behavior. As for the changes to my (as yet non-existent) applications, it would be a simple matter to add the desired window title to the argument list for FSUIPC_Open. If this were C++ code, I could even go so far as to provide a NULL default value for the desired window title argument, which would result in the "old" behavior of matching the window only by its window class name, without any changes to existing application code. But if the caller of FSUIPC_Open provided a window title argument, then this title could be used to differentiate between multiple WideClient instances. I do not intend to waste your time by repeating questions. In this case, my "would it be technically feasible" question was meant as a polite introduction to a more detailed technical proposal. I'm sorry I appeared to not be paying attention. You did say it would be possible to add an option to WideClient.ini to specify the desired window class. But you began that paragraph with "If you are writing your own applications and you don't want to interface to FS itself." I certainly _do_ want to interface to FS. The approach I am proposing involves your described change to WideClient.ini (actually, a slight modification to your described change), _and_ my application interfacing to FS itself. I could create my own private SDK version, and I am willing to do so if necessary, but I was starting to feel hopeful that there was a way to accomplish the desired functionality by an enhancement to the existing SDK, without breaking the interface that current applications use, as more specifically described at the top of this message (but a better approach is proposed below). I agree that two incompatible versions of the same interface would be problematic. I haven't written any applications yet, so whatever I do write can conform to any crazy SDK interface I come up with. Since these applications are private, I could have private applications interfacing to a private SDK version, and this would be workable and should not cause any harm to the outside world. But if we use window title instead of window class to differentiate between multiple instances, then I still think there is a possibility of preserving the existing interface, so that it would not be necessary to recompile existing applications or patch binaries. I see that this does preclude my proposed approach of an extra argument to FSUIPC_Open, with a default value. So I suppose I would have to create a new function, FSUIPC_WindowTitle or something like that. If nobody every calls FSUIPIC_WindowTitle, the window title used by the FindWindowEx call in FSUIPC_Open will be NULL (wild card). But if someone calls FSUIPC_WindowTitle with a specific title, that specific title will be used in the FindWindowEx call. Yes, you're right. That one slipped out. I meant to say WideClient. AHHHH! Now _that_ makes this whole discussion a moot point. That's a show-stopper, that is. If the rest of this message ends up being sufficiently persuasive, what are the prospects for a configurable option to turn off this behavior? Minus the previous show-stopper issue, I think what I am proposing only affects the SDK and applications, not WideClient, if I use a helper application to change the WideClient window title. And I think there is hope that it could affect only the SDK, and not applications. But I guess the previous show-stopper issue definitely implies a change to WideClient. And it would probably be easier and more user-friendly to provide a WindowTitle argument to WideClient.ini than it would be to write an application that changes the window title. I'm not even totally sure it is possible to change window titles after the fact. I'm about 80% sure. :? The window-title-changing application was a grasp at a straw, trying to come up with a proposal that would allow me to accomplish what I needed without requiring you to make any WideClient changes at all. But if we can come up with a backward-compatible approach, I hope you will consider making the small changes we have discussed, hopefully with some benefit to the user community, see immediately below. If there is a way to get this to work without breaking the existing SDK interface, do you see any advantage to making this functionality available in the public version? This would not be a competing/incompatible SDK, but an SDK that is backward compatible with the current interface, but also allows for multiple WideClient instances. Again, it does seem to me that there might be a general audience for this capability, beyond my specific application. Do my previous explanations in this response answer this question now? Applications that want to talk to multiple specific instances would use a new function, e.g. FSUIPC_WindowTitle or whatever we want to call it, to specificy non-NULL window titles to connect to. So yes, applications that want to talk to multiple instances of WideClient will need to be slightly modified and re-built, as you have noted. But other applications could continue to operate as they currently do. I would not consider releasing the new SDK into the same domain as the old SDK unless the new SDK was backwards compatible. If there is no backward compatibility, then the danger and confusion would be more than it was worth. Pete, I really do appreciate the time you are spending considering my hairbrain proposal. I hope that my persistence is not annoying you. It's my job. I have to accomplish this goal one way or another. Seriously, I would probably be directed to implement an alternative to WideFS if this discussion falls apart. That's why I'm being so tenacious. Thank you, Tim Crews GECO, Inc.

Pete: I can see that you are concerned for maintaining a standard interface, as of course you must be, since a large 3rd party market relies on this. I am not sure about this, but it seems that there might be a way to accomplish this objective without breaking existing interfaces. Would it be technically feasible to create multiple instances of WideServer (on different PCs) with multiple instances of WideClient (all on one PC) using different port numbers? I see in the WideFS documentation under the heading "WidevieW compatibility": But if you made the change that you proposed in your previous response, where WideClient.ini allowed specification of the FS Window Class name, then I could have multiple instances of WideClient on one machine, because the multiple instances would be differentiated by their port numbers (on the network side) and their window class names (on the programming interface side). Then I would have to change the FSUIPC SDK API to support identification of and access to these multiple instances. The resulting API would not conform to the current SDK interface. But I don't think it would prevent execution of applications that do conform to that interface, as long as they continue to use the default window class names. I understand that you might not be terribly interested in spending time making modifications to FSUIPC just so some one-off user can create his own application that your other users will never see. So, what if I further proposed the existence of a helper application that would change the window name of the WideClient window, after it is launched? I would prefer to propose changing the window class (so that SDK code wouldn't have to change), but I don't think that is possible after the window is created. If I used this helper application to rename each instance of WideClient to a unique window name, I would be almost where I needed to be. I could then modify the following code in a local copy of the C SDK: to pass a non-null argument for the fourth parameter to FindWindowEx. This non-null argument would be the desired window name, i.e. something that uniquely identifies each instance of WideClient. This would not require any change to the FSUIPC shared-memory file mapping interface, nor to the message protocol between WideServer and WideClient. It is purely localized to the SDK code. The C SDK code could be further modified to be a true C++ class implementation (as it seems to have once been, anyway), to support multiple instances of the interface. I don't think even this change affects existing applications, because those applications would still use the same window class name, and the NULL window name, which would match any existing instance of that window class, even one whose window title had been changed from the default as described above. It seems to me that there actually might be some demand for the capabilities that this multi-client support would provide. There could be plenty of interesting applications that worked with merged data from multiple FS simulations, in addition to the capabilities that are already present with multi-player. I would of course be willing to contribute any modifications back to the user community. Tim Crews GECO, Inc.

Hello: Would it be possible to run multiple instances of WideFS client on one PC, connected to instances of WideFS server on multiple computers? A single application would then display merged data from multiple instances of Flight Simulator. I know that a single instance of WideFS server can connect to multiple WideFS clients. But from the client-side API it is not obvious that a single client could support multiple servers, or that multiple clients could co-exist on one computer. Since the SDK works by attaching to a window based on its title, and all of the WideFS client windows would have the same title by default, it would appear, at the very least, that the SDK code would have to be modified. Thanks for any advice, Tim Crews GECO, Inc.

Our project has a short fuse. It is should be more than half finished in two to three weeks. Would it be possible to get a "sneak preview" version of the Java SDK? Tim Crews GECO, Inc.

Pete: I do now see the range of offsets that are "available for applications". I'm sorry I missed that the first time around. If I succeeded in reserving offset 5280, for example, and I wrote an external application that writes values to that offset, would I use the "Library for FS Internal Users" to read data at that offset from my custom gauge code? One thing that I failed to mention is that the application will not be publically available. It would be used internally for prototyping of real cockpit displays. So, I would certainly understand if you were uninterested in setting aside space in your offset map for applications that none of your customers/users would ever see. (On the other hand, I do see a strong possibility that we will be contributing a Java API for FSUIPC when we complete this task, if that's something your users would find useful. ) If our use of the desired offsets is purely private, do we need to apply for reservations of offsets at all? Does FSUIPC have to do anything additional to support data transfer at these new reserved offsets, or are the offsets transferred by FSUIPC already? For example, if I decided to use offsets 6300-7424 for our private application, would this data make it through to our custom gauges without any additional FSUIPC changes? If that answer to that question is No, I wonder if a chunk of locations could be set aside for private implementations? In other words, no publically available application should rely on this range of addresses for any particular purpose, but multiple different private applications could use this range of addresses for their own purposes. Of course, only one of these private applications could run at one time, since they would all be overloading the use of the same offset ranges. Thank you again for your time, Tim Crews GECO, Inc.

Hello: I have a requirement to implement a weapons/targeting display system for a military airfcraft simulation. It would be implemented as a separate executable from FS, communicating with FS via FSUIPC. I need some of the data from this new subsystem simulation to be communicated back to Flight Simulator, so that it can be displayed in custom FS gauges. For example, targeting information could be displayed in a FS heads-up display. Is there a way to communicate such data back to FS via FSUIPC? In other words, are there any "expansion" offsets where non-FS data can be placed, so that custom FS gauges can read data from custom external simulations? Thank you for your support, Tim Crews GECO, Inc.