Scenario:
I am trying to migrate a C++ application to WinRT/Metro Style. This application uses an ATL/COM object that implements an IDispatch interface by using the class IDispatchImpl, however, according to MSDN IDispatchImpl is not available for Metro Style applications.
My ATL/COM class looks like this:
class MyATLClass :
public IDispatchImpl<IMyDispInterface, &IID_IMyDispInterface, &LIBID_MYLIB, 1, 0>,
public CComObjectRoot,
public CComCoClass<MyATLClass,&CLSID_MyATLClass>
{
...
}
Question:
Is there any replacement in WinRT for IDispatchImpl?
The replacement could involve deriving from different classes and discarding my IDL file for example. My ultimate goal is just to be able to do QueryInterface on an instance of MyATLClass and get a reference through IMyDispInterface. I can also include all my files (library and application) in a single project, but I do want to avoid changing the code where IMyDispInterface references are used if possible.
Re-implementing my COM/ATL class as a WRL based component is probably the best choice in this scenario (Thanks Larry). More information is provided on these video posts:
Porting a desktop app to a Metro style app
The Windows Runtime Library (WRL)
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).
Currently I have a Credential Provider implemented in C++ and I would like to incorporate BLE communication to it. This is provided in Windows 10 by the UWP class Windows.Devices.Bluetooth.GenericAttributeProfile.GattServiceProvider.
I tried to load to make a UWP DLL implementing the function and load it using LoadLibrary but got an ERROR_NOT_APPCONTAINER
Is it possible to use the UWP APIs from some unmanaged C++ code?
You can not load UWP dll inside of desktop application. However it is possible to use many UWP APIs directly as they are essentially COM-based. Typically anything not depending on application context and having public activation factory (constructor) can be used. For example see How to: Activate and Use a Windows Runtime Component Using WRL.
I'm planning to write a cross-platform project in C++, which will run a Lua engine. I'd like to write the main program for that project including the GUI in Lua. And to make it even easier, I want to write the GUI in HTML and therefore I need an additional library, hopefully QtLua which is based on Qt.
From what I heard, implementing QtLua into the Lua engine shouldn't be too hard and Qt has a nice class called QWebView that should allow me to write HTML GUIs. But I'm wondering about 2 things:
Is it cross-platform capable?
Is QWebView even part of QtLua?
Answers to both questions i think you should find here http://www.nongnu.org/libqtlua/
There's this part that says
QtLua is not designed to develop an application in pure Lua but rather to extend a Qt C++ application using Lua as scripting language.
Therefore, if your application is built/based on Qt and only extended using Lua, it should be cross-platform capable.
And for your second question; QWebView is used to view and edit web content, QtLua or QtScript is used to provide support for application scripting. QWebView is not part of QtLua plus i don't see any member of the QWebView class that has any connection with scripting
I am about to create an application. I would like to keep it in modular architecture and to work on Linux, Mac and Windows. I want to use Qt library in general.
The most of the functionality of this application will be stored in plugins, which for some reasons is the best approach here. I am used to create plugins on C++. However I am considering to use Qt plugin management system.
My questions are:
Can this system be used to manage any kind of plugins? What I mean is that most (all I've run into) examples cover plugins regarding Qt styles and Qt elements, etc. No general plugin managemet like "Foo" plugin doing "hello world".
Are there any advantages of "manually created" pure C++ plugin system over Qt plugin system? Should I rather consider using pure C++ approach?
Qt offers a generic plugin system, and you can leverage it for whatever use you desire. The documentation has it covered.
Qt's low-level plugin api works on interface classes - classes with abstract virtual methods. A plugin implements such interface. The plugin loader gives you an instance of an interface-derived class that implements the interface.
Do you know any tutorial for creating MFC ActiveX objects that can be used in JScript or VBScript (Windows Script Based Host)?
I mean an OCX that can be used as:
var x= new ActiveXObject("name");
and NOT this:
<object id="xxx" classid="CLSID:xxxx">
so far everything that I found just allow using an activex with html tags and they fail to initialize with script engine.
Just to add some extra options:
1. Old vb6 was adept at creating ActiveX/COM components quite simply.
2. Other languages like Delphi and PowerBasic can easily create components too.
3. VBScript can be used to create com components which are packaged in a com wrapper WSC (Windows Script Component). This contains your class and code and is usable as a COM object. The WSC uses an external Script Component Runtime to execute your script when called via COM. The actual internal code can be written in other script languages, such as jscript or python or a number of others.
As far as getting started goes, I highly recommend you check out A Beginner Tutorial for Writing Simple COM/ATL DLL and Using it with .NET by ThatsAlok.
I've tried a number of different techniques in creating ActiveX objects, and, I found the ATL C++ to be one of my favourites. The key essentials of the tutorial are:
Utilizing Visual Studio ATL Simple Object wizard
Naming the interface in C++ (e.g. ISimpleCom)
Choosing a progid (e.g. SimpleATLcom.SimpleCom)
Letting Visual Studio generate as much code for you as possible
Registering your COM DLL
Some things the tutorial doesn't cover is:
Avoid Project Build Error PRJ0050 by registering your COM DLL using Per-user redirection which Visual Studio 2008 supports (see Microsoft MSDN article on Linker Property Pages)
Invoking in JScript / VBScript from Windows Script Host / HTML
The latter, you already know how to do that, but, for completeness. In JScript, it's:
var obj = new ActiveXObject("SimpleATLcom.SimpleCom");
And, in VBScript, it's:
Dim obj
Set obj = CreateObject("SimpleATLcom.SimpleCom")
FireBreath plugins can be used that way. It doesn't use MFC, but you haven't specified why you need to use MFC.