How do I make my application use the Windows theme? - c++

I'm working with some windows API to create a little application.
I already created the buttons, windows, alright.
But the problem is the components I created don't look like the OS theme. They look very simple:
See the button as example.
How do I enable the Windows theme? It can be in C or Delphi.

For an application using windows controls, that is documented in this msdn article
Edit: To make a long story short, Windows needs to know for an application if it was intended to use the new style controls. Some older apps just aren't compatible with the new skinned looks of XP and later. Each exe should therefore declare with which version it is compatible in a manifest, an embedded xml file in the executable. The manifest is used for other things like declaring what you are or aren't compatible with (DLL versions, 120 dpi) as well as registration-free com.

It depends on what version of Delphi
you're using. IIRC pre-Delphi 6 you
need to add the needed manifest by
hand. D7 and later has a component
that need to be dropped on a form to
add theme support (it simply adds the manifest), until D2007 IIRC
added a simple check in the project
options.
Earlier version of Delphi won't show themed design form. You will see themes only at run time.
Not all controls may support themes. Themes require the proper draw API to be called, if a control doesn't comply it won't be themed. The standard grid is a good example, it isn't draw themed until a late version.

If you're using Delphi 2007 or later, Project > Options > Application > Use Windows Themes needs to be checked.
(This should be automatically checked for new applications).

In Visual Styles Reference: Functions of MSDN, I found an interesting functions, that is, SetWindowTheme(). It can be used to either to apply or remove visual style to/from a control/window, there are several steps need to be done to enable Visual Style in an application.
To use Windows Theme api, you'll need JwaUxTheme unit of JEDI API Library.
However, applying theme from Windows Theme files (.theme) to an application seems has to be done by turning off visual style from controls and write owner drawn controls based on information from .theme files. MSDN has a documentation about .theme file specification (see the first reference below).
Some good references:
Creating and Installing Theme Files
Fully themed Windows Vista Controls
Creating Windows Vista Ready Applications with Delphi
Is Windows Presentation Foundation (WPF) Themes bad? There is a code example how to load it here.
If you use VCL, Theme Engine and Skin Engine has a complete support of themes for Windows XP.
If beauty application is your priority (without supports for Windows themes), I think, BusinessSkinForm and DynamicSkinForm is the best choice.

If your executable name is YourAppName.exe then, create a manifest file named YourAppName.exe.manifest in the same directory where the executable application is.
YourAppName.exe.manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
name="YourAppName"
processorArchitecture="*"
version="1.0.0.0"
type="win32"/>
<description>MyApp</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
For embedding manifest file into executable use mt.exe
commandline syntax:
mt.exe –manifest YourAppName.exe.manifest -outputresource:YourAppName.exe;1

Related

Why do native C++ projects have a TargetFrameworkVersion?

In Visual Studio (v100, v110) it is possible to specify the version of .NET framework that a project targets using the TargetFrameworkVersion element in the project file. (If there is no TargetFrameworkVersion element, the IDE just uses its default .NET version.) The specified TargetFrameworkVersion is then used to choose the (default) tool-chain which will be used to build the project.
The above is true for both CLR and native C++ projects. I find this really weird and confusing. If Visual Studio knows a project is native then why does it care what the TargetFrameworkVersion is?
Well, actually you'd have to ask the developers responsible for creating the MSBuild scripts, because in principle it is not really needed, nor used. And they know it themselves. For a standard C++ project file, these are the lines causing the property to get set (Microsoft.Common.targets):
<!-- By default, we are creating a managed app because .NET 2.0 projects did not have this property. -->
<PropertyGroup Condition="'$(TargetRuntime)' == ''">
<TargetRuntime>Managed</TargetRuntime>
</PropertyGroup>
<!-- Because .NET 2.0 apps did not set TargetFrameworkIdentifier, we need to set it for them here by default. If
the runtime is set to Managed, we also need to set these. Otherwise they should be blank (for instance Javascript or
Native apps) because they do not target a .NET Framework. -->
<PropertyGroup Condition="'$(TargetRuntime)' == 'Managed'">
<TargetFrameworkIdentifier Condition="'$(TargetFrameworkIdentifier)' == ''">.NETFramework</TargetFrameworkIdentifier>
<TargetFrameworkVersion Condition=" '$(TargetFrameworkVersion)' == '' ">v4.0</TargetFrameworkVersion>
</PropertyGroup>
Lazy programming, basically. Microsoft historically preferred managed code because it's not really portable to other operating systems, causing lock-in. So the .NET languages have had more priority in Visual Studio.

