I have a C# XAML UWP project, and I need some 3D stuff in it.
So I figured using DirectX (which requires C++) is the way to go.
So I want to make a new C++ project that builds to a DLL, and use that in my C# project.
But I can't figure out what Project type to use for that. There are types for libraries, and their are other types for creating DirectX apps, but I can't find any that combines the 2.
This may be a stupid question, but I'm really not that familiar with Visual studio, project templates and building dlls.
You don't need C++ to have 3D in your C# project.
Just google 'directx in c# tutorial'. Also DirectX is not your only option for 3D. You may want to look at OpenGL. Make sure you go through a few tutorials to get some understanding of 3D stuff.
I ended up using the "Windows Runtime Component (Universal Windows)" template.
I don't know if it's the best choice, but it works.
Related
I want to use simple plotting functions in my C++ code. Presently I am using Qt5 with VS2010 c++ compiler. I came across this library called koolplot. But I cannot buid it with VS2010 from its source files. I am opening vs2010 cmd and running nmake...It shows winbgim.h missing..I copied that header in MinGW include folder and ran it ...now it shows "Plotdata.h:warning: 'typedef' was ignored in this declaration" Please help...if any one knows a simple plotting library running with VS2010 please suggest..
According to its website, Koolplot is designed for the MinGW/gcc toolchain - you'll have to do a bit of leg work to get it to compile on Visual Studio, though I don't know specifically what you'd have to do without taking a closer look.
Also, the library seems to do its own window management and the like, so I'm not sure how well you'll be able to integrate it with Qt.
koolplot needs WinBGI library (BGI = Borland Graphics Interface?).
I have changed it to use native Win32 using VS2008:
http://www.tu-chemnitz.de/~heha/hs/koolplot-heha.zip/
It's still incomplete as a good Win32 implementation would implement koolplot in a DLL which self-registers a Window class, and has both C and C++ interface. Moreover, koolplot as-is doesn't support multiple scales, finer plotting options, GDIplus, and fast data update, so it's not the right thing to write an oscilloscope program.
It's C++ code is also outdated as there are lambda functions available now.
However, good integrating into Qt is another task.
Our VB6 program currently calls code in a C++ dll. This dll does not need to be registered, it only needs a .def file specifiying the properties and methods. Vb6 late binds to it. The dll is written in VS2005 without a dependency on the Net framework.
As we are migrating our application to Net4 and also want to enhance the C++ dll with new functionality, I was wondering how to migrate the existing C++ code to VC++. I suppose thereafter the dll will just happily integrate in our solution which already contains C# and VB.Net libraries too.
Is there some tutorial/documentation about the do's and don'ts of this plan?
EDIT:
I think I have some basic misunderstanding about VC++, thinking that it can be ported to 100% managed code while keeping the C++ syntax. The replies I get seem to indicatie that VC++ will always produce native, unmanaged code?
From a pure C++ point of view, you should be able to convert the VS2005 solution and project to VS2010 automatically. If I recall when you load the solution or project into VS2010 it will automatically convert it for you.
If you open the VS2005 project file in VS2010, VS2010 will automatically convert the old project to the new project format and the auto-conversion will do it's very best job to get everything correct. This usually works, but not always. So the moral of the story here is, double-check all of the new project's compiler/link settings, to be on the safe side.
Also with VS2010, you have some better interop possibilities between managed and native code: P/Invoke and C++/CLI. P/Invoke is simpler, but you will find that stuff may compile but fail at runtime. C++/CLI is way more flexible, a bit more work, but makes it much easier to debug the interop, when it becomes necessary.
I got another crazy idea: why do I want to create a static lib in XCode, then create monotouch bindings for it then linking this lib with monotouch project. That would be much easier to have all the sources in a single project...
I'm trying to have Obj-C, or C or even C++ sources right in monotouch project compiled all-together. But apparently I got no luck with that. I can't make C code to compile from monodevelop.
Does anybody tried this approach? what are pros and cons (if it is possible)?
You're right that you can have several projects, in different languages, inside a single MonoDevelop solution.
However you'll still need to create bindings to access non .NET code (e.g. C/C++) and data from the main (C#) project solution.
So having a single solution can be a bit simpler in many cases but it won't be a lot simpler - unless you're using .NET for every projects.
Note: there are now binding solutions templates in MonoDevelop that can make binding non-.NET code simpler. That's more likely yo help you.
I've always been developing simple(console) apps. And even then most problems I had was with starting/porting/CMaking/ libraries to work.
I need to find a gui which is added/used by adding #include "somelibrary.h" to EXISTING c++ project. I've downloaded QT, but it seems I have to create a new QTproject,... and thought alone of including all CUDA,OpenCV,others is making me sick.
I've been experimenting with windows forms (.net?) but there is this managed/unmanaged border with its creepy bugs.
So I'd like to add GUI to existing project (where forms can be designed in completely separate designer).
Do you know any?
Or maybe You'd suggest me different approach?
I suggest you to use CMake and Qt. CMake is better than qmake to manage projects and use additional libraries. Currently Qt is the best multi-platform GUI API.
QT and winforms can be added on to an existing project but it's harder that taking a gui application and adding your project to it. Event driven code is organized differently than procedural code.
You don't need CUDA or OpenCV for a GUI.
I have inherited an old C++ (MFC) project and will have to add new functionality.
The new functionality will mostly not conflict with the existing C++ code, like additional dialogs etc.
Having limited experience with C++ MFC, I would very much prefer to do the additional functionality in Delphi, create a DLL and use the DLL in the C++ project.
I guess this is generally possible, similar to using C++ DLLs in Delphi?
Are there limitations on what can be done this way?
Basically, there are no issues. But if you're going to use dialogs and so on, your application will be using two frameworks, MFC and the VCL, and they may not play very well together.
Delhi if I recall my history should create Dll's happily. See here 'Calling delphi DLL from MS Visual C++' for an example