Paul Henty

Hi Pete, As scruffy said, nothing. You can call any Win32 DLL if that's the platform you're running on. In fact the .net FSUIPC SDK code does just that. It calls User32.dll and Kernel.dll just like your C example. This is a useful thing to be able to do the moment as we're still running on Win32 OS. For example, the FSUIPC client uses windows messages which do not exist in .net. It's essential that we can call Win32 dlls for legacy reasons like this. If one was to imaging a version of FSUIPC written in .net, you'd use the Remoting Services to exchange data between different processes instead of IPC. Interestingly, the remoting services also work between different machines on a network. So if FSUIPC was written in .net there'd be no need for a seperate WideFS program as any FSUIPC client program could access the FSUIPC server on the same machine or a networked one. They wouldn't care. There would also be no need to write any networking code either - that's all handled by the framework. Standard memory allocations arn't required because you don't manage your own memory - the framework does it for you and cleans up after you. Explicit memory allocations are a Win32 concept. You can't normally use pointer arythmatic in .net because you could get into a mess like corrupting the stack or you might try to read or write memory that you isn't yours. Having said that - if you're using C++.net or C# these do have full pointer functions available, but if you use them you have to declare your code as 'unsafe'. It's only really useful for porting existing code. There's no reason to use such techniques in .net. Ponter arythmetic is simply not required to write a .net program. The token stuff is not nessasary. I suspect it's only there because the author was from a win32 background and didn't know enough about .net at the time. There are much tidier ways it could have been done without pointers or the token system. The managing is not done by interpreting the code, or running it inside a 'proper' Win32 process and looking over it's shoulder. It's done by inserting calls to the various framework libraries at compilaton time. Paul

Hi Pete, .Net code is not 'interpreted' like BASIC or a scripting language. Any program written in a .net language gets compiled to native machine code before they are run. They're as 'fully compiled' as any C or C++ program. The only thing that isn't 'native' about them is that they can't be run directly by the operating system (as of WindowsXP) as they're not programmed against the Win32 API. They have to sit on top of a framework that does talk to the OS and Win32. This will all change in Vista as the Win32 API is being replaced with the WinFX API which is written in .net. So .net will become the native code (both in terms of being compiled to machine code and also being run directly by the OS). Paul

Hi, Your code looks fine. I've copied and pasted it from your post and I get a proper value back in the Bank variable. Must be something wrong somewhere else. Have you got a registered copy of FSUIPC? I remember a similar post not so long ago where the problem was an unregistered version. Paul

Just a note on WidevieW - according to the website FAQ, the 2004 version doesn't tranmist guage/panel data to the clients, only aircraft position. The panels only run on the server computer. Paul

Pete often asks people to look at the FSUIPC.Log file that's created in the Modules folder. Have a look and see if there's anything obvious. Maybe copy it into this thread and see if anyone can see anything. Paul

It works the same as in the Read() method - ie, you can use it in the FSUIPC_Get() method to read back the number you just wrote. I can't see that being of much use though :-) It's pretty redundant as far as I can see. Paul

Hi kenazo, Public Form1() is the constructor. It's a bit unusual to see this.Show() in the constructor. Rather you should put this in the main program method (public static Main()) after you create your form. Presumably you have something like Form1 myForm = new Form1(); after that you should do myForm.Show(); Alternatively you can do: Application.Run(myForm); or Application.Run(new Form1()); Anyway - to your specific problem: The application isn't responding because it's in a really tight loop. Thread.Sleep() is still blocking the thread - ie, it's waiting 300ms and then carrying on - it's not allowing other threads to run. What you should use instead is: Application.DoEvents(); Which unblocks the thread and allows other windows messages etc to be processed. But there's a much better way of doing this than creating a continuous loop on the main thread: On the form designer find the 'Timer' control in the toolbox and drag it onto the form. It's not a visual component so it appears at the bottom of the form. This timer allows you to run a method every x milliseconds. In the properties set the Interval to the number of millisecond - So you want 300. Then on the events section (click the lightning icon on the top of the properties) double click in the blank space next to 'Tick'. This will take you to the code and wire up an event handler for you. You will see a new method which will now run every 300ms. It's probably called: private void timer1_Tick(object sender, EventArgs e) Ignore the parameters. Just write your code in here to get the airspeed back. At some point in your code need to Enable the timer - by default it won't run. I suggest enabling it after you have opened FSUIPC because the code in the timer event will crash is it's run before FSUIPC is open. To achieve this - and some other good practise too - I suggest you setup two more events: In the form designer click on the (blue) title bar of the form to get the properties/events window to show the properties/events for the form itself. Then go to the events bit and find: Load Again double click in the blank area to the right to make a new event handler. This one will run when the form loads. In here - do the FSCIPC open stuff and lastly enable the timer. Timer1.Enabled = true; (Be sure to move the line Fsuipc fsuipc = new Fsuipc(); up into the form member variables section so it can be accessed from any method). Lastly, back to the forms events and make a handler for FormClosing. Here you can close FSUIPC. Hope that helps at bit. Everything should run much more smoothly, and with the timer method you won't need to worry about Application.DoEvents() either because the timer is on a different thread anyway. If you have any questions, just ask. Paul

Yeah, I get an accurate value for the current indicated speed. Paul

Hi Simon, I've just pasted your code and it works for me! As Pete said you need to divide the AS by 128 not multiply but other than that it's working. I don't have any ideas on where the problem might be but it's not the code. Paul

OK, no probs. Yeah, that's was plan B - Just looking for an easy option first :-) Thanks for your reply. Paul

Hi Pete, I'd like to read the position of the sun from FS into my program - ie, its heading and its angle from the horizon. I've looked in the offset table in the documenation and I can't see anything. I'm assuming that FS has to calculate this to put the sun in the right place and do the sun glare effect when you fly towards it. What are the chances that FSUIPC can give this info? Thanks, Paul

Roberto, Have you installed the lastest GoFlight drivers from the web site? http://www.goflightinc.com Old versions of the goflight installer program do not write a registry key that FSUIPC looks for. The latest installer on the web site will. Give it a try if you havn't already. Paul