How to run application with Admin privileges using Manifest file in Visual Studio 2005?

I need to create an application which needs to create files/folders in "C:\Program Files","Users[username]" and Sys32. Also the application needs to make some registry entry.
This application needs to work on Vista and higher. Also, on Windows Server 2003 and higher.
The above Operating Systems have the concept of User Account Control (UAC), where to access Program Files and writing in registry requires admin privileges.
I looked into many forums and found that using Microsoft SDK we can check whether the current user have admin privileges or not . But the function "CheckTokenMembership" fails for Vista and higher version of OS.
I also found a solution where manifest file can be used to tell OS in advance that the current application requires admin privileges. This is done using "requestedExecutionLevel" tag.
I am using Visual Studio 2005 to create the application. When we create an application in Visual Studio a default manifest file is created. Can I change this manifest file to include "requestedExecutionLevel" tag, so that my application always runs with admin privileges?
Is there any other method through which my application runs with admin privileges without asking user (admin or standard) to run my application as "run as admin"??
Thanks!
You should find an option for this in project properties Linker -> Manifest File -> UAC Execution Level. Set this to requireAdminstrator.
This will cause the default generated manifest to include the requestedExecutionlevel that you need, so that your users will be prompted automatically to elevate their privileges if they are not already elevated.
Acknowledgements and Introduction
This question helped me and I will help back with the knowledge I gained. Thanks to:
Lipika(The person whom asked the question) revealing that admin access was the reason why access to system directories were redirected to virtual directories. It was later clear that lack of admin access cause writing to certain registry keys to fail.
snowcrash09 for revealing the Visual Studio option for enabling require admin access. With further research on MSDN, I got the manifest to not embed into the executable under Properties>Manifest Tool; thus allowing me to read it.
Nayana's link to polynomial's answer is also good. Here I will borrow part of his answer in my demonstration.
Answer
As Lipika have stated, you require admin access, else Windows Vista and up will redirect you to a virtual directory. Which is great. Logically then your app should request admin access. You can let the user do it manually. If not, Windows provides many ways to do this programatically. The easiest way is to declare it in your app's manifest. Here I will dedicate instructions to individuals not using Visual Studio. If you are using Visual Studio, it is as easy as Properties>Linker>Manifest File>UAC Execution Level.
If you are using CodeBlocks for example; create a file called app_resources.rc. With CodeBlocks its very import that this file has the .rc extension, so CodeBlocks knows to compile it with windows resource tool. Copy the following code into this file, and add it to your project.
#include <windows.h>
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "adminAccess.manifest"
Create a manifest file called adminAccess.manifest. copy the following code to the file. Do not need to add this file to your project as it is reference from your rc file.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="MyApplication"
type="win32"/>
<description>Description of your application</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Now you can compile your app and it will automatically prompt for admin credentials when run. It will return failure if admin access was not granted. On Windows Xp, you won't be prompted for any authentication.
Note that from here you can edit the manifest to add features such as visual styles for Windows widgets and DPI awareness.
If you are not using CodeBlocks. For example you are compiling from the command line. You pretty much have to compile the rc file with the Windows Resource Tool. In MinGw build tools, this is called windres.exe. It will compile a .res file. You then link this resulting file, with all the other files you will be linking at the linker stage.
Note that the rc file is a windows resource file and carries all the resources your app uses such as BITMAPs, ICONs, STRINGs, dialog template. Which will all be stored in the final executable. Which you can then load from the executable using Windows specific functions. This is pretty similar to what Android does.

