You might like to use child and Descendant selectors for handling such situations.

Before IE-7, Child Selector was not supported in IE. And for IE to recognize the chile selector you should provide Doctype declaration in your page else IE7+ would render the page in quirks mode and child slector would be ingnored.

Descendant Selector:

• Specifies elements by ancestry
• If Child selector is specified after the Descendant Selector, then Descendant Selector would affect all the Children but not the direct children.
• If Child selector is not specified or specified before the descendant Selector, then it would affect the direct children too.

Each "generation" is separated by a space. For example, the following rule states that <strong> tags within <p> tags should have green text.

p strong
 {
 color : Red;
 } 

With descendant selectors generations can be skipped. In other words, the code above does not require that the <strong> tag is a direct child of the <p> tag.

Child Selectors:

A child is the direct descendant of a node/tag in CSS or in other words direct Parent-Child relationship.

p > strong 
 {
 color: red;
 }
 

In this case only <strong> tags that are direct children of <p> tags are affected.

Note the use of “>” to specify the Parent – Child relationship.

Note: If you want proper effect, first specify the Descendant Selector and then Child Selector. If you reverse the order i.e. first Specify Child Selector and then Descendant Selector,

in this scenario Child Selector would not be applied as Descendant Selector will override the Child Selector.

Consider Child Selector as a one more layer of Specialization over the Descendant Selector hence it should be written after the Descendant Selector.

For Child selector to be recognised by IE7+ do put Doctype declaration in your page else it would be ignored as IE7+ would render the page in quirks mode.

HTMLPage1.htm

While launching from Admin account or doing “Run as Admin” it was launching properly but when launched from the standard-user account, though it was launching but GUI was not coming properly and before launching, it throws the error that some particular Skin file is missing. I checked in installation folder and skin file was there but still while launching I was getting the error, but when launched from Admin account or using “Run as admin” it was launching properly with proper GUI and no skin file missing error.

On exploring further I found that application was installed by admin account and it created some entries in HKCU, and these entries contain the path and name of skin file to be used. So when we launched the application from Standard user account then these entries were empty in HKCU for Standard user. So to solve this problem while re-packaging I used Active Setup.

Active Setup provides a great solution for installing current user data when the package is not installed in the user context.

This is how it all works:

When user logs on the system then following registry entries are checked :

HKLM\Software\Microsoft\Active Setup\Installed Components\<UID>

                And

HKCU\Software\Microsoft\Active Setup\Installed Components\<UID>

N.B. <UID> has to unique; it is good practice to use a GUID. As I was repackaging I used the Product Code of installer. (Product Code is GUID)

If the HKCU key is not found in the registry then the contents of the string value StubPath is executed. The HKLM key is then copied to HKCU.

The executable in StubPath can be anything. It can be a VBS script, a regsvr32.exe call, msiexec.exe call etc.

But here my aim is to repair the already installed application so that it may have the entries in HKCU for current user context.

To do this I need to force the package to repair so Msiexec.exe will be used: 

Msiexec.exe /fu <ProductCode> /qn
 
 /f - Repair
 
 /u - all required user-specific registry entries
 
 /qn – Silent mode with no UI.

[For other repair options type “msiexec” in run, it will open the help for msiexec]

So I would need to create Active Setup entry in HKLM Registry for my package.

For this example I have used Admin Studio InstallShield to re-package the application.

On opening the application by Admin Studio InstallShiled I found out that there was no Active Setup entry in HKLM under Registry, so I created the one by myself.

Please see the below screenshots to see how to create Active Setup registry entry for a Package: (Admin Studio Installshield is used here): 

Step 1: Open the .msi or create a .mst transform file and navigate to Registry section.

Step 2: In Registry section navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\

Step 3: Right click on Microsoft folder and select New -> Key, a new folder will be created under Microsoft.

Step 4: Change the name of newly created folder to “Active Setup”.

Note: If you do not find any folder named SOFTWARE or Microsoft under HKLM then these folders can be created in the same way as “Active Setup” folder has been created.

Step 5: As explained earlier, now create a one more folder under the “Active Setup” and name it as “Installed Components”.

 Step 6: Create a new folder under the “Installed Components” and name it as “[ProductCode]”.

Note: [ProductCode] is an .msi variable which is replaced by Product Code value when package is installed on computer. Product Code is nothing but the GUID assigned to package. You can check the Product Code value from “General Information” section. You can also use the Product Code GUID instead of “[ProductCode]” variable; but using "[ProductCode]" is cleaner and better.

Step 7: After creating the “[ProductCode]” folder select it and right click on the extreme right lower pane.  From the right click menu select “New String Value” option.

Step 8: Name the newly created string value as “StubPath”.

Step 9: Double Click the “StubPath” string key and that would open an Edit Data popup. Enter following under "Value Data:" Textbox

msiexec /fu [ProductCode] /qn

Then click OK.

Step 10: In the end,  your .msi/.mst should look like the following:

After creating the Active Setup registry, save your package and Install it.

Now after installation there will be an entry under HKLM\Software\Microsoft\Active Setup\Installed Components\<UID> for the currently installed application.

And if application is installed in a different user context than the current user, so when current user logs on the system, Windows would find that HKCU entry is missing. Then it would run msiexec.exe with
repair options from StubPath and copy the HKLM key to HKCU. (Note that we wrote msiexec.exe in StubPath, windows would run whatever command is written in StubPath) 

Next time when this user logs in the repair won't run as the key already exists in HKCU.

N.B.  : Here I only choose to repair the Registry entry, if you want you can choose the entire Installation to repair by using :

msiexec.exe /fauvs <ProdcutCode> /qn

Hope this article is helpful to you all.