Jump to content
The simFlight Network Forums

scruffyduck

Members
  • Posts

    146
  • Joined

  • Last visited

Posts posted by scruffyduck

  1. All I would suggest is to make sure that all your calls to Process() are wrapped in a Try..Catch block. In the Catch for the FSUIPCException type, make sure you call the FSUIPCConnection.Close() method after reporting the failure. This will enable your application to re-open the connection again.

    Paul

    Checking my code - as far as I can see that is what is happening. The call to Process() occurs only in two places throughout my code. Each is wrapped in a try..catch block. Where an exception is raised I carry out house keeping to close the connection including calling FSUIPCConnection.Close().

  2. I think the program is using my .NET DLL. It's looks like my error message.

    The first error (#12) is thrown under the same circumstances as the C source; that is, the GetLastError() being other than 0. So it's the same error, just my wording "Error sending message" along side the original C SDK enum value.

    The "Already Open" message is almost certainly because my DLL thinks the connection is still open after it failed. In other words, when the application caught the first "Error sending message" exception it didn't call FSUIPCConnection.Close() to close the now bad connection. Therefore any attempt to open the connection again will result in the "Already open" error you are seeing.

    I could add some extra information to that first exception to return the result of GetLastError(). This may help identify what the underlying problem is. Let me know if you want me to do that, or if there is any other way I can help.

    Paul

    Paul

    You are correct that I am using your .NET dll so I guess I am reporting your exception message. I guess I also need to add some more code?

  3. Odd, because the error message comes from his program, reporting an error detected in the application part of the interface, for which he can easily check because the source is available. In fact if it is reproducible it is debuggable because of that.

    Well I might debug it if I could reproduce it. I have never seen this error while working here with ADE and FSUIPC so I was hoping for an explanation of what the error means. ADE catches exception messages coming back when it tries to connect. It is using the Managed Wrapper for FSUIPC that was originally posted here - so perhaps the error message comes from there. I have checked to see if it is possible to get this error via a double click on the connection button in ADE but it is not.

  4. Hi Pete

    Something odd. My application reads and writes aircraft location information. I have the DeLuxe Edition of FSX installed and FSUIPC4 as downloaded today. It is registered.

    My program has a freeware key from you. In unregistered mode I can move the aircraft to a new location from my application i.e. write lat, lon and alt. It works fine exactly the same as with FS9.

    In registered mode the write do not have any effect and the plane is not moved. Make the program unregistered by moving out the key and the plane can be moved again.

    Here is the log when in registered mode. You can see the writes to 0560, 0568 and 0574 but they are not having any effect. The freeware key is logged but I have made a continuation log so it does not show.

    ********* FSUIPC4, Version 4.00 by Pete Dowson *********

    User Name="Jon Masterson"

    User Addr="jon@scruffyduck.co.uk"

    FSUIPC Key is provided

    WIDEFS not user registered, or expired

    [Continuation log requested by user]

    Running inside FSX

    Module base=61000000

    LogOptions=00000005

    627953 System time = 13:56:56, FSX time = 13:48:27 (17:48Z)

    628890 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    629953 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    630906 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    631906 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    633000 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    633937 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    634922 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    635922 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    636890 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    637968 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    638906 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    639109 WRITE0 0560, 8 bytes: A2 C3 30 71 AE 21 2C 00 ..0q.!,.

    639109 WRITE0 0568, 8 bytes: 00 74 D1 8A F3 0A 60 C6 .t....`.

    639109 WRITE0 0574, 8 bytes: 00 00 00 00 00 88 90 3F .......?

    639890 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    640937 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    641906 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    646078 WRITE0 330A, 4 bytes: 02 00 00 00 ....

    646656 System time = 13:57:15, FSX time = 13:48:41 (17:48Z)

    646656 *** FSUIPC log file being closed

    Memory managed: 223 Allocs, 223 Freed

    ********* FSUIPC Log file closed ***

    thanks

  5. FYI...If the program was written with VS2005 it won't work with earlier versions. It'll give an error saying "Not a valid solution" or something like that. There is a workaround...Basically open a new project with whatever earlier version you have, import the modules used along with any other code. It sounds a little silly but it works.

    Well I am not going to have more than one version around - it becomes a configuration nightmare and I only work in VS2005 so it will not be of any use to you if you are using an earlier version. You can still get a free copy of the VS2005 express editions which are absolutely fine but if your shop has not upgraded and you are required to work in an older version................ :(

  6. Out of interest - Is this a wrapper around the VB.Net code that's in the SDK at the moment, or have you written the whole thing from scratch?

    It started as a wrapper for the vb stuff in the SDK. It still uses API calls since I havent had time to sit down and change it, but I have modified the way they are used in some places. It is a half way house in that it makes reading of some offsets easier by making the result available via properties - I plan to make all offsets read/wriable via properties or similar at some point - I'd like to get away from explicitly calling offsets and use structures or enumerations instead. Other than that it is still using tokens but I want to get rid of that when I find the time :D

  7. So what stops them containing calls to the main Windows API DLLs?

    Nothing actually, but generally it is not done that way - it is just a different language, and as mentioned above it is certainly not interpreted. In fact the NET framework is just a set of DLLs like the win32 API is but we 'call' them instead of the API directly. I use C# and VB interchangeably in some cases the program constructs are easier in one than the other but in a lot of cases they are pretty much identical apart from case sensitivity, curly braces and semi colons :D :D

    Managed code refers to the fact that the NET languages manage things like garbage collection and disposal of variables and objects when they are not needed. It also means that NET langages are less likely to have memory leaks etc You can get past all that and work unmanaged, and in some instances it is important to dispose of objects yourself, but to be honest there is no point

    I have just made my .NET dll available on my web site - http://www.scruffyduckscenery.co.uk and I am putting a new forum up for VB.NET and FS

  8. Well I wonder what you are trying to understand.

    FS stores the numbers in a particular way internally and to get them out to recognizable co-ordinate values you need to use the conversion factors shown. I think you would need to ask Microsoft why they chose to store the numbers in the format that have.

    I seem to recall there is an explanation in the FSUIPC SDK documentation

  9. Thanks George - I understand how it works. I am not reading up on vector maths to code up the angle calculations. I was going to work out the bearing of each of the pairs from the aircraft and subtract the second from the first but that gets complicated around 360/0. Looks like using vectors and cross-products to calculate the angle is better as you suggest. I just digging up some information on that now - it is a long time since I did this kind of math :D

    EDIT - OK I think I have coded it now I need to make a test rig.

  10. I have a dll which contains all my interfacing to FSUIPC - it is for VS2005 (written in VB but should be fine for other .NET languages.) The DLL contains other stuff like navigational maths and provides properties to most of the common FS variables for reading. It is not well documented but if you would be interested in looking at it then let me know. It would only be available for freeware or personal use. You can contact me at jon [AT] scruffyduck.co.uk

  11. OK It's Friday afternoon and my brain has clearly stopped working. I am reading the Alt Lo and Alt Hi fields to get altitude. Alt Hi is fine but I am doing something wrong for Alt Lo.

    I have a value being returned of -1841823744 which I am treating as a double. If I calculate the low part by dividing this number by 65536*65536 and multiplying by 3.28084 I get -1.4066 but the answer I need is 1.87391 and this is being returned by FS Interrogate correctly

    Is this field a 32 bit signed integer? A far as I can see it should always be zero or positive. :?

    Any help much appreciated

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.