Is it possible to get gesture code to work with Android and C++? If so, how can it be done?
The easiest way by far would be to pass the information from your MotionEvent and/or GestureDetector to your native code via the JNI. Exactly how you do this is up to you, but the basic principle is no different than that of any other communication between native and Java code.
If you are asking if you can acquire MotionEvents without going via the JNI, if it's even possible, it's far more hassle than it's worth. You could (and probably should) use a tool like SWIG to avoid the pain of writing JNI wrapper code manually.
Related
I want to use VB.NET code in win32 (C++) (I dont want to convert my code). I have heard about wrapping VB code in COM but i don't know how to do it. Also, I am not aware if there is an alternative (or any better) way of porting the code.
Any help is appereciated.
Update: I created a class library in vb and saved it as a dll after setting the comvisible attribute to true, then imported it in my c++ project and accessed the interfaces via COM
*thank you everone for helping me out !!!!!!! *
You cannot call .NET code directly from a native C++ application, so there is some work involved.
Of course, your question leaves us guessing at why you're wanting to do this, but unless you are still going to be using the library from a .NET application, I would be a strong advocate in favor of porting it (like your title suggests) to C++.
But if you don't want to do this, you have a couple of other options:
Write a wrapper around the VB.NET code using C++/CLI. This would probably be the simpler solution, especially if you're reasonably familiar with both the VB.NET and C++ languages.
Expose the VB.NET methods you need as COM functions, using the <ComVisible(true)> attribute. This is going to be a bit trickier to get going, especially if you're uncomfortable or unfamiliar with COM programming in C++. It's too much to explain in a Stack Overflow answer; investigate purchasing a good book on COM programming. And although you're using VB.NET, the steps are basically the same for C#, for which you'll have much better luck finding examples.
You can't directly port VB into C++, but if you are looking to just switch to a more powerful language and still use the GUI libraries, you can check out C#. It uses very similar code, and a quick google search provided me this program: C# converter. If you really need C++, you could probably then convert the C# code to C++, but there really wouldn't be a need to since C# is VERY close to C++. Just googling that I found this: C++ converter.
I hope this will help you.
I would like to use Photoshop via COM using C++, but I'm not sure if I'm getting it right. I've seen lot's of tutorials on how to do that with C# and even tried one but as far as I know ideology of COM says that you can use any language you like since it's source is just binary. So, C++ is exactly what I want and to start I should have a photoshop interface class in my client programm, right ? So, the question is: Where can I get it (interface class) ? And even if I had one, how would I know about functions to operate photoshop instance. Or maybe I understanding COM + C++ wrong ? Your help is highly appreciate.
Thank you in advance!
You are right, COM is language-neutral, but it requires a lot of extra runtime work to ask the OS for pointers to the interfaces and methods you need. COM is a huge pain in C++. You're looking at 5-10 lines of code for a single function call. Microsoft's "helper" libraries like MFC and ATL can help make it easier, but it's still not pretty.
C# abstracts a lot of the details away and makes COM look like regular object-oriented code. In C++, you'd have to write the wrapper class yourself or find someone else's implementation. It won't necessarily be hard, but it will be tedious.
I work with COM in C++ and I would jump at the chance to do it with C# instead.
What's the best way to do this....?
I have some Native C++ code that uses a lot of Win32 calls together with byte buffers (allocated using HeapAlloc). I'd like to extend the code and make a C# GUI...and maybe later use a basic Win32 GUI (for use where there is no .Net and limited MFC support).
(A) I could just re-write the code in C# and use multiple PINVOKEs....but even with the PINVOKES in a separate class, the code looks messy with all the marshaling. I'm also re-writing a lot of code.
(B) I could create a native C++ DLL and use PINVOKE to marshal in the native data structures. I'm assuming I can include the native C++ DLL/LIB in a project using C#?
(C) Create a mixed mode DLL (Native C++ class plus managed ref class). I'm assuming that this would make it easier to use the managed ref class in C#......but is this the case? Will the managed class handle all the marshaling? Can I use this mixed mode DLL on a platform with no .Net (i.e. still access the native C++ unmanaged component) or do I limit myself to .Net only platforms.
One thing that bothers me about each of these options is all the marshalling. Is it better to create a managed data structure (array, string etc.) and pass that to the native C++ class, or, the other way around?
Any ideas on what would be considered best practice...?
UPDATE:
I know I can re-write the native C++ code from scratch, but it means duplicating the code and prevents me from easily reusing any code updates with any Win32 application. What concerns me most is the best way to marshal the various data between the managed and unmanaged world. To me, a mixed mode DLL looks like the most flxible option, but I'd like to get a different perspective on the potential pitfalls.
Why not just use .NET directly? It seems to me like your problem arises from the fact that you are dependent on the original native library, but you don't mention that it can't simply be re-done in .NET.
As for .NET-native interop, PInvoke is messy, but it does work. I'd go with that if you can't change the original DLL into .NET.
Option C gives you the least work if the marshaling turns out to be simple and easy for the framework to handle (is everything blittable?). It also gives you a place to hook in your own marshaling. I wrote something about this ages ago marshaling between date types etc but I think today I would write a marshal_as<> overload between your managed and native types. It would be the most elegant solution and also the least code.
Update: found my old article - it was for PInvoke. http://codeguru.earthweb.com/columns/kate/article.php/c4867/
I do have to say I'm fairly inexperienced when it comes to C++, don't be too harsh on me.
Recently stumbled unto the wonders of the win32 API and have chosen to practice using it (I'd rather not use MFC/wxWidgets/etc at this point, just for educational purposes).
Well, my real question is:
How do you properly code your win32 GUI stuff into classes. I mean, sure, you can make a class that saves individual window handles, allows for easier modification of window properties, has a more simplified version of CreateWindow(). But as I understand it you will need a messagepump and several callback functions for your created windows. How does that work when combining them with classes?
Could anyone point me in the right direction here? I don't mind reading (a lot of) example code as long as it is commented.
PS: I'm also having trouble finding good (read: easy) documentation on using 'resource files' for my window decorations. Bonuspoints for that! :)
I program in C++ for a living. I like C++.
That said, your life will be so much easier if you do your windows GUI in something .Net, e.g., C#. Win32 is very low-level and you will be building tons of stuff that you will get for free with the .Net libraries. Win32 is not a wonder, anymore. :-)
If you want to learn C++, pick something other than a GUI to do with it.
I personally would use MFC instead of reinventing the wheel here. However, if you insist you need to have an application object that is instantiated when the program is run and contains the message loop and a mechanism for forwarding messages to the correct window objects.
That's the way MFC does it, at least. I'm not sure if the MFC source code is available for download, but if you have access to Visual C++ install disks (any version) you should be able to install the source code on your computer to review.
The biggest problem I faced back when I used the Win32 API (have since moved on to Linux and cross-platform solutions) were the callbacks. Especially the winproc one, AKA the message pump. I found this, which should be a good hint. I did what that page suggests when I rolled my own wrapper.
Look at MFC or ATL/WFC. If you want to re-invent the wheel, the best reference source for how to do so is the wheel itself, especially since the source code is readily available.
I would suggest reading Windows++ by Paul Dilascia. It takes you through the whole process of building a class library in C++ on top of the Windows API. It's written for 16-bit Windows, but all of the concepts presented in the book still apply. Plus, you can get it really cheap since it's "out of date".
And make sure you learn about message crackers (#include <windowsx.h>), they will keep you from pulling out too much hair. ;-)
The best way to learn this is to go and readCharles Petzold's original book. He does a good job of showing how to set up the base message loop and how to build statements for routing the various events to handlers. The real problem here is that by reinventing everything you are going to be spending hours and hours writing and debugging windows event hanlding code instead of writing your own application.
Unless you have a compelling reason for doing this yourself, you woudl be far better served using someone else's construct like MFC.
The only reason I see for coding all this yourself is if you want a basic understanding of how it works before you switch over to MFC or something similar. At least this way you would see how it works under the covers before you can forget it forever.
Many years ago, I developed a set of classes to encapsulate the API (various reasons why we couldn't use MFC). I learned a lot from the MFC source code.
The big key is that every window has a UserInfo data member - you can use it for whatever you want. What you'll want to use it for is the class's this pointer.
Now, the other tricky thing is that the message handler callback function cannot be a normal class member function, as Windows uses C calls and not C++. So your callbacks must be statics. However, since you've saved the class's this pointer, its just a matter of getting the class's userinfo, casting it to your class's this pointer and then calling whatever (non-static) class functions you need.
If you plan it correctly, inheritance will work well, including all of the inheritance that the windows themselves exhibit (ie, an Edit is a Control is a Window).
The only reason I would recommend not reinventing the wheel is you are neither an expert at C++ nor the Win32 API. Trying to learn two unrelated subjects at once will not be productive. If you want to become better at C++, write a library for a subject you know a lot about. If you want to learn the Win32 API, program it raw to understand how it works before creating (or using) a wrapper for it.
There is a pretty good C++ Windows API tutorial on the Reliable Software site.
I'm all for language diversity, but Objective C is insane. So I'm curious: is it possible to code iPhone apps with C++ while using the Cocoa API, etc?
Although Objective-C does indeed appear to be "insane" initially, I encourage you to stick with it. Once you have an "a-ha" moment, suddenly it all starts to make sense. For me it took about 2 weeks of focused Objective-C concentration to really understand the Cocoa frameworks, the language, and how it all fits together. But once I really "got" it, it was very very exciting.
It sounds cliché, but it's true. Stick it out.
Of course, if you're bringing in C++ libraries or existing C++ code, you can use those modules with Objective-C/Objective-C++.
Short answer, yes, sort of. You can use Objective-C++, which you can read about at Apple Developer Connection.
If you know C++ already, learning Objective-C would be pretty simple, if you decided to give that a try. More info on that topic is at the ADC as well.
I use Objective-C to slap the UI together.
But the hard guts of the code is still written in C++.
That is the main purpose of Objective-C the UI interface and handling the events.
And it works great for that purpose.
I still like C++ as the backend for the code though (but that's mainly becuase I like C++) you could quite easily use Objective-C for the backend of the application as well.
First off, saying Objective-C is "insane" is humorous- I have the Bjarne Stroustrup C++ book sitting by my side which clocks in at 1020 pages. Apple's PDF on Objective-C is 141.
If you want to use UIKit it will be very, very difficult for you to do anything in C++. Any serious iPhone app that conforms to Apple's UI will need it's UI portions to be written in Objective-C. Only if you're writing an OpenGL game can you stick almost entirely to C/C++.
Having some experience of this, you can indeed use C++ code for your "core" code, but you have to use objective-C for anything iPhone specific.
Don't try to force Objective-C to act like C++. At first it will seem to you this is possible, but the resulting code really won't work well with Cocoa, and you will get very confused as to what is going on. Take the time to learn properly, without any C++ around, how to build GUIs and iPhone applications, then link in your C++ base.
You have to use Objective C to interface with the Cocoa API, so there is no choice. Of course, you can use as much C++ as you like behind the scenes (Objective C++ makes this easy).
It is an insane language indeed, but it's also... kind of fun to use once you're a bit used to it. :-)
I'm not sure about C++, but you can definitely code iPhone applications in C#, using a product called MonoTouch.
You can see this post for detailed discussion on MonoTouch Vs Obj-C: How to decide between MonoTouch and Objective-C?
I'm in the process of porting a computation-intensive Android app written in Java to iOS6. I'm doing this by porting the non-UI parts from Java to C++, writing the (minimal) UI parts in Obj-C, and wrapping the former in a (small) C interface using the standard C/C++ technique, so that it can be accessed from Obj-C, which is after all a superset of C.
This has been effective so far, and I haven't encountered any gotchas. It seems to be a legitimate approach, since Xcode lets you create C++ classes as well as Obj-C classes, and some of the official sample code does things this way. I haven't had to go outside any officially supported interfaces to do this.
There wouldn't seem to be much to gain from writing my remaining UI code in C++ even if it were possible, in view of the help given to you by the interface builder in Xcode, so my answer would be that you can use C++ for almost all your app, or as much of it as you find appropriate/convenient.
Yes but Thinking that you can program every kind of program in a single language is a flawed idea unless you are writing very simple programs. Objective C is for Cocoa as C# is for .NET, Use the right tool for right job, Trying to make C++ interact to Cocoa via writing bridging code and trying to make C++ code behave according to Cocoa requirements is not a good idea neither expecting C++ performance from Objective C is. You should try to layout design and architecture of app keeping in view existing skills and determine which part should be written in which language then build accordingly.
I'm currently writing an Objective-C++ framework called Objective-X, wich makes PURE C++ iPHONE PROGRAMMING possible. You can do like this:
#import "ObjectiveX.h"
void GUIApplicationMain() {
GUIAlert Alert;
GUILabel Label;
GUIScreen MainScreen;
Alert.set_text(#"Just a lovely alert box!");
Alert.set_title(#"Hello!");
Alert.set_button(#"Okay");
Alert.show();
Label.set_text(#"Ciao!");
Label.set_position(100, 200, 120, 40);
MainScreen.init();
MainScreen.addGUIControl(Label.init());
}
and compile it using GCC's appropriate commandline options. I've already compiled this helloworld app&it w0rkX0rz like a charm. ;-) It'll available soon on GoogleCode. Search for Objective-X or visit http://infotronix.orgfree.com/objectivex approx. a week later!
Updated (but apparently inactive) URL: http://code.google.com/p/objectivex/
It may be a bit offtopic, but anyway. You can program c++ right on iOS devices. Check out CppCode ios app - http://cppcode.info. I believe it helps to learn c and c++ and objective-c later.