Paul Henty

Would be identical, except VB.NET insists on a rather vulgar and ostentatious capital D. ;-)

You use a 'Double'. Paul

Integer in VB.NET is a signed 4 byte integer. You need a UInteger which is a 4-Byte unsigned integer. With signed integers, values greater than half the maximum value (in this case of a 4 byte integer, greater than 2147483647) are used for negative values (i.e. from 0 to -2147483647). You need to do this: Dim Heading As New Offset(Of UInteger)(&H580) But this alone will not solve your heading difference problem. As Pete says you're probably not factoring in the local magnetic variation (see offset 02A0). Paul

Hi Tobias, What you've declared here is an offset that will read 256 bytes into a byte array. Offset 3364 is only 1 byte in length, so you should only declare it as a byte (not a byte array): Public FlagReadyToFly As Offset(Of Byte) = New FSUIPC.Offset(Of Byte)(&H3364) If you look in the UserGuide.htm in the docs folder, there is a section called "Registering your interest in an Offset" This explains what type of VB variable you should use in the offset declaration according to how the offset is described in the "FSUIPC for Programmers" document from Peter. The top line of the table says that offsets with size 1 should use Byte in VB.NET. Paul

No probs - here's what you do... 1. Create the textbox to hold the startup fuel amount 2. Find the sub called: Private Sub Form1_Load... 3. After the call to OpenFSUIPC() add a process() line 4. Get the value from your fuel amount offset, do any maths/formatting you need and put the result in your new text box. 5. That's it. The Form1_Load() only runs when you start the form. So it'll grab the startup fuel amount. After that the timer will update your current fuel amount as normal. Here's an example of the same thing but I'm storing the Compass Heading at startup as I don't have fuel data in my test app.... Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load OpenFSUIPC() FSUIPCConnection.Process() Me.txtHeadingAtStartup.Text = compass.Value.ToString("F2") End Sub Paul

Can you explain a bit more - I'm not sure what you're trying to do. Where do you want to store the value at startup? - are you talking about writing a value into Flight Sim or simply storing a value in a variable or form control? What do you mean by "another textfield that is updated"? What information is being updated and where does it come from? If you can give me the specific problem you're trying to solve I'll be able to tell you how to do it. Paul

Sascha, Pete did answer your question. As long as all the individual reads are stacked up before a single process you will save no time at all by reading a large block and splitting out the individual variables manually. However if you really must do it like this, here is what you would do... The Token is merely a reference to the data you want. It's not the actual data. So regardless of the length of the data you are reading the token is always an integer. The token is peculiar to this poorly implemented FSUIPC SDK and is why I wrote my DLL that Pete referred to. 1. You set up the read as normal: You declare the start offset of the data block and the length of the entire data block (ie, the length of all the offsets added together). You get an integer token as normal. 2. Then you process. 3. Then you get your byte array back using the appropriate Get() overload, passing your integer token (which identifies the start of your data block) and the length of the entire data block again (dwSize). This will copy the raw bytes from FSUIPC into the byte array you passed into the Get() function. 4. So now you have an array of bytes which you must split up into individual variables. For this you need to use the BitConverter class. It has methods (e.g. ToInt32(), ToDouble() etc.) which take an array of bytes and a start address in that array where the variable starts. You can get an idea of how to use these by looking at the Get() methods in the source for the VB.NET SDK. Basically if the first variable in the data block is the latitude (64bit int (8bytes)) and the second is the Longitude (also 64Bits (8 bytes)) you would do this: Dim myLat as Long Dim myLon as Long myLat = BitConverter.ToInt64(myArrayFromFSUIPC,0) myLon = BitConverter.ToInt64(myArrayFromFSUIPC,8) and so on for each variable in your large data block. So that's how you would do it. But I assure you it's a complete waste of time. Paul

Hi Hawk, Take a look at page 1 of this thread - about 8 posts down I answer a similar question about COM2 from Devon. This should show you how to to it. If this isn't sufficient let me know... Paul

It depends how you are talking to FSUIPC. I suspect you are using the C# SDK from the official FSUIPC SDK download. That doesn't support Float64s which is one of the reasons I wrote my FSUIPC Client DLL for .NET programmers. You can read about it and download it in the sticky posting above: http://forums.simflight.com/viewtopic.php?f=54&t=53255 If you're too far down the road of development to switch all your code then let me know and I'll see if I can provide you with a workaround for the original SDK or add float64 support to it. I'll need to spend a bit of time on though so I'd prefer it if you use my DLL if at all possible. Paul