How does Win8 classify a process as a "Background Process"? My app works in Win7 but shows no UI in Win8

My fairly normal MFC-based Windows application works fine on Windows 7. But when I run it in Windows 8, no UI appears. At first I thought it somehow wasn't launching properly, but eventually realized that if I bring up the Task Manager, it shows that my application is running but it's listed under the "Background processes" section.
What heuristics is Windows 8 running on a process to decide it is a "background process"? Or is there something I can do--perhaps in the application manifest--to explicitly label my application as a foreground process?
I have tried running in Win7 and XP compatibility modes, to no avail. I have tried several Win8 machines, all give the same result.
For what it's worth, this app is compiled with Visual Studio 2003 and I do not have the option of using a newer compiler.
I have googled things like "win8 background process" but all I'm getting are people who want to create a background process. Some of the answers suggest that a background process has to be registered using the application manifest, but I double-checked my manifest and it definitely has nothing in it about being a background process.
Here's my manifest, in case you can see something off in it:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="MyProductName"
type="win32"
/>
<description>My Product Description</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:security>
<asmv3:requestedPrivileges>
<asmv3:requestedExecutionLevel level="asInvoker" uiAccess="false" />
</asmv3:requestedPrivileges>
</asmv3:security>
</asmv3:trustInfo>
</assembly>
I will be opening a support incident with Microsoft to get their help if I can't find an answer here. If it gets to that point, I'll certainly update this question with what I find.
I'm developing Windows 8 applications but not much knowledge of MFC development. so based on my knowledge MFC development is more similer to Silverlight development but Windows 8 development is more different than MFC development platform.
by the way, "Classification of Background Process in Win 8":
The Process of application which is in suspend mode, that means the application is running but not showing any UI due to Desktop mode.
to clarify my self on this point I checked once more by creating a tread in win 8 by XAML & C#, and made that thread as in suspend mode, only at that time that process showing as background process in task manager.
moreover that "Specifically for Windows 8 only" :
The process of any app shows as background process when Provided Resources to the app will decreases or will d-allocate those resources but still application is loaded and running...
This feature of Windows 8 is known as "Auto Resource allocation"...
sorry if you not find your answer here but i think this can help you to know "Which process is classify as Background Process in Win 8"
This is pure speculation on my part, as I can't find any documentation on this, but I suspect that something in MFC is failing, and the lack of a working UI is why Task Manager is classifying your app as a Background Process, since the user is not able to interact with it.

Android C++ Native Code

I am a new Android developer and I would like to create an application using only C/C++ code for Android but I have found the documentation to be very limited. I can create an Android C/C++ project in eclipse, but it uses a lot of java code.
I'm using NativeActivity (new to 2.3) and I need help setting up my project. Does anyone know how to do this?
http://developer.android.com/reference/android/app/NativeActivity.html
Just remove all of the generated Java code. You don't need it if you want a purely native activity. The only thing you need to do is to set up the Android Manifest file as shown in the documentation. In particular, you'll need:
<!-- Tell NativeActivity the name of or .so -->
<meta-data android:name="android.app.lib_name"
android:value="native-activity" />
And you'll need to modify jni/Android.mk so that it builds a jni with the name lib_name.
Yuo can look into the Lighthouse project for android, which allows you to use Qt (and therefore C++) code instead of java. You still need 1 line of java code to kick off your Qt app.

msvcr90.dll dependency in VS 2005 C++ project

