Can I integrate Flurry into DirectX (no C# code) WP8 app?
Flurry docs have some instructions, but they are for C# app. I have a FlurryWP8SDK.dll and I don't know is it possible to integrate it into my project.
Unless Flurry comes out with a C++ SDK you can't integrate Flurry in a pure Direct3D app. You could however use the Direct3D with XAML app template. http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj714079(v=vs.105).aspx
You will still get good Direct3D performance, and will have most of your code in the C++ WinRT component. Having the C# layer will allow you to integrate Flurry, and you can pass down delegate functions from the C# into your WinRT component so that your C++ code can log events with Flurry.
Edit: I wrote a blog post about this topic with some code examples - http://robwirving.com/2014/07/21/calling-c-methods-c-winrt-components/
Related
My company has many old projects that are written in vb6. We have some reusable software components which are written in ATL/C++. We're now considering to rewrite our app with UWP but it seems that UWP apps do not support the old COM technology. I am researching if there is a way to implement a COM object which also supports UWP. I understand that porting our old components to UWP Components would definitely work. But we do not want to maintain two version of common components because we have shipped many old software and we still provide software support. Some of those software have been used by our customers for more than 10 years. It is impossible to upgrade all software we have shipped.
I have come up with few possible solutions:
Desktop Bridge
I have found a phrase called "Packaged COM" which can be used by UWP apps with Desktop Bridge. This article, COM Server and OLE Document support for the Desktop Bridge, gives an example of calling an exe COM server from an UWP app. It seems to be a good solution if it also supprts InProcessServer. I did found something suspicious, InProcessServer, but it turns out that it is for WinRT components.
I have also tried to add the COM reference to the UWP project. The code can successfully refer to the COM object. However, it doesn't work at runtime. The UWP app has its own registry hive, therefor is won't load the COM object which is registered to the system registry. I'm thinking that if I add the registration information to the private hive of the UWP app and pack the COM dll along with the app, this may work. Just couldn't find any example.
ATL/COM
Since we have implemented our business logic into COM objects. The most viable solution would be upgrading our COM object to support UWP applications. WinRT components still use COM technology but implement the new interface IInspectable, I assume that the old ATL based COM object can be modified to support the calling convention of UWP if it implements IInspectable interface. I just don't have any clue to do this.
WRL
I found an MSDN article, How to: Create a Classic COM Component Using WRL, talking about using WRL project template to implement classes COM object which can be used in Win32 application as well as UWP apps.
It says:
You can use the Windows Runtime C++ Template Library (WRL) to create basic classic COM components for use in desktop apps, in addition to using it for Universal Windows Platform (UWP) apps
But I soon realise that WRL project template is no longer supported by Microsoft. All the download links of the project template I found on the web are no longer available.
C++/WinRT
This technology seems to be the successor of WRL. It seems promising but unfortunately have not yet been released.
To clarify few things from #Peter Torr:
(1) Do you want your app / COM object to be "pure" UWP (runs on all
devices) or are you OK with fullTrust UWP (aka Desktop Bridge) that is
Desktop-only? And (2) are the COM objects only for use with the app
that ships them, or are they supposed to be used by other apps?
My company uses Windows platform to provide PC-based industrial automation services(both hardware and software). So the answer is yes, we are happy with fullTrust UWP. Our products will only run on desktop. We just want to embrace the new technology and leverage the great UI framework of UWP.
COM objects are for both new apps(UWP) and old software(some are vb6 based). We are happy with packaging COM objects with UWP apps and using system registered COM for old software as long as those COM objects are the same(built from the same code base).
guys! I'm currently working on new cross-platform application (iOS, Android, UWP). I have graphical library for UI written in c++, using freeglut for opengGL.
The problem is, I don't know how to use this library in my UWP application. I have read a lot of information about all the wrappers for OpenGL, but they all for WPF or written in C++. I also know about Microsoft ANGLE Project, but it is written in the c++ too, but I need to write the application in C# language.
So, how can I modify my own library using excluding freeglut and import it into my C# application?
By the way, sorry for mistakes in my English.
So you want to consume your legacy C++ assembly in your UWP application?
You can create a Windows Runtime Component(Universal Windows) project, in which you need to include the assembly, and declare as many APIs as you want to expose, all marked with DllImport attribute.
Eventually, this WinRT component will do the Platform Invoke, and works as a "wrapper" layer between your legacy code and UWP application.
It's up to your preference which language you use for the WinRT component, C++ or C#, either way, you need to worry about struct/type mashalling and unmashalling.
After you're done with above, you'll be able to reference the WinRT component in your UWP application, and call the APIs you declared in that assembly.
The same way works for Microsoft Angle project as well.
You might find this post useful.
One last word, you might want to avoid using forbidden APIs, otherwise your UWP app won't pass the Windows Store Certification.
According to https://msdn.microsoft.com/library/windows/desktop/jj714080.aspx there is an option to use DirectX and some native API functions including LoadLibrary and GetProcAddress functions https://msdn.microsoft.com/library/windows/desktop/jj714080.aspx
This should give you ability to use any native dll.
You can try to make RuntimeComponent project and put it there. Also you can try clr oldsyntax option to use native code as it is.
So I look at this (Windows build keynote 1:42:56) And I just do not get it - what I can use to create GUI from C++ and/or GUI language that will be capable to call functions from my C++ code? HTML, XAML or what? And where to see code sample of doing markup call code and code create GUI sample with C++ for Windows 8 Metro apps?
Sample code in C++ and other languages is at http://code.msdn.microsoft.com/windowsapps. You can take a look at how it's done.
If you want to call C++ code the easiest way will be to use C++ with Component Extensions. This is just plain C++ that compiles to native code however it has a few extensions (reminiscent of C++/CLI) that let you use the WinRT COM components without worrying quite so much about the COM plumbing.
With C++ and WinRT you can actually use XAML like the managed languages to define your user interface. It's pretty neat, see the documentation here:
Information on C++ component extensions
I haven't looked into it but you may still be able to use P/Invoke or COM interop in the managed languages to call C++ code for a Metro style app however this is unconfirmed. Obviously a desktop app can do all the things it normally would.
You can use C++ code to write metro style applications. You can also write applications in Javascript/HTML/CSS and call APIs that you write in C++ or C#/VB from those JavaScript applications.
I am interested in using Javafx for my visual content for a desktop application and call native,unmanaged C++ functions ( on events from the Javafx views). Is this possible? Can someone explain with an example?
As JavaFX has been designed for maximal compatibility with the Java platform, you can always call Java code from your JavaFX code, and then do some JNI stuff, as in this example question.
I'm looking at a new project where both Native and Managed approaches sound like a good idea. This is a Windows desktop application which should support an MDI interface. The client area will make extensive use of Direct3D. The developers on the project are equally skilled on C#, C++/CLI and MFC.
MFC Advantages:
Doc/View Architecture
Most Direct3D online resources still use C++
Managed Code Advantages:
The .NET Framework
C#
What more can I add to the lists above? Don't flame this. Two lists. Just add to them.
Note: I have very good reasons (to do with the IDE and debugging) not to use mixed mode. So count that out.
Why not use both?
You can write the UI (forms) using C#/VB.NET and render the window using C++.
Basically all you need to do is pass the HWND (Window Handle) from the C# to the C++ and initialize the C++ using that value.
You can see an example on my blog: How-to Render managed (.NET) form using native DirectX
This doesn't directly add to either list, but the current "recommended" way to do 3D with .NET is using XNA - Managed DirectX is being deprecated.
Edit: Of course, WPF 3D is also an option! Forgot about that :}