Hi Chris, Sorry for the delay in replying - I still don't have an internet connection after 2 months! It does look a very strange problem. Does it make any difference if you decalare the type as FSUIPC.Offset? eg. Dim Offsetxxxx as FSUIPC.Offset(of Integer) = New FSUIPC.Offset(of Integer)(&Hxxx) As you say it doesn't make sense that the compiler suddenly can't find the type after a few lines. If the above doesn't work I'll investgate some more. Paul

Hi Ricardo, TestConsoleForm is part of the old procedural-style C# SDK. You might also want to have a look at my Object-Oriented .NET Client DLL which has a number of advantages over the old SDK. See the sticky at the top of the forum: http://forums.simflight.com/viewtopic.php?f=54&t=53255 Paul

Hi, Sorry for the delay - I've just moved house and don't have any internet connection. Your objAircraft is destroyed as soon as you set all the references to it to Nothing. What's probably causing the problem here is that your Offset objects that are created by the objAircraft object are still registered with the FSUIPCConnection class. The FSUIPCConnection class holds its own references to the offsets. So even though you have released the references to the offsets held by the objAircraft object they are still left if memory because they are registered with FSUIPConnection. What you need to do it disconnect them before you lose the references. So in your objAircraft objects I sugest you put a method called something like "ReleaseOffsets()". In there call DisonnectGroup() (or DeleteGroup() if you have v1.3 of the library) for all the groups you've declared. If you havn't used groups you'll need to call .Disconnect() on each offset. (I suggest you always use groups as it's easier to disconnect). This will make FSUIPCConnection give up it's references to the offsets. Call this before setting objAircraft to nothing and you should be OK to create another instance of your aircraft object. If you want more info on this read my reply to LordOfWings earlier in this thread. Not really. If they have different methods etc then they are different classes. The closest you'll get is to pull out the common methods etc into a base class and inherit from that when you define your specialised aircraft classes. Then you can declare the variable as the base class type and some intellisense (the common methods etc) will come through. The other way (or this can be used in combination with the above) is to cast into the specific aircraft object type once you know what type you're dealing with. Presumably you have to know in your code so you can call the special methods. e.g. Dim objAircraft as Object Dim acDefault as DefaultAircraft Dim acLevelD as LevelD767 If objAircraft.Name = "LevelD767" then Set acLevelD = objAircraft ' Call methods on acLevelD here else Set acDefault = objAircraft ' Call methods on default aircraft end if Hope this helps a bit. Paul

Hi Jörg, VBA is pretty much the same syntax as VB6 so you might be able to use the source from the VB6 SDK. Try this: 1. Look in the FSUIPC SDK and open UIPC_SDK_VisualBasic.zip. 2. Open the FSUIPC.BAS file in notepad. 3. Create a new Module in your spreadsheet. 4. Copy and Paste the contents of FSUIPC.Bas into the new module. 5. Delete the top line beginning "ATTRIBUTE..." You should then be able to use this library in the same way as the VB sdk. I've tried it really quickly and it compiled and the FSUIPC_open() seemed to work. (Told me it couldn't find FSUIPC or WideFS which was the right error message). It's worth a try. I think there's a good chance it'll work. Paul

That's the wrong overload. You need to use this one that accepts the byte array and also the length of the byte array: fsuipc.FSUIPC_Write(0x3380, datablock.length, ref datablock, ref a, ref dwResult); Try that. Paul

Hi James, Convert.ToByte() is for converting a number string to a real byte. e.g. A string "255" is converted to a byte holding the value 255. What you need to do is convert the string into an array of bytes. To complicated things all .NET strings are unicode and FSUIPC wants the string in ASCII. .NET has some classes to do a conversion for you: The following code will convert a string called "MyString" into a byte array called "datablock" and also do the unicode to ASCII conversion, and zero terminate it on the way. You can then use the datablock with the FSUIPC_Write() overload that takes a byte array (byte[]). From memory I think there's an extra parameter on that one to tell it the length of the array. Alternatively you could convert your code to use my .NET client DLL for FSUIPC. It has a number of advantages over the older SDK you are using, one being that it reads a writes .NET strings directly to and from FSUIPC. All of the above conversion is handled by the DLL. For details and downloads see the sticky post at the top of this forum: http://forums.simflight.com/viewtopic.php?f=54&t=53255 Paul

