I'm new to windows phone development, and I need to create a control with C++ (basically it's a WebBrowser control) I would create with C# but the library I need to use for core is written in C++.
Conclusion: So the question is, Can I develop a control in C++ using external libraries and then compile it to use with any language of the CLR and use it in my windows phone 8 applications? If does, let me know about some resource any video, book, or whatever.
The general answer is "yes", although it comes with some caveats.
It's certainly possible to build a component in C++ using the Windows Phone Runtime APIs and then utilize it from another programming language, such as C#. The more "pure" the C++ code is in that it doesn't access native operating system features (that may not be present), the better off you'll be.
There's some general guidance on MSDN:
Native code for Windows Phone 8
Windows Phone Runtime API
Using Native C++ code in your Apps
That being said, if you're attempting to create an entirely new web browser for some reason, I'd strongly suggest you consider using the built in WebBrowser component. In Windows Phone 8, it's based on IE10, and in Windows Phone 8.1, it's IE 11. Those are both very capable browsers and designed to work well within the memory constraints of the platform.
Related
This question already has answers here:
How do I build a graphical user interface in C++? [closed]
(8 answers)
Closed 6 years ago.
is there a way of creating a classic GUI with cpp like for the case of JavaFX? I want to create elements like floating buttons, tables, graphs, etc. I know of tools like qt but I'm not ok with it. I tried win32 API but it's only for Windows.
GUI libraries are generally called "widget toolkits", and there are a variety of cross-platform GUI widget toolkits available, however they are rarely a good idea for a great UX because different operating-system environments have different UI paradigms (e.g. how macOS and Ubuntu has a single always-on menu-bar at the top, whereas Windows and other Linux desktops do not).
So you have two fundamental choices to make:
Use a single cross-platform GUI toolkit - which means creating a single GUI project, but restricting you to that toolkit's selection of controls and functionality, and generally subjecting your users to a (relatively) poorer user-experience, either because your toolkit does not use native widgets (e.g. Java, WPF, Qt) or because you cannot use a platform's native paradigms.
Write a new native GUI for each platform. This means more work, but a better user-experience.
For cross-platform GUI toolkits, the main options are:
Qt
GTK+
WxWidgets
For a comparison between the three, see this QA: Which, if any, achieves Windows native look: GTK+, wxWidgets, Qt, FLTK?
(TL;DR: WxWidgets uses native controls but is difficult to develop with; Qt offers the best developer experience but has many other bullet-points which you need to be aware of)
For a native UI for each platform you need to target, you'll need to familiarize yourself with each API:
Win32:
MFC (the API is ugly by modern standards, but does encapsulate the main Win32 UI paradigms and APIs, such as Common Controls. However, be prepared for an uphill fight to support latter-day UI features, such as High-DPI, bi-directional text and high-quality 2D rendering. GDI/GDI+ is on the way out, which means using Direct2D - which is fun because MFC assumes GDI)
UWP/XAML: If your application can be sandboxed (and run only on Windows 10) then you should take a good look at UWP/XAML (it's all native, so the CLR is not involved).
WPF: Using WPF makes it easier to create a high-quality user-interface, if you're comfortable with your application taking a dependency on the .NET Framework and writing UI code in C# - however the visual aesthetic of un-skinned WPF apps took a nosedive with Windows 10 (i.e. they're ugly) and WPF's default control set is very aneamic - but if you have the means (i.e. time, money, people) then you can get great results - and as a bonus the XAML for WPF is generally portable to UWP.
macOS: Cocoa - you will have a hard time doing this in C++. If you're targeting macOS I strongly suggest writing your UI layer in Swift (or Objective-C if you have to) and then linking-in to the rest of your application code using C++ bridges.
Linux: As Linux is just a kernel the set of "native" widgets depends on the desktop environment of the user - but most desktop programs seem to use GTK. And if you're going to use GTK then you might as well use GTK's cross-platform features to support Windows and macOS.
In conclusion: it's difficult and a lot of work. :) - and explains why many software titles today (mid-2017) often built as web-applications either on the web directly (e.g. Facebook, StackOverflow, SalesForce) or hosted webviews using Electron (e.g. Slack, VS Code, Atom) or some other hosted-webiew (PhoneGap apps, Spotify, etc).
I'm trying to attempt to build a UI similar to the ones coming out of Microsoft these days. Particularly those targeting the Windows 10 operating system (a la Office 2016).
Currently I use WinAPI, but all of the controls provided by Windows.h and CommCtrl.h appear to be legacy/old style UI elements. I'm particularly looking for the titlebar/menu/status bar elements (the main clientarea will consist of a GDI/Direct2D context, so nothing special necessary there).
I found some information pointing to XAML, but I don't think that's what I want. WPF seems to be a more likely candidate, but I'm not sure if that's the case either.
I would like for this to be 100% native (WinAPI/C&C++), but if there's absolutely no other option I can use C# for the UI and stub in the native code.
You use XAML and either C++, C# or JavaScript to write a Windows Store (previously Metro) app. If you use C++, the app is 100% native, but if you use C# or JavaScript, of course the required virtual machine is used.
The API that your code calls is WinRT, which looks like Silverlight. In addition, your app can also call some, but not all, Win32 API's similar to how .NET apps can call Win32 (e.g. By using P/Invoke). However, even if you use C++ and thus your app is 100% native, it is still sandboxed like a browser. Meaning it cannot do things like access the entire disk or write to HKLM in the registry. This is for security; a Windows Store app needs to be safe, and thus more limited, like a mobile app you buy from the Apple AppStore. This means that you can't call e.g. CreateFile. This says:
Minimum supported client
Windows XP [desktop apps only]
When MS mentions 'Desktop Apps' as above, they mean Win32 apps. This excludes Windows Store Apps. But this is confusing, because on Win 8/8.1, these Windows Store apps are full screen, but on Windows 10 they are resizeable and overlapping, appearing next to, and mixed in with traditional Win32 apps like Explorer and Task Manager. So even though they appear on the same desktop as Desktop apps, they are not Desktop apps.
I believe if a Windows Store app also targets Windows Phone 10, Windows IoT, etc. then it is called a Windows Universal app.
I have a service application (no frontend) that was converted from C# to CPP native code not implementing .net framework. This was done to speed the processing and to reduce the footprint.
I am investigating the move to support this service to Window tablet devices. How would I go about this and what obstacles might I meet along the way?
TIA
You shouldn't expect troubles, even Windows Phone 8 will introduce full support for the C++, there is no relevant news that can make you worried about Windows 8 and C++, the only relevant thing is the addition of the WinRT to the usual set of C++ libraries for Windows but is more like an extensions rather than a set of libraries that will suppress something that is already existing in the Microsoft environment.
The only real changes are in the GUI subsystem, as you can expect just looking at the Windows 8 products and in this case under Windows 8, if you want a GUI, you probably do not have other options than switch to the new WinRT.
There is also this link that can be useful.
How can i make buttons in c++ and handle them.
I am targeting win32.
Till now i have no idea of how to make graphical programs in c++ . I have come from JAVA and therefore have no idea of handling c++ events and building GUI
It will be of great help if you give the links to tutorials or could name the books to do so.
C++ is merely a language and the framework and operating system services whcih enables you to make use of the services using C++.
Java contains a GUI framework which has implemented across the platform. When you come to a native windows application, you have to rely on mainly two things, Win32 and MFC(a C++ wrapper of Win32 APIs). Win32 provides C based APIs which expose the operating system services.
For your specific questions I can answre like, You can use CreateWindow() Win32 API or CButton::Create() (MFC) to create a button. Also Visual studio provide a really good resource editor where you can manage the controls and make the message handlers.
The APIs are largely classified in to three DLLs
GDI32.dll - provides APIs for drawing
User32.dll - provides APIs to creates buttons windows etc.
Kernel32.dll - provides APIs to use operating system services like file creation, threading, synchronization etc.
As a Java programmer, it would be easy to adopt C# rather than C++. For you C++ might be going back to stone age where you've to hit the stones and make the fire, where in C# you can enjoy the easiness of a matchbox.
I'd suggest you to read following books to learn basic GUI programming under Windows
Windows Via C++ - (Win32)
Programming Windows with MFC - Jeff Prosise
Programming Windows - Charles Petzold
Making UIs is not part of C++ itself : you'll have to use a framework or rely on something else (like MFC in visual c++).
If you want easier way of building a GUI and manage your events, while still keeping your code portable, I suggest having a look at Qt : it's really good quality and delivered with a bunch of well-done examples. (license is LGPL so as long as you link dynamically, you can license your code the way you like).
A very good book to understand win32 api is http://www.charlespetzold.com/pw5/.
I just wondering about this.It is said that .NET is better than MFC in a lot of aspects.But when I use my PEID to recursive scan my 'program files' directory,it turns out there are still a lot of programs written with 'Visual C++ 6'(esp. for security software),whose GUI should be written with MFC.
So my questions are:
Is MFC still the dominating framework
for windows desktop aplication?
What frameworks do IE,firefox,Microsoft office(or other famouse desktop applications,if you'd like to list some) use?
What frameworks do the desktop applications(e.g. explorer,card games) of Windows itself use?
thanks.
I say windows forms and WCF are pretty widespread. C#/VB.NET are well-entrenched in corporate america.
IE is COM-based.
Office is MFC/COM.
Windows Apps are usually native code to demo the platform.
For new projects I don't think MFC is the dominant platform, but mostly because newer platforms shield developers from the idiosyncrasies of Win32 and MFC itself and allow for faster development. MFC applications take longer to develop but are, imo, unmatched in responsiveness.
I will not deny that some parts of the platform are irrelevant in 2010 (for example CArchive and most of the Doc/View foundation); on top of that, the dwindling availability of 3rd party components (mostly GUI) is a bit worrisome. FP1/MFCNext was a step in the right direction, I'm anxious to learn about the new MFC functionality in VS 2010.
For optimal integration with the OS, imo C++/MFC is still the best choice because of the nature of C++ as low-level and the fact that Win32 is still the foundation of Windows and that it can most easily be accessed in C or C++.
By the way, I had to write code to change screen resolution and found that C# could only handle detecting screen resolution but not changing it.
To change resolution you had to do a lot of Interop gobbldygook which I tried but was too complex because the Win32 APIs to do that had too many old style arguments.
So, instead I wrote a quick MFC DLL that accessed Win32 API directly and wrapped all the calls to Win32 in a simple API. Then I did an interop call to my simple API in an MFC User dll.
Everything worked fine.
So, there's still no substitute for Win32 API. That has the ultimate power, and you have full access to it via MFC. So, yes MFC is still relevant and so is ATL and so is direct Win32 all of which I'm forced to use from time to time.
So, you may get 90 percent of your work done with .NET, but you have to go under the covers for a few things. Also, I've done a lot of Qt, and would never use it for quick jobs that are windows only. Qt also has become prohibitively expensive if you're doing anything commercial and also it is very very bloated. It's libraries take up gigabytes.