Hello, I was just wondering if it is possible to prgram for Fly! II in the Microsoft C# Enviornment?

>Hello, > I was just wondering if it is possible to prgram for >Fly! II in the Microsoft C# Enviornment? Not directly. You might be able to get it to work with some Managed C++ in between.The Fly SDK is a static library. You can't call functions in a static library directly from C#. You also need to export the DllInit and DllKill functions, and I don't think C# can do that. Managed C++ can bridge the native/CLR boundary.Your MC++ DLL would need to instantiate the C# class and pass it some initialization values. To be able to call back into Fly from C#, you will need to either write a garbage collected class in MC++ or individually export normal C++ functions from your DLL and call them via Platform Invoke from C#. Personally, I wouldn't do it. Assuming you could get everything to work, the time you spend writing the interface plumbing will be more than you'll save by writing your application logic in C#. -Frank

In theory, it should be possible. You would need to, on the one hand, construct a set of "extern C" imports so that C# could make calls into the Fly! SDK API. This is not a problem. However, Fly! II needs to have you export a number of C-style entrypoints. This is where things start to fall apart. The managed environment does not provide for this eventuality. After all, when you perform a loadlibrary call, what exactly does that mean from the perspective of the managed code base? Or for that matter, when you call getProcAddress? Looked at from this perspective it makes sense that the CLR doesn't permit this. So, the short answer is "no, you can't". However, it should be possible for you to create a "mixed-mode" environment. Use C++ to create a standard DLL that exports the required entrypoints. Use C# to implement your functionality. The C++ DLL would then call into your C# module using standard COM calls that are readily supported by the managed code environment. This is not an entirely optimal solution, since when implementing the C# module, you would still have to go through some level of effort to import the Fly! SDK API. This added level of complexity would be inefficient. Moreover, I'm not really certain it would work. In theory, it should, but this Microsquish we're talking about here and the good folks there may have decided that this type of process boundary is not supported.My suggestion would be to bite the bullet and do it in C++.Cheers, Tony

Hey, Thanks guys...so the short hand answer would be no! OK...back to studying the books LOL "Sams teach yourself C in 21 days" preceeded by "Sams Teach yourself C++ in 21 days" LOL

Why don't you send me an e-mail (mailto:[email protected]) and I can provide to you a reasonably complete DLL shell project. You could then add functionality to it without having to build the framework from scratch. Mind you there are rules you have to follow when talking to Fly!, but we can work out those issues as you get further along in your programming effort. Also, if you haven't already, you should definitely print the Fly! SDK Programming Guide. It's a very useful reference to have lying about and you'll access it quite often. Anyway, good luck!Cheers, Tony

Hey, I am reading through the "Teach yourself C in 21 days" and I don't want to be restricted so I think i will take the harder route but it will be worth it..yay