I need to develop common UI which will run on both desktop and metro.
Is this possible.I wanted to use same code for UI both in desktop and metro app
I know that Win RT is Supported on both desktop and metro.
I believe your question is about creating an application that works like both Metro Style and also as a traditional desktop app. What you need to do is to wrap all your business logic code into a WinRT DLL and create two different UI applications one using XAML and another using windows Form and consume the DLL.
But ideally you cant have a single exe that runs like a native app and a metro style app, you should have two exe's.
Another thing is the native app which you develop in this manner may not be backward compatible because in build conference i remember them saying WinRT is only from Windows 8 onwards. so you cant run your native app in Windows 7.
Related
I am investigating the option of using chromium embedded framework in C++ desktop application to implement new HTML views.
The issue is all the GUI are implemented using QT Framework.
so can chromium embedded framework be used with QT ?
I want some of the views to be implemented using QT while others using Chromium Embedded framework.
First I considered the option of using QTWebEngine but license is not free for commercial use however Chromium embedded framework is an open source
Just have a look at this project,
https://cefview.github.io/QCefView/
QCefView encapsulates CEF and works for all desktop platforms
I searched the documentation for the winrt namespace and didn't find any console functions, i.e AttachConsole. I wonder if there is, for a UWP windows console project (C++/winrt)?
UWP has three 'app models':
A XAML app with C# or C++ code-behind
A Direct3D app
A Direct3D + XAML app
There is no support for 'console windows' in UWP.
I've 'faked' a text console for UWP test apps and samples using the Direct3D app model (see directx-vs-templates for the basic render loop), DirectX Tool Kit, and my TextConsole utility.
You can invoke most Windows Runtime APIs from any win32 console applications as well as packaged console applications (a relatively new feature) but there are no Windows Runtime APIs that provide control of the console or console-specific behavior at this time.
Thanks,
Ben (MSFT)
Currently I'm working on a simple game engine project. I would like it to be independent from the platform, so for started I've taken only classical Windows Desktop application and Metro Style app.
From this picture:
Windows APIs
We can see that the C/C++ blocks are common for both parts. In other words, I would like to easily switch between platform configurations. I've created simple WinAPI static library that you can easily include in the project, as well as DirectX game-engine and it works perfectly. However, I'm having issues to do the same with WinRT (used in Metro Style apps).
Is it possible to have one Visual Studio project that can use WinAPI or WinRT? It would be perfect if I could have like one single entry point for a game and just switch underlying APIs.
No. A single VS project that either generates a classic win32 exe and a WinRT (nowadays Universal) applications is not possible.
In theory they could have made it possible, like you can have a single project that generates a console application or gui application. The difference between the two boils down to one (or two) flags.
The difference between a classic exe and a WinRT app is quite big: There are manifests and packaging and special sauce signing not to mention the resources (icons, etc) are specified differently.
In the Visual studio UI this is manifested by a different set of property pages, besides the common core of compiler + linker ones of course.
The other reason is one of strategy. Microsoft wants you to move forward and embrace the WinRT API. That is the API set that works across all Windows devices (if you ignore the Win7 elephant in the room). Supporting a dual mode will send the wrong signal to developers.
As a side note that the very windows headers (windows.h) are annotated by API family. CreateNamedPipe is #ifdef out in a WinRT application, or for example there is CreateFile for classic apps and CreateFile2 for modern apps.
We have a C++ desktop application using an old MFC GUI; we would like to move it to a Windows App.
We use some sdk (for GigE cameras, CameraLink grabbers, vision libraries) that need msvcrt and shared mfc dlls. Including <afx.h> in a Windows App does not work.
Could be a solution packing everything in WinRT components or there are simpler ones (or none at all, and we must stay within desktop apps)?
MFC cannot be used in a Windows Store app. The only option is to eliminate use of MFC from the components that you would like to use in a Windows Store app.
I have experimented with XAML UI programming using C++ for Windows 8 Store apps. I really like the developer experience, the XAML designer and the fact that I can get pure native apps with a modern rich user interface and high performance.
I want to create similar XAML apps using C++ for Desktop Windows (the non-Store world). How do I do this? For years I have waited for a native UI stack for Windows Desktop which is newer than MFC and somewhat higher level than direct Win32/GDI programming.
Both Silverlight and WPF use XAML along with code-behind to implement apps. Neither are still maintained but if you want to play with the same technology, it's there.
As Jeff McClintock mentioned, Microsoft has announced that a future update to Windows 8 will allow apps to run on the desktop, but I expect that this will merely be a windowing change and the apps will still run in the restricted sandbox that Store Apps run within. Maybe Microsoft will introduce yet another desktop-based UI framework and support it for three years before killing it.
WTL is newer than MFC, although its last update was six years ago. I personally recommend Qt, as it allows access to native Win32 calls (so you can do whatever ganky stuff Win32 apps normally want to do) while still having a rich, robust UI framework to build upon.
A future update to Windows 8.1 will allow Windows 8 Store Apps to run in a Window on the Desktop, and appear on the taskbar like a Win32 Application. This allows Store apps to Act a lot like Desktop Apps. MS have hinted store-app XMAL will be available to Desktop apps at some point in future.
http://www.gottabemobile.com/2014/04/02/microsoft-listens-to-users-start-menu-and-windowed-apps-are-on-the-way/
Codejock has some markup language support in MFC (native C++).
http://www.codejock.com/inc/img/downloads/samples/toolkitpro_markupsample_full.png
What I am looking at is C++/WinRT for native C++ applications that use the WinRT framework for UWP apps, at least for Windows 10. See C++/WinRT in the Microsoft Dev Center for a starting place.
C++/WinRT is an entirely standard modern C++17 language projection for
Windows Runtime (WinRT) APIs, implemented as a header-file-based
library, and designed to provide you with first-class access to the
modern Windows API. With C++/WinRT, you can author and consume Windows
Runtime APIs using any standards-compliant C++17 compiler. The Windows
SDK includes C++/WinRT; it was introduced in version 10.0.17134.0
(Windows 10, version 1803).
The intro article in the series goes on to say:
For authoring and consuming Windows Runtime APIs using C++, there is
C++/WinRT. This is Microsoft's recommended replacement for the Windows
Runtime C++ Template Library (WRL) and C++/CX.
I first got started with UWP apps for Windows 10 using C++/CX which uses the Microsoft Visual Studio C++ extensions with ref and all of the C# like extensions for C++ in a .NET world.
I am now working with Visual Studio 2017 and the C++/WinRT framework which uses native C++17 features along with an SDK. I believe you can also use C++/WinRT with Visual Studio 2015 with the latest updates, update 3.
There is also a package available from Extensions and Updates within Visual Studio, C++/WinRT, which contains a couple of Visual Studio templates for a couple of different application types.
C++/WinRT seems to be a work in progress. It seems best if you are using Visual Studio 2017 with the latest Windows 10, Version 1803, which contains the SDK and the XAML editor works fine. I have had problems with the XAML editor with an earlier build of Windows 10 Enterprise at work (IT Services maintains its own update servers and is a couple of builds behind the bleeding edge).
See also my question synchronizing SDK with Windows 10 update and using WinRT with Standard C++ which has an updated version of a test program from this article, C++ - Introducing C++/WinRT.