Jump to content


Photo

FSUIPC Client DLL for .NET - Version 2.0


  • This topic is locked This topic is locked
428 replies to this topic

#41 lordofwings

lordofwings

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts
  • LocationEarth

Posted 11 June 2007 - 09:29 AM

I noticed that your Offsets are internally indexed in FSUIPConnection using their address.

At least in my add-on experiment I have run into situations in which I have two classes monitoring the same offset but that gives problems with an exception saying there is already an entry with that offset.

That because I don't like to group all things into just one class but rather divide it in logical groups, some of which sometimes overlap slightly.

What I try to do is to define the offset do the operation and if I no longer need it (until it gets needed again for some reason) to disconnect the group.

Anyway, thought that might make it easier.
  • 0
Blogger: Lord of Wings Blog
Facebook: Lord of Wings
Twitter: @aviationweb

#42 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 430 posts
  • LocationBristol, UK

Posted 11 June 2007 - 12:27 PM

I have run into situations in which I have two classes monitoring the same offset but that gives problems with an exception saying there is already an entry with that offset

.

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
  • 0

#43 Guest_ava038_*

Guest_ava038_*
  • Guests

Posted 11 June 2007 - 08:08 PM

Hi to all,

I have a problem by sending text-messages via 0x3380. In C++ it's not a problem but with this .NET dll the text-message in simulator is showing only at the second time. In other words, the first sending is not showing the text-message, the second shows the first text-message, the third show the second text-message and so on.

Please try my attached sample and press the "Sending text" button to send the sample text to FS2004. The first time no text is displayed, the second time a converted text (another problem) is displayed? This is not a primary problem, because if you use the "byte[]" version, there are no converting in it?!?

I hope you understand what I mean.

Thx for your help.

Andreas Widmann

Attached Files


  • 0

#44 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 430 posts
  • LocationBristol, UK

Posted 11 June 2007 - 09:19 PM

Hi,

There's two seperate problems here...

converted text (another problem)


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.

text-message in simulator is showing only at the second time


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
  • 0

#45 lordofwings

lordofwings

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts
  • LocationEarth

Posted 15 June 2007 - 09:41 AM

One of the wonderful things about the Offset generics implementation is that you can Disconnect() and Reconnect() offsets individually.

It is alsco cool that the main class has a DisconnectGroup() method which comes quite handy when you have classified your offsets (as I did) and need to control them in groups.

Unfortunately I seem to miss the obvious counterpart: ReconnectGroup() because some times you need to reconnect a group as a whole rather than going through each of the offsets programmatically.

I think this would be a nice addition to the next version (when is it coming out?) and should not be difficult to implement as you already have the DisconnectGroup() which simply iterates through the whole list and operates on the offsets matching that group.
  • 0
Blogger: Lord of Wings Blog
Facebook: Lord of Wings
Twitter: @aviationweb

#46 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 430 posts
  • LocationBristol, UK

Posted 15 June 2007 - 10:58 AM

Hi LordOfWings,

Unfortunately I seem to miss the obvious counterpart: ReconnectGroup() because some times you need to reconnect a group as a whole rather than going through each of the offsets programmatically.

I think this would be a nice addition to the next version (when is it coming out?) and should not be difficult to implement as you already have the DisconnectGroup() which simply iterates through the whole list and operates on the offsets matching that group.


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
  • 0

#47 lordofwings

lordofwings

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts
  • LocationEarth

Posted 17 June 2007 - 02:11 PM

Hi Paul,
Thanks a LOT for that detailed explanation about the ill-named Disconnect. I guess next release might be a good thing to give it a more appropriate name (but that is up to you); nevertheless I do understand the situation as many years ago (when I was into open software) I also had an ill-named application name LOL.

Anyway the explanation was clear and fantastic, I appreciate it and sorry if I ask too many questions it is just that I am working full time on this app. so I come across these things.

Following your suggestion of some days ago I refactored and grouped within the classes but was thinking of having a finer detail of control by disconnecting offsets. So far there I am ok, I will just need to change the other things where I was 'disconnecting' groups that may/could be used later on.

Well, it is clear now. Thanks a million and keep up the good work. Enjoy those holidays, I should be doing that too!
  • 0
Blogger: Lord of Wings Blog
Facebook: Lord of Wings
Twitter: @aviationweb

#48 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 30 June 2007 - 05:18 PM

