computerman1597 Posted July 8, 2013 Report Share Posted July 8, 2013 (edited) I am working on a c# program using the .NET Client DLL that, among other things, allows failing engines and instruments. I have been able to read values of things like the light status, etc. I would like to have the fail engine button set to fail the engine if it is currently working, or un-fail the engines if they are currently failed. However, when i try to read the current value, instead of a value, i just get FSUIPC.Offset`1[system.Int16]. Is the failure offset write only? I set the variable like this: private Offset<short> failEngines = new Offset<short>(0x0B6B); //Offset to fail the engines And try to read it: // Failure // Write status of failures to failure box this.failuresBox.Text = failEngines.ToString(); Is the offset write only (if that's possible) or is there something else that i need to be doing? I am currently using FSX. Edited July 8, 2013 by computerman1597 Link to comment Share on other sites More sharing options...
Graham Pollitt Posted July 8, 2013 Report Share Posted July 8, 2013 That offset is a bit array and yes you can read/write to it 'In FS2000 and later, FSUIPC extends this by having a bit for each engine, 1=Eng1, 2=Eng2, 4=Eng3, 8=Eng4' Private fsEngineFail As Offset(Of BitArray) = New FSUIPC.Offset(Of BitArray)("engines", &HB6B, 1) Public Engine1fail As Boolean Public Engine2fail As Boolean Public Engine3fail As Boolean Public Engine4fail As Boolean 'then have something like' FSUIPCConnection.Process("engines") If fsEngineFail .Value(0) = 1 Then Me.Engine1fail= true Else Me.Engine1fail=false End If If fsEngineFail .Value(1) = 1 Then Me.Engine2fail = true Else Me.Engine2fail =false End If If fsEngineFail .Value(2) = 1 Then Me.Engine3fail = true Else Me.Engine3fail =false End If If fsEngineFail .Value(3) = 1 Then Me.Engine4fail = true Else Me.Engine4fail =false End If To set a bit do something like fsEngineFail .Value(2) = 1 'then write it ' FSUIPCConnection.Process("engines") 'this should set engine 3 bit to 1 to show engine fail' Thats from memory. It tests whether each bit for each engine is set or not and sets the bool var accordingly. In VB.net at least. May not be 100% correct but should give you an idea. EDIT you may have to change the above lines to (not home at mo to look how I did this) If fsEngineFail .Value(0) < 0 Then 'true' else 'false' 'etc.' Link to comment Share on other sites More sharing options...
Pete Dowson Posted July 8, 2013 Report Share Posted July 8, 2013 However, when i try to read the current value, instead of a value, i just get FSUIPC.Offset`1[system.Int16]. Sorry, I don't understand how, if you are reading a byte value (which is only 8 bits, range 0-255 if unsigned), how you can get a weird string like " FSUIPC.Offset`1[system.Int16].". Are you perhaps mistaking an error message for a value? I don't know C# at all, but the following seems odd: Offset<short>(0x0B6B); As documented, offset 0B6B is a one byte, or 'BYTE' value (8 bits). I don't know about C#, but in C/C++ "short" is a 16 bit or 2-byte value. I think you would get wrong results in any case even without whatever error string you seem to get. Is the offset write only (if that's possible) You don't mention which version of FS you are talking about, as this may be different. But i'll assume FSX for now. Internally, as a Simulation variable, it's really read-only, but if you write to it a different value to its current value, FSUIPC interprets that as a request to send the TOGGLE_ENGINEn_FAILURE control to FS, where n depends on which bit(s) you change. The read-back value will then change when FS accepts and obeys that control. Pete Link to comment Share on other sites More sharing options...
computerman1597 Posted July 8, 2013 Author Report Share Posted July 8, 2013 The short int is one of the other data types that a tried, after using byte, and having it return FSUIPC.Offset`1[system.byte]. The fix ended up being converting the byte to an integer using the bytes .value, then display that using tostring(): // Failure // Write status of failures to failure box // failEngines is the value of the offset from FSUIPC int engineFailed = failEngines.Value; this.failuresBox.Text = engineFailed.ToString(); instead of calling failEngines.ToString(). Link to comment Share on other sites More sharing options...
Pete Dowson Posted July 8, 2013 Report Share Posted July 8, 2013 The fix ended up being converting the byte to an integer using the bytes .value, then display that using tostring(): Weird language, C#, since a BYTE is already just an 8 bit integer. I would imagine that under the skin all the conversion does is provide the byte as it is. No conversion is really necessary. Ah well. Regards Pete Link to comment Share on other sites More sharing options...
Paul Henty Posted July 9, 2013 Report Share Posted July 9, 2013 The short int is one of the other data types that a tried, after using byte, and having it return FSUIPC.Offset`1[system.byte]. The fix ended up being converting the byte to an integer using the bytes .value, then display that using tostring(): // Failure // Write status of failures to failure box // failEngines is the value of the offset from FSUIPC int engineFailed = failEngines.Value; this.failuresBox.Text = engineFailed.ToString(); instead of calling failEngines.ToString(). The string you are getting with failEngines.ToString() (FSUIPC.Offset`1[system.byte].) is the name of the class. That's what you have asked for by calling the ToString() method on the offset object. What you want is the string version of the Value of the offset which is: failEngines.Value.ToString(); Your conversion through an int is not required. You might also consider Graham's excellent suggestion of declaring the offset as a BitArray type. You might find it more convenient if you are working with more than one engine and are not familiar with bitwise operations. Paul Link to comment Share on other sites More sharing options...
mgh Posted July 9, 2013 Report Share Posted July 9, 2013 Weird language, C#... Agreed. What are the advantages of managed C# over native C/C++ in these circumstances? Link to comment Share on other sites More sharing options...
Paul Henty Posted July 9, 2013 Report Share Posted July 9, 2013 Pete Dowson, on 08 Jul 2013 - 11:42 PM, said: Weird language, C#.. mgh said... Agreed. What are the advantages of managed C# over native C/C++ in these circumstances? There's nothing 'weird' about C#, although it might look that way if your only knowledge of it is what you see on this forum. People posting on this forum about C# (or VB.NET come to that) are usually beginners. People who have picked up what they can as a hobby by looking at 'example code' usually also written by beginners. They have no formal or deep understanding of the language they are using. They muddle through as best they can and post bizarre code and incorrect statements about C# because they don't really know what they are doing. What's posted on this forum is not a text book on C# or shining examples of what the language can do or how it works. The reasons to develop in C# (or VB.NET) rather than C/C++ would be very similar to why you would use C/C++ rather than assembler. It's a higher level language which is easier to learn and much faster to develop applications with, requiring fewer lines of code to be written. Also, you don't need to worry about technicalities like memory allocation/deallocation, pointers, message pumps etc. which makes it attractive to people who just want to get on and write their application rather than learn about the inner working of the PC and Windows first. Paul Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now