I've created a DLL project in VS 2005 for native Win32/unmanaged C++, call it myProj.dll. It depends on a 3rd-party commercial DLL that in turn depends on msvcr90.dll (I assume it was built from a VS 2008 project). I'll call it thirdParty.dll.
My DLL project builds just fine in VS2005. I've built a test app (again, VS 2005 Win32 C++) that links to myProj.lib. (As an aside, judging by the small size of the .lib, and by the fact that, at run-time, the app must locate myProj.dll, I'm guessing that the .lib is just a wrapper for a call to loadLibrary() that loads the actual DLL; is that close?)
My problem is that, at run-time, the test app cannot locate msvcr90.dll (nor msvcp90.dll), the dependency on which stems from the thirdParty.dll.
I've installed Microsoft's redist package, and so have all the std (9.0) C++ libraries in c:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_... . What's more, if I point the dependency walker at thirdParty.dll, it happily resolves the references to that location.
But, if I point depends.exe at my test app (.exe) or myProj.dll, msvcr90.dll and msvcp90.dll are not found.
I'm guessing there's something I need to configure in VS2005 so that the .exe or myProj.dll are aware of the location of the 9.0 versions of the std C++ libraries (presumably where the redist package installed them in C:\WINDOWS\WinSxS), but I can't seem to figure out what it is. Am I on the right track?
I note that, if I simply copy the msvc*90.dll files to my app directory, then the dependency is resolved, but I get the run-time error about improper loading of std c++ DLLs, etc.
Thanks immensely in advance.
This looks like a "Side-by-Side Assemblies" issue to me.
From what I can tell, Microsoft in an attempt to stop the DLL Hell problems of past years has introduced a concept of "Side-by-Side Assemblies".
In a nut shell it means that your application needs to tell Windows which version of the CRT it was designed to work with. When the application is installed Windows will make sure you application gets its own private copy of these DLL files.
To make it all work you need to embed the application's DLL dependencies into the applications Manifest file and attaching it to the project using the Manifest Tool, Input and Output section of the application project settings.
As an example here is the manifest I use for the Zeus for Windows IDE:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
name="Xidicone.Windows.Zeus for Windows"
version="3.9.6.69"
processorArchitecture="X86"
type="win32" />
<description>Zeus for Windows</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.VC80.CRT"
version="8.0.50608.0"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*" />
</dependentAssembly>
</dependency>
</assembly>
Finally, if you plan to make an installer you will need to add the same versions of these DLL files to the application installer or alternatively have your installer run the Microsoft CRT redistributable installer.
FWIW I only found out about this when a user reported that Zeus no longer ran on Windows XP because of a missing MSVCRT runtime DLL file, yet Zeus had been working fine for over 10 years without ever once having to ship with a MSVCRT runtime DLL file.
Did you install the SP1 version of the msvc 2008 redist?
It is not a problem if depends.exe cannot find the msvcr90.dll, if you use the microsoft installer it is automatically installed in the correct location, and will be found if your application is run. It does not help if you copy the dll's to your application directory if you do not create a manifest.
But can you tell the exact error message you get?
You can also take a look here and here regarding the manifest.
I would ask the third party dll people about this.
I have the same problem some days ago. myProj.dll depends on a thirdParty.dll, which uses msvcr90. If I build a test.exe using directly myProj.dll, it is ok. But if I use loadLibrary(myProj.dll) in test.exe, the call will just fail. The same would happen if I try loadLibrary(myProj.dll) in a Java program.
After some investigation and research on Internet, the following steps have resolved my problem.
Make sure that NO msvcr90 is on the PATH.
You can use process explorer (procexp.exe of SystemInternals) to find out all msvcr90 currently loaded in your environment. As a matter of fact, starting from VC 2005, C runtime libraries should only be installed in the Global Assembly Cache (\winsxs....), not even under windows, or windows\system32.
embed the dll manifest in myProj.dll.
After cl.exe and link.exe producing myProj.dll, a corresponding manifest is also produced.
Then use mt.exe -inputresource myProj.dll.manifest -out myProj.dll;2
The above solves my problem, hope that it could be of any help to you.
BTW, I am using VC 2008 under Windows 2008 R