Here is what I am trying to do

http://williams.best...orm.htm#Example

tc1 should be 66deg but I read 55deg

and here is the code

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Dim lat1, lat2, lon1, lon2 As Double
Dim dis As Double
Dim tc1 As Double
Dim a, b, c, d, f As Double

lat1 = (33 + 57 / 60) * (Math.PI / 180) 'answer in radians
lon1 = (118 + 24 / 60) * (Math.PI / 180)
lat2 = (40 + 38 / 60) * (Math.PI / 180)
lon2 = (73 + 47 / 60) * (Math.PI / 180)

dis = 2 * Math.Asin(Math.Sqrt((Math.Sin((lat1 - lat2) / 2)) ^ 2 + Math.Cos(lat1) * Math.Cos(lat2) * (Math.Sin((lon1 - lon2) / 2) ^ 2)))
dis = dis * ((180 * 60) / Math.PI) 'convert to nm

tc1 = Math.Acos((Math.Sin(lat2) - Math.Sin(lat1) * Math.Cos(dis)) / (Math.Sin(dis) * Math.Cos(lat1)))
tc1 = tc1 * (180 / Math.PI) 'convert to degrees

Label1.Text = "lat1=" & lat1 & " lon1=" & lon1 & " lat2=" & lat2 & " lon2=" & lon2 & " distance d=" & dis & " course:" & tc1

End Sub

EDIT - found the problem, I was converting into nm and using that as the distance when it should have been in radians, doh, lost 2 hours bcos of that :)
  • 0

#49 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 430 posts
  • LocationBristol, UK

Posted 21 July 2007 - 11:20 AM

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
  • 0

#50 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 21 July 2007 - 05:14 PM

thanks Paul, appreciated as always :D

Gray
  • 0

#51 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 25 July 2007 - 11:47 AM

Anyone know of a way to interface VB.Net to the Level-D 767 dll? Are there any VB.net packages anywhere? I've searched on Google and Level-D forums but to no avail

The only way Ive come up with so far to read the 767 switches etc is to read the offsets as written by FSConv, is this efficient enough for my flight tracker program?

Thanks
Gray
  • 0

#52 jgrouse

jgrouse

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 11 August 2007 - 12:26 AM

Hi,

Great work with the port to .NET. The original VB6 support was brilliant but since then I have moved on to VS 2005. Only problem is that the supplied source code for VB.NET which came with .NET shell rev 2.004 is not quite 1 to 1 for the newer VB 2005 code and the built in conversion wizard just ends up with a big blank form. The final code doesn't seem to show any examples of reading real-time values.

If anyone out there has any working samples of VB 2005 code that just gets the current lon/lat values I'd really apprieciate it.

Regards,

John
  • 0

#53 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 430 posts
  • LocationBristol, UK

Posted 11 August 2007 - 11:47 AM

Hi John,

Only problem is that the supplied source code for VB.NET which came with .NET shell rev 2.004 is not quite 1 to 1 for the newer VB 2005 code and the built in conversion wizard just ends up with a big blank form


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
  • 0

#54 jgrouse

jgrouse

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 11 August 2007 - 09:43 PM

Thanks Paul, that's exactly what I was after. Solution dropped straight into VS 2005 without any conversions required.

Regards,

John
  • 0

#55 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 09 September 2007 - 07:19 AM

I have question regarding destroying objects.

In my project I have option to select aircraft with 2 different classes, defaultaircraft and leveld767. I have used objAircraft to hold the copy of the object depending on which aircraft is selected.

In my module I use Public objAircraft but dont set it to anything as this is done when the aircraft is selected. ie If the aircraft is Level-D 767 then in my code I use objAircraft=New leveld767, for default objAircraft=New DefaultAircraft.

This works fine for one run ie I select an aircraft, the object is created and my app runs. If however after I then want to choose a different aircraft I get the error 'An item with the same key has already been added.'. So I added the line objAircraft=Nothing, thinking this would kill the object which it seems to as in debug the reference objAircraft is then empty or 'nothing'.

ie my code
        objAircraft = Nothing

        'see if it is level-d 767
        If n = "Level-D Boeing 767-300ER" Then
            'if it is then set flag to show we are using this aircraft
            objAircraft = New LevelD767 'create instance of level-d aircraft
            LevelD = True
        Else
            objAircraft = New DefaultAircraft 'create instance of default aircraft
            LevelD = False
        End If