Hi John, Sounds like you are using the VB.NET shell that is supplied with the FSUIPC SDK. If so, you might want to repost in a new thread as this thread is for my new object oriented .NET client dll. You might not be speaking to the correct audience here. However, you might want to download my DLL and try it out (it's also free). It has many advantages of the one supplied in the SDK. Check out the first post on page 1 of this thread to download the package with documentation and sample projects. There are also exmples of reading lon and lat with my DLL on the first page of this thread. Paul

Hi all, Version 1.3 has been posted on page 1 of this thread. Changes since the last 1.1 release are: (1.2 wasn't publically released). * Fixed error in connection code where a failed connection could lead to never being able to connect. * Fixed error in string handling that could cause strings read from FSUIPC to be corrupted. * Fixed error in string encoding where certain symbols were corrupted when writing to FS. * Offsets are now written to the IPC file in the order they are created. This problem will not have affected most people but some offsets (like the ones to send text to FS) are sensitive to the order in which they appear in the IPC file. * FSUIPCConnection.DisconnetGroup() has been deprecieated and replaced by FSUIPCCOnnection.DeleteGroup(). DisconnectGroup was a bad name. From now on you cannot compile a project that calls DisconnectGroup(). However, projects already compiled that use this method will containue to function as before. * Added a new property DLLVersion to FSUIPCCOnnection. This returns a version object representing the version of the client DLL. * Added FSX to the FlightSim enum so that you can now write apps that only connect to FSX. There were other requests that havn't made this build. I've not got much time at the moment as I'm moving house. This release is mainly bug fixes with a couple of easy enhancements. All requests are still on the list for future versions. Paul

Offset 0x0578 is marked as 4 bytes in the fsuipc programmers docs. You need to declare your offset as a 4 byte integer - 'int' in C#. A C# long is 8 bytes so at the moment you're also reading the Bank angle into the same variable. The user guide that came with the .NET client dll has section called "Registering your interest in an Offset" which explains what .NET type to use given the types and lengths specified in the programmer's doc. You're casting is a bit wrong here. You need to cast the pitch into a double not a long. Also you should mark the literals as double type literals as well or the compiler will treat them as ints or longs. double thePitch = ((double)pitch.Value) * 360d / (65535d * 65535d); Paul

Hi LordOfWings, The next update will be in July. I'm going on holiday for a couple of weeks soon. I won't be able to do anything until I get back. About the groups - I don't think you're understanding the whole disconnection thing. It maybe because it's not explained as well as it should be in the docs. It may be because 'disconnection' is a very bad name for what's actually happening. I'll try and explain a bit better here: Disconnection for the entire group: The ability to disconnect an entire group is there only so that you can release the references to the offsets held by the FSUIPC.Connection class. The only reason you'd want to do that is if: 1. You don't need the offsets anymore, ever, for the rest of your program's lifetime, AND 2. Those offset objects are about to go 'out of scope' in your program, AND 3. You understand enough about .NET garbage collection to care about who's holding references to your objects. If you're ever possibly going to need the offsets again then don't disconnect them. It's incorrect to disconnect a group of offsets if you want to use them later. If you don't want offsets in a group updated then just don't call process() for that group. Registering offsets in a group and never processing them does no harm at all. They just sit there doing nothing. As for reconnecting the group as a whole: that's impossible. The act of disconnection removes the entire group object (and therefore all the offsets in the group) from the FSUIPC.Connection Class. That's the whole point of the disconnectgroup() method. You can't then ask it to reconnect the offsets because it's lost all referencs to them. I think I made a mistake calling it 'disconnectGroup'. On reflection it should have been something like 'UnregisterGroup' or 'DeleteGroup' or 'RemoveGroup'. I might depreciate that method in the next version and rename it. Disconnect/Reconnect individiual offsets: This facility actually does the same thing as the groups but for individual offsets. Again, we are really unregistering or deleteing or removing the offset. However, the offset can reconnect (re-register) itself becauase it remembers what group it used to be in. I added this so you've got a very fine level of control and flexibility within the grouping system if you need it. Again bad naming. Should have been something like MyOffset.UnRegister() and MyOffset.ReRegister(). So in summary: you shouldn't be disconnecting at all. You just don't need to. The control over which offsets are read or written is done by the grouping. Offsets never get updated unless you process the group they are in. Within the grouping you can further control individual offsets with the Disconnct and Reconnect methods if you need to. I hope this is much clearer now. I'm afraid I chose bad names for the methods. If you need any more info I'll be happy to answer any questions... Paul

Hi, There's two seperate problems here... Some characters (mainly punctuation) are getting converted wrongly. This is due to the converter I'm using to translate the unicode (.net strings) into ascii (for flight sim). I'll fix this in the next version. I've tracked down the reason for this. FSUIPC needs to have the text first and then the control code. When I say 'first' I mean the text must be before the control code in the IPC File that is used to communicate with FSUIPC. I didn't realise that there was any such sensitivity (I'd never used the text offsets for example). My DLL lays out the IPC file in order of Offset address. This means the text control comes before the text at the moment because the offset address is lower. Thus the control is being effectively sent before the text which explains what you are seeing. This is something else I will need to fix. I'll have to preserve the order the local offsets are instantiated in and layout the IPC file in that order. I'm on holiday for the last two weeks in June so it'll be July before I can get the next version out. For now you can work around the problem (well the order one anyway) by declaring the Text and TextControl in two different groups. You then need to process() the Text group and then Process() the TextControl group. This will force the correct order for now at the expense of an extra Process(). Paul

.The local Offset objects can indeed only be declared once per address. If two classes need to access the same offset then they must reference the same local offset instance. The best way to use the DLL is to create all your offsets when the app starts (with the appropriate grouping of course). If you keep declaring offsets before every process then the code becomes very much like the old C# SDK, which is what I tried to improve on. There's no harm in letting the offsets just sit there. If you don't call Process() for their group then they don't do anything. What I recommend you do is create a seperate class that creates all the offsets you'll ever need and exposes them as public fields or properties. You can then pass a reference to this class around (or make it a public static class) so the other classes in your app can access whatever offsets they need to. That way you just have one central pool of offsets that's used by multiple classes in your app. There's nothing to stop individual classes from calling Process() for the relevant group(s). You don't have to put the processing in the central pool. Paul

I think you've run into a bug I've fixed in 1.2 which I will release soon. Sometimes a failed connection can prevent you from ever connecting. OK - You may be the first to try and write a string. Can you confirm that you declared the offset as a string and not a byte array. You should declare the string length as the max, then you should be able to assign a shorter string. If that's what you've done let me know and I'll check the string handling. OK - I'll have a look at doing that. Paul

Hi, So you'd like the DLL to maintain the connection in the background? Maybe it could fire an event when connected and when the connection is lost. I'll have a look at the implications - I agree it'll be a bit neater than the current way. I don't have FSX but I'm pretty sure there are some people using the DLL with FSX. The 1.1 release was pre-FSX. I'll see if Pete has a value for FSX and add it in. I have 1.2 being released soon with a a couple of minor bug fixes so I'll be able to incorporate it then. That's my fault - it's poorly written. For write-only offsets you still need to call Process(). What I meant in the doc was that the value is only written during process if the value of the local offset has been changed since the last process(). That is - it's not continuously wirting the same value. For read/write offsets - they a read on every process() except where the local offset value has been changed since the last process(). In this case the offset is written to FSUIPC and then goes back to read mode. Thanks! I hope it's useful. If you need any more info or help just ask... Paul

Hi, Well the widths coming in in feet does add a bit of complication. The conversion from feet (or metres) to latitude is complicated by the fact that as you get closer the the poles, a degree of latitude represents fewer and fewer feet (or metres). There is a set formula for calculating this though. However, you then have to take into account how much of that you use and how much of the longitude you use. This of course depends on the heading. For example for a 36 runway the 'width' is all latitude. For a 27 runway it's all longitude. I think the best thing here would be to leave your program working off the four corner coordinates and have another program work these out from the runway data (I assume you're going to do some kind of import program anyway). Doing it this way would make the calculations at runtime faster as most of the complicated stuff would have been done during the import. I can probably get you a routine that works out the corners from the info you get from makerunways in a few days. I'll just need to find my maths hat. If this sounds like a plan I need to know exactly what data you have to work with from the makerunways program. I assume it's something like lon/lat of centre of the threshold, length, width, heading. What would also be helpful is if you could give me the four corners AND the make runways data for a few of your working airports. Then I have something to test against. Paul

I don't know anything about BGL files sorry. MakeRunways seems to include runway widths. This is from the readme... Let me know if you need help modifying the routine I gave you to work with the new data (e.g. centreline + width, rather than four corners.) Paul