How can I get around this problem please? It seems that I need to completely destroy the objAircraft but cant figure out how.

Also using the above with regards to defining an object at runtime means that I lose my intellisense at design ie the leveld767 class has different methods than the defaultaircraft class. By declaring objAircraft as public but not linking it to a class means when I do this
- objAircraft. I dont get the list of all the methods etc to choose from so I am having to type them in manually. Doing it this way also means that if I mispell anything then my app throws up the error in runtime and not design. Is there a better way around this?

thanks
Gray
  • 0

#56 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 430 posts
  • LocationBristol, UK

Posted 11 September 2007 - 03:29 PM

Hi,

Sorry for the delay - I've just moved house and don't have any internet connection.

How can I get around this problem please? It seems that I need to completely destroy the objAircraft but cant figure out how.


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.

By declaring objAircraft as public but not linking it to a class means when I do this
- objAircraft. I dont get the list of all the methods etc to choose from so I am having to type them in manually. Doing it this way also means that if I mispell anything then my app throws up the error in runtime and not design. Is there a better way around this?


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
  • 0

#57 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 13 September 2007 - 04:55 PM

thanks Paul, works fine with the disconnect group call. :)
  • 0

#58 bismond

bismond

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 01 October 2007 - 05:19 PM

I'm a beginner amatuer programmer and I was wondering how to go about writing a program that would constantly scan a group of offsets while FS9 is running. For example I want to turn on the leds of a phidgets card when the landing gear goes down and turn them off when gear is up. I've already written a simple console program that uses FSUIPC client and reads the offset of the landing gear once and turns on the led [see below] but how do I have the program run all the time and wait for the gear to change and turn on the led? Do I use the c# Timer class to call Process() and use conditional statements or an event delegate type deal? Thanks
Dazed and confused

using System;
using System.Collections.Generic;
using System.Text;
using Phidgets;
using Phidgets.Events;
using FSUIPC;
using System.Threading;

namespace FSUIPC_LED_Wrapper_dll
{
class Program
{
static LED myLed = new LED();

static void Main(string[] args)
{
myLed.open();
myLed.waitForAttachment();
try
{
FSUIPCConnection.Open(FlightSim.FS2K4);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}



Offset gearValue = new Offset(0x0BEB);

FSUIPCConnection.Process();

Console.WriteLine("Gearup = 0 Gear down = 4194048 Value = {0}", gearValue.Value.ToString());
int gear = 4194048;
if (gearValue.Value == gear)
{

myLed.leds[1] = 100;
myLed.leds[2] = 100;
myLed.leds[8] = 100;
}

Console.ReadKey(true);
myLed.leds[1] = 0;
myLed.leds[2] = 0;
myLed.leds[8] = 0;
FSUIPCConnection.Close();
myLed.close();
}












}

}
  • 0

#59 EW321

EW321

    Advanced Member

  • Members
  • PipPipPip
  • 150 posts
  • LocationEINN

Posted 03 October 2007 - 07:31 AM

I'm a beginner amatuer programmer ...

......
Console.WriteLine("Gearup = 0 Gear down = 4194048 Value = {0}", gearValue.Value.ToString());
int gear = 4194048;
if (gearValue.Value == gear)
......

}

Hi

I don't know C**, but of course you need to use a timer.

Offset gearValue = new Offset(0x0BEB);

You use the Offset BEB ??

The Gear positions are read in
0BEC 4 Gear position (nose): 0=full up, 16383=full down
0BF0 4 Gear position (right): 0=full up, 16383=full down
0BF4 4 Gear position (left): 0=full up, 16383=full down

int gear = 4194048;
if (gearValue.Value == gear)


The value for Gear down is 16383.
  • 0

Best Regards
Thomas Richter

technicalservicerichter@gmail.com
 


#60 cknipe

cknipe

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 31 October 2007 - 04:52 AM

Hi,

Any memory limitations in regards to the amount of offsets that can be registered? Please see attached - it doens't make sense to me at all :( Basically, any additional offset registered through FSUIPC.Offset, gives the same identical error....

--
Chris.

Attached Thumbnails

  • Untitled.gif

  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users


About simFlight - simflight.com - simflight.de - simflight.fr - simflight.nl - simflight.pt - simflight.es - simflight.it - simflight.jp - simrussia.com - simMarket