ActiveX Tutorial

Activex Q And A

2008-11-12T03:22:00.000-08:00

What's In This Document?

This document describes the changes in Internet Explorer 7 that reduce the number of ActiveX controls enabled by default

through a feature called "ActiveX Opt3In".

This document also describes some of the best practices for developing ActiveX controls intended to run in Internet Explorer.

These best practices have been compiled from the Security Development Lifecycle and from software developers who develop

and test ActiveX controls intended for safe use on the Internet.

Where does ActiveX Opt_In apply?

Where does it not apply?

ActiveX Opt3In applies to controls run in Internet Explorer and any applications which opt3in to Manage Add3ons through the

feature control key. ActiveX Opt3In can be enabled or disabled on a zone3by3zone basis through the IE Security Settings panel.

The setting, "Allow previously unused ActiveX controls to run without prompt" enables and disables the feature. By default,

ActiveX Opt3In applies to controls used on the Internet and restricted sites zones while controls used on an intranet and

trusted sites zones will not be affected by ActiveX Opt3In.

Should your control be on the pre_approved list?

Having your control on the pre3approved list can be valuable in some, but not all, situations. The situations below will help you

determine if you need your control to be on the pre3approved list.

Putting a control on the pre3approved list will attract the attention and scrutiny of the security research community. Any

vulnerabilities found in your control would expose a significantly larger number of users than if your control were not on the

pre3approved list. Keeping your control off the pre3approved list will keep users secure by default and protect customers who

are not using your control.

Your control should be on the pre3approved list if:

Your control is (or uses) an ActiveX control that is pre_installed on a user's machine by Windows or by an OEM.

Controls installed by Windows or by an OEM will be disabled by ActiveX Opt3In unless you take steps to pre3

approve them. Pre3approving your controls will insure that users have the best possible experience on your Web

site because it will work the way that you and the user expect.

Your control is intended to run from Internet Zone Web pages.

If, in the process of installing your application, ActiveX controls are installed which are intended to run on the

Internet, you might want to add these controls to the pre3approved list. Because the controls were installed by

software, and not by the user, the controls will be disabled by ActiveX Opt3In.

Your control should not be on the pre3approved list if:

Your control is not intended to be run in Web pages served from the Internet.

If your control is not intended to run in pages served from the Internet, then it should not be on the pre3approved

list. There are two steps we highly recommend in order to prevent the control from running in IE.

1. Killbitting the control [ http://support.microsoft.com/kb/240797 ] will ensure that it can never load in

IE. Killbitting the control only requires setting a registry bit and is easily accomplished.

1. Killbitting the control [ http://support.microsoft.com/kb/240797 ] will ensure that it can never load in

IE. Killbitting the control only requires setting a registry bit and is easily accomplished.

2. Do not mark the control safe for initialization or scripting. You should ensure this is true in both the

component categories as well as through IObjectSafety Mechanisms.

Your control is downloaded to the user's machine.

If your control is not locally installed on the user's machine then there is no need to be on the pre3approved list.

When the user downloads the control and chooses to install it, then the control will be approved. The user will not

be prompted again after choosing to install from the authenticode dialog. Note: only the control whose CLSID was

included in the object tag will be approved. If you have a single cab file which installs multiple controls, only the

control initialized in the object tag will be approved. You might need to pre3approve any other controls which

the .CAB file installs.

Your control is only intended to run on your corporate intranet or your control is for a line of business application.

You should not add these controls to the pre3approved list. ActiveX Opt3In is turned off by default in the intranet

zone so your corporate ActiveX controls will not be affected. It would be a good idea to zone3lock these controls or

restrict their capabilities when not running on an intranet.

If you have controls created for business applications which are not applicable to the general public, these

controls should not be pre3approved. You should work with the network administrators where your applications

run to ensure that the right controls get approved on your users’ machines. This can be done either through

Manage Add3Ons group policy [ http://support.microsoft.com/kb/883256 ] or by adding the controls to the pre3

approved list in the registry.

How does my control get onto the pre_approved list?

Because pre3approved controls add to the attack surface of a user’s system, you should make sure that your controls have

been designed with security in mind. As the vendor for your ActiveX control, you are responsible for designing and testing it

to ensure that the control meets the best practices criteria described in this document. By adding your control to the pre3

approved list, you are warranting that you have reviewed the best practices for secure development outlined in this

document and certify that implementation of your control followed these or equivalent principles for secure development of

ActiveX controls. You are certifying that your control has no vulnerabilities to the best of your knowledge.

To put your control on the pre3approved list, you need to write the CLSID of the control to the following registry location.

HKEY_LOCAL_MACHINE

SOFTWARE

Microsoft

Windows

CurrentVersion

Ext

PreApproved

If Microsoft determines that a control has a vulnerability and presents a danger to end users, Microsoft reserves the right to

remove that control at any time from the pre3approved list.

How to build secure ActiveX controls

Building a secure ActiveX control requires that designers, developers, and testers focus on security throughout the product

lifecycle. Designers must restrict the capabilities of the control so that it can accomplish only the work it needs to do without

any additional capabilities that might lead to exploits. Developers must code the control to act appropriately and safely when

handling data. Testers must include test cases based on potential threats to the control. At each stage in the development

lifecycle, security must be considered. The next sections go into more details on specific steps and considerations at each

stage in the lifecycle of a control.

Principles of Secure Design for ActiveX Controls

Designing for security is important because ActiveX controls are exposed to content from malicious Web sites. Any Web site

can try to use the control; all it needs is the control's class identifier (CLSID). When you designed your control, you may have

thought primarily about the control being used by some well intentioned pages, maybe even on your own website. To be safe

for running in the internet zone, you must design your control to be safe when loaded from any page on the internet,

particularly malicious pages. You need to ensure that malicious Web sites can't exploit your control to harm the user's system.

As you design, think about how the functionality of your control could be exploited and what measures you can take to

protect users from these exploits.

Restrict the capabilities of your control

Because an ActiveX control is a Microsoft Win32 component, there is no sandboxing33it can run without restrictions. You

should think about how you can restrict the functionality of your control to prevent others from repurposing it to malicious

ends. One of the first things you should think about when you consider writing an ActiveX control is if you really need an

ActiveX control to accomplish the functionality you need. If you do not need access to system resources, you can write the

control as a Dynamic HTML (DHTML) behavior [ http://msdn.microsoft.com/library/default.asp?url=/workshop/author/

behaviors/overview.asp ] .

In order for your control to be safe, the interface exposed to IDispatch (and therefore the Web) should be scoped as narrowly

as possible while still meeting your functional requirements. If your function does not absolutely require input parameters,

then remove them. If you can narrow the scope of the input parameters to a handful of known inputs, then do so. If your

control writes data to the local computer, or in any way changes the state or behavior of the system, take time to consider

how your control might be abused by a malicious third party.

Some scenarios you should consider when designing your control include the following.

How many and what kind of parameters does your control take?

Can you reduce the number of parameters or

more closely restrict the kind of data they accept?

Does the control rely on the URL of the hosting page to make security decisions? What happens if the control is

unable to obtain the hosting URL from Internet Explorer? Does it fail securely in this case?

Can the control be made to call other objects on the page, including Java applets? The Microsoft virtual machine

(Microsoft VM) called from native code in the control might attribute greater permissions to the control than script

on the page has. If the script can manipulate the control to call the Microsoft VM for it, an indirect security attack

might be possible.

Can the control tunnel out of the frame in which it is hosted and access content in another frame? The data

accessed could potentially violate the privacy of the user. You might prevent this by restricting the control to run

only within a particular domain.

Many ActiveX controls are initialized with data from local or remote sites, and most ActiveX controls are scriptable, supporting

a set of methods, events, and properties. Both initialization of persisted data and use of the controls through scripting require

safeguards to ensure that security is not violated. If your control does not read persisted data, don't mark it as safe for

initialization.

Site_Lock Your Control

One powerful way to restrict the capabilities of your control is to lock it to a specific domain. If your ActiveX control is

designed only for a specific Web site, then locking it to the domain of that Web site will make it harder for other sites to

repurpose the control in a malicious manner. However, you should be aware that site3locking does not guarantee another site

cannot use your control. Cross3site scripting flaws and man3in3the3middle attacks could expose your control to other Web

sites. Site3locking should only be used as defense in depth; it cannot be your primary line of defense.

A site3locking template that uses Microsoft Active Template Library (ATL) is available: SiteLock 1.14 Template for ActiveX

Controls [ http://www.microsoft.com/downloads/details.aspx?FamilyID=43cd7e1e35719345c0388d93

ec9ea7fefbcb&displaylang=en ] .

Zone Lock your Control

If site3locking your control is too restrictive, you might still be able to zone3 lock your control. You could zone3lock your control

so it will only work when IE is in a specific zone, Internet, intranet, trusted sites, or restricted sites. As with site3locking,

however, zone3locking should be used as defense3in3depth and not a primary line of defense.

The SiteLock 1.14 Template also provides zone3locking functionality.

Ensure that ActiveX runs under least_privilege environments

By default, Windows XP user accounts were administrator accounts because many features and programs did not run

correctly under non3admin privileges. In Windows Vista, this will no longer be true. Users, by default, will not be

administrators on their machines. ActiveX controls must be able to operate fully in a non3admin environment. Furthermore,

when Protected Mode is enabled in IE the entire process will be running at a low integrity level, level 1. Controls need to be

tested under normal user account privileges and if possible even developed in these accounts.

More information on user account privileges can be found in Security in Longhorn: Focus on Least Privilege [ http://

msdn.microsoft.com/library/default.asp?url=/library/en3us/dnlong/html/leastprivlh.asp ] and Understanding and Working in

Protected Mode Internet Explorer [ http://msdn.microsoft.com/library/?url=/library/en3us/IETechCol/dnwebgen/

ProtectedMode.asp

frame=true ] .

Secure Development Practices

Once you have designed and threat3modeled your control it is time to start implementing.

Prevent Denial of Service Attacks

Be sure the control doesn't loop infinitely or stop responding when given bad data or arguments. An attacker might tie up a

user's computer using your ActiveX control.

Safely Handle Memory

It is important for a secure ActiveX control to check all inputs and guard against buffer overruns. For example, if a control

receives an input string into a fixed3length buffer without checking its length first, it is possible for a malicious caller to

provide a string that is longer than the allocated buffer, overwriting other information in an unintended way. In some cases

these bugs can be exploited to make the control perform unsafe operations it was not designed to do. As the author of an

ActiveX control, you need to be vigilant. Never assume that a certain input conforms to certain requirements. Always check

the data to avoid these attacks. All inputs should have maximum sizes, and controls should be tested to perform safely, even

with inputs that are beyond specifications. See Fix Those Buffer Overruns [ http://www.msdn.microsoft.com/library/en3us/

dncode/html/secure05202002.asp ] for more information.

Limit Drag_and_Drop Capabilities

Drag3and3drop capabilities can be used to create many engaging and interactive experiences for users, however, ActiveX

controls need to enable and react to these capabilities in a responsible manner. If your control acts as a drop target then you

should not perform any unsafe action without prompting the user. If your control is a drag source, then you should be sure to

set the CFSTR_UNTRUSTEDDRAGDROP Clipboard format. This will insure that any program reading the dropped data will know

that it should not be fully trusted. You should also be aware that drag3and3drop capabilities in IE are now limited by a security

setting which may restrict the drag3and3drop capabilities of your control (URLACTION_SHELL_ENHANCED_DRAGDROP_

SECURITY).

For more information on tagging clipboard data, please see Shell Clipboard Formats [ http://msdn.microsoft.com/library/

default.asp?url=/library/en3us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_programming/transferring/

clipboard.asp ] .

For more information on the IE security setting regarding drag3and3drop, please see URL Action Flags [ http://

msdn.microsoft.com/library/default.asp?url=/workshop/security/szone/reference/constants/urlaction.asp ] .

Safe for Scripting and Safe for Initialization

There are a few different mechanisms that IE uses to determine that controls are safe to initialize and script. The

IObjectSafety interface and Component categories manager are two tools that IE uses.

One of the first things to note about marking a control safe for scripting or initialization is that this should only be done for

controls which you actually intend to be initialized or scripted. If your control does not need scripting functionality then do

not mark it as such.

IObjectSafety [ http://msdn.microsoft.com/library/default.asp?url=/workshop/components/com/reference/ifaces/iobjectsafety/

iobjectsafety.asp ] is an interface that IE can use after a control is loaded to query the control and determine if the control

believes that it is safe to be initialized and scripted. The component categories manager is a method for controls to register

themselves as safe for use in IE. These are registry settings which IE can check prior to loading a control.

believes that it is safe to be initialized and scripted. The component categories manager is a method for controls to register

themselves as safe for use in IE. These are registry settings which IE can check prior to loading a control.

The IObjectSafety interface supports two methods, IObjectSafety::GetInterfaceSafetyOptions and

IObjectSafety::SetInterfaceSafetyOptions. The GetInterfaceSafetyOptions method should return the control's security

capabilities, safe for initialization and/or safe for scripting. The SetInterfaceSafetyOptions method is a request from the

container, IE, to the control and indicates that the control should configure itself to be safe for initialization or scripting.

The component category manager is a way that IE uses the registry to determine when controls are safe for initialization and

scripting. You should be sure to register your control with the component category manager when it is installing. Details on

how to set these registry keys can be found at How to mark MFC ActiveX controls as Safe for Scripting and Initialization

[ http://support.microsoft.com/kb/161873/ ] .

For more information on marking ActiveX controls safe for initialization and scripting via IObjectSafety and Component

Categories, please see Safe Initialization and Scripting for ActiveX Controls [ http://msdn.microsoft.com/library/default.asp?

url=/workshop/components/activex/safety.asp ] .

Controls that Operate in the Local Machine Zone

ActiveX controls operating within the Local Machine Zone should not allow arbitrary content from the Internet to be written to

files in predictable locations without user interaction. Furthermore, controls operating in the Local Machine Zone should not

allow execution of arbitrary code directly or indirectly.

Design your control to be compatible with the Data Execution Prevention Feature

Data Execution Prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to

help prevent malicious code from running on a system. DEP is available on Microsoft Windows 2003 Server SP1, Windows XP

Service Pack 2, Windows XP Tablet PC Edition 2005, and on Windows Vista.

DEP works by preventing code execution from data memory that is not marked EXECUTABLE, such as the stack and heaps.

Hardware3enforced DEP detects code that is running from these locations and raises an exception when execution occurs.

Software3enforced DEP is a subset of hardware3enforced DEP, for machines that do not have supporting processors, and can

help prevent malicious code from taking advantage of exception3handling mechanisms in Windows.

Controls which are DEP compatible cannot execute code from any page which is marked non3executable. Note, ATL 7.1 and

earlier is not DEP compatible so if you use ATL, you will need to compile your control with ATL 8.0 or later.

IE provides a setting you can enable to test your control with the DEP feature. Go to the Tools | Internet Options | Advanced

tab and check the setting "Enable memory protection to help mitigate online attacks". (Note if you are running on Windows

Vista, this setting can only be changed if Protected Mode is disabled. Once the feature is enabled, you can run in Protected

mode.) You should use this IE setting to test your control and make sure it is compatible with DEP. Once your code is

compatible with DEP, you should link your code with /NXCOMPAT.

For more information, please see Changes to Functionality in Microsoft Windows XP Service Pack 2, Part 3: Memory Protection

Techniques [ http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx ] and A Detailed Description

of the Data Execution Prevention (DEP) Feature [ http://support.microsoft.com/kb/875352 ] .

Use Automated Tools to Evaluate Your Code

Code reviews and quality assurance testing are highly valuable processes which are able to find and correct many bugs and

threats; however, more recently, new automated tools have become available which can review your code and flag potential

problem areas. One tool which Microsoft releases is called PreFast. It is available as part of Visual Studio Team System 2005

and also in the Windows DDK. PreFast will step through all the execution paths in your source code and look for errors in the

following areas.

Memory: Potential memory leaks, de3referenced NULL pointers, access to uninitialized memory, excessive use of

the kernel3mode stack, and improper use of pool tags.

Resources: Failure to release resources such as locks, resources that should be held when calling some functions,

and resources that should not be held when calling other functions.

Function usage: Potentially incorrect usage of certain functions, function arguments that appear incorrect,

possible argument type mismatches for functions that do not strictly check types, possible use of certain obsolete

functions, and function calls at a potentially incorrect IRQL.

Floating point state: Failure to protect floating point hardware state in a driver and attempting to restore floating

point state after saving it at a different IRQL.

Precedence rules: Code that might not behave as the programmer intended because of the precedence rules of C.

Kernel_mode coding practices: Coding practices that can cause errors, such as modifying an opaque memory

descriptor list (MDL) structure, failing to examine the value of a variable set by a called function, and using C/C++

string manipulation functions rather than the safe string functions defined in Ntstrsafe.h.

Driver_specific coding practices: Specific operations that are often a source of errors in kernel3mode drivers, such

as copying a whole I/O request packet (IRP) without modifying members and saving a pointer to a string or

structure argument instead of copying an argument in a DriverEntry routine.

This kind of automated code checking can greatly increase the security of your code and also reduce the number of bugs

found later during testing.

For more information on PreFast, please see PREfast Step3by3Step [ http://www.microsoft.com/whdc/DevTools/tools/PREfast_

steps.mspx ] .

Digitally Sign your Control

A digital signature on your control enables users to verify the control's publisher and ensures that it has not been tampered

with since being published. Digital signatures help users make better trust decisions when determining if they should install a

control and help identify your control in the Internet Explorer's Add3on Manager.

Digitally signing controls is a vital step if you want users to be able to easily install your control. Users are strongly

discouraged from installing unsigned controls, and unsigned controls are blocked from installation by default.

Internet Explorer's Manage Add3Ons dialog displays information about all of the controls on a user's system. (To open the

dialog, choose Manage Add3 Ons from the Tools menu.) Signing your control will ensure that the Publisher field displays

correctly in this list. As you can see in the image below, some of the publishers appear as "(Not Verified)"—these are controls

which have not been signed.

If your control is installed by a CAB file or another executable, you must be sure to sign both the installation file (to enable

installation) and the .dll or ocx file containing the ActiveX control (to ensure your publisher name shows up without the "Not

verified" notice).

The name displayed in the Name Field of the Manage Add3Ons dialog is taken from the following registry setting.

HKEY_CLASSES_ROOT

CLSID

{Control CLSID}

AppName="contoso.exe"

(Default)=(REG_SZ)"Control Name"

LocalizedStringPolicy=(REG_SZ) Localized Control Name

If you have a name that localized for other languages, set LocalizedString to point to the resource ID in your control's binary

file that contains the translated name. Manage Add3ons checks this value first, and uses it if it exists. If the localized string

does not exist, we fall back to the default value, which is (usually) the English name that does not get localized.

For more information, please see the following resources.

Signing and Checking Code with Authenticode [ http://msdn.microsoft.com/library/default.asp?url=/workshop/

security/authcode/signing.asp ]

Introduction to Code Signing [ http://msdn.microsoft.com/library/default.asp?url=/workshop/security/authcode/

intro_authenticode.asp ]

How to Judge control Security

The security of a control is ultimately a subjective judgment. The following questions are designed to help you think about the

security of your control. You can use them as part of your larger security review.

Can you limit domain usage or zone usage? See the section on site3locking your control for more information.

Are you exposing the user's private information over the network or to other users?

Can you read, write, create, detect or delete arbitrary persisted data either on the file system, the registry, a

buddy list, or a camera or other USB devices?

Does this control enable data to passing from one Internet site to another? From the intranet to the Internet?

From the local computer to the Internet?

Can this control host mobile code or script? If so, where does the code or script come from?

Does the control cause arbitrary operations or programs to execute on behalf of the user without notice?

Does this control circumvent/defeat a specific security feature in the browser, operating system, or another

application?

Can a Web page use this control to cause the system to become unstable or stop responding?

Can this control be used to spy on the user without their knowledge?

Is there a possibility for cross3site scripting attacks using this control?

Does this control load its own data format? Does this data type have its own security implementation? Does this

data type allow macros?

Is history, statistical, or debugging information persisted on the local computer? Can a privacy conscious user

clear this information? Is the information ever sent over the network? Are globally unique identifiers (GUIDs) used

to track users?

These are some other general questions that you should consider as you design your control.

Are strings from the network validated, parsed, or filtered? What happens with the strings? What would happen if

they contain script? What happens to the strings after they are passed on to another component?

Where might there be buffer overruns? Have you done full testing for buffer overruns on all methods, properties,

and events?

What are you doing to stop an extraneous Web site from invoking the control?

If you don't mark the control "safe for scripting" or "safe for initialization", does that disable the purpose of the

control? Controls are marked as not safe for scripting or data initialization by default. Don't implement them unless

the functionality of the control is hampered without them.

Does the control present information to the user such that they can always identify its authenticity? Do you

digitally sign the control?

In addition, it is a good idea to document the following information about your control for reference.

Methods

Properties

CLSID

Events

Owner

DLL/OCX name and version

Secure Testing Practices

Validate the control for security using the following four practices.

Create Test Cases based on Threats Identified in the Threat Model

For each threat identified in your threat models, you should create a test case. The test cases should confirm that the

identified threat has been mitigated by the design or implementation of your control. While design and developer

documentation can describe how a control should behave, only testing can confirm how a control actually does behave.

Penetration Testing

Penetration testing is security testing in which testers aim to circumvent the security features of an application, or in this

case, an ActiveX control. Penetration testing includes, but is not limited to, denial of service, stress testing of all network

interfaces and fuzz testing of all file formats used by the control. Penetration testing should verify any explicit access controls,

such as ACLS and also verify correctness in all code which processes untrusted data. You should also test any security

mitigation you may have included in the control. For example, if you site3locked your control, you should do testing of the

control on other Web sites to insure that site3locking was properly implemented.

Fuzz Testing

Fuzz testing should be performed on any ActiveX control that handles data. The idea behind fuzz testing is to provide

structured but invalid inputs to your control. This kind of testing requires a high volume of test cases, with many variations

and mutations in the data that you test the control with. Most often, fuzz testing is done using automated tools. The objective

of fuzz testing is not to ensure that your control acts in an expected manner on the invalid data but to ensure that your

control acts in a safe manner when given invalid data. Your control should not crash or cause a buffer overrun when handling

invalid data.

Fuzz Testing should be done on the following areas of your control.

Any methods within the control

All parameters used by the control

Any data from a remote source, for example if you have a property that takes a URL you should fuzz test the URL

itself but you should also fuzz test the file that is downloaded from the URL.

There are two different parameters to consider when choosing the fuzz data you test your control on. The first consideration

you might make is whether to use a smart or dumb form of data generation. The differences in these two forms are similar to

the difference between black box and white box testing. Dumb data generation, similar to black box testing, generates input

without knowledge of the intended data format or processing functions. Smart data generation, similar to white box testing,

generates input based on knowledge of the correct data structure and how it is processed in the control. A second

consideration when generating data is whether to generate new data or to mutate valid data. Generating new invalid data

may be more appropriate when you are doing dumb fuzz testing. Mutating valid data so that it becomes invalid may be more

appropriate when you are doing smart fuzz testing. For most controls you will want to use a combination of dumb and smart

fuzz testing and generate some of the test data while also mutating other data.

Regression Testing

Regression testing ensures that new changes in the code have not broken any functionality which was previously working.

Regression testing needs to be done at every major milestone in the development cycle. It is important to regression test not

only on the functionality of your controls but your security test cases as well.

Acknowledgements

We would like to thank the following for their help in preparing and reviewing this article: David Ross, Philip Nachreiner, Eric

Lawrence, Mike Friedman, Patrick Mann, Levent Besik, Cullen Sauls, Josh Cain, and Madhuvan Gupta.

Sharon Cohen and Rob Franco are program managers on the Internet Explorer team.

Adding Tooltip To An ActiveX Control

2008-08-24T22:57:00.002-07:00

By default, ActiveX controls do not support tooltips. This article demonstrates how to add tooltip to an ActiveX control. This control can be used to add tooltips to ActiveX controls that we develop. Steps Involved: We have used the 'MFC ActiveX Control Wizard' to develop the 'mytooltip' control. The steps involved are enumerated below:

(a) Select 'MFC ActiveX Control Wizard' as new project type with project name as 'mytooltip'. Click on 'OK'. to let the wizard generate the code.

(b) Open the 'stdafx.h' file associated with the project and add the following line: #include

The header file 'afxcmn.h' contains declarations for MFC classes that serve as wrappers to Windows Common Controls including CToolTipCtrl. Add the following lines to COleControl-derived class CMytooltipCtrl located in 'mytooltipctl.h': CToolTipCtrl m_ttip; Use ClassWizard to add an OnCreate( ) handler to the message map. It is in this routine that the ToolTip control will be created. Add the following code to this handler:

m_ttip.Create ( this ) ;
m_ttip.AddTool ( this, LPCTSTR ( m_toolTipText ) ) ;
m_ttip.SetTipBkColor ( RGB ( 255,255,0 ) ) ;
m_ttip.SetTipTextColor ( RGB ( 255,0,0 ) ) ;

Alter CMytooltipCtrl::DoPropExchange( ) by adding code to initialize the m_toolTipText and m_showToolTip properties:

PX_Bool(pPX, _T("ShowToolTip"), m_showToolTip, FALSE);
PX_String(pPX, _T("ToolTipText"), m_toolTipText, _T(""));

To allow the user of the control some control over the ToolTip functionality, use ClassWizard to add the following Automation properties to the CBasicCtrl class:

External Name: ShowToolTip ToolTipText
Type: BOOL CString
Variable name: m_showToolTip m_toolTipText
Notification function: OnShowToolTipChanged OnToolTipTextChanged

ShowToolTip will allow the user to suppress the display of the tooltip, and ToolTipText will track the text that is to be displayed when the tooltip is visible. To make this work we have added a virtual function PreTranslateMessage( ) to the control class and called RelayEvent( ) function from it.

Directory Copy Control

2008-08-24T22:57:00.001-07:00

Frequently we wish to build a control which copies one directory to another. The standard 'File' dialog is not of much use here since it cannot be used as a control inside another dialog. Also the standard 'File' dialog permits selection of only files and not of directories. To meet this requirement we have developed here an ActiveX directory control. We have used the 'MFC ActiveX Control Wizard' to develop the dircopy control. The steps involved are enumerated below:

Select 'MFC ActiveX Control Wizard' as new project type with project name as 'DirCopy'. Click on 'OK'.

In Step 1 of 2 select '1' for 'How many controls would you like your project to have?'. Click on 'Next'. Click on 'Finish' to let the wizard generate the code.

Next we have added an OnCreate( ) handler to the CDirCopyCtrl class. From the OnCreate( ) handler we have made a provision to create tooltips. For more information on tooltips to an activex control see 'ToolTips to an activx control' in the same website. and then we have laoded a bitmap. In OnDraw( ) handler we have built the folder bitmap using BitBlt( ) . We have added OnLButtonDown( ) handler to CDirCopyCtrl. In this handler we have written a code for popping up a copy dialog, so whenever we click left mouse button on the folder bitmap a copy dialog gets popped up. This dilaog box contains two edit boxes one for source and another for target directory. We can also browse for the directoy using the 'Browse' button present on the copy dialog . Whenever we click on the 'Browse' button 'dirdialog' gets popped up and helps you to browse the directory from the treeview control. After browsing both the directory paths we can click on copy button to copy the directory.

ActiveX Directory Control

2008-08-24T22:56:00.004-07:00

This article demonstrates use of stock property pages in an ActiveX control. The system provides three stock property pages that ActiveX controls can use: a color page for color properties, a picture page for picture properties and a font page for font properties. Here we have created an edit control whose properties can be changed using the color and a font property page. This control has been developed using 'MFC ActiveX Control Wizard'. While going through the steps of the Wizard we chose 1 control for ' ' and 'EDIT' window as a subclass. To add property pages to the control do the following:

Open 'MFC ClassWizard' dialog box. Select the 'Automation' tab sheet. Click on the 'Add Property' button.

From the 'External Name' combo box select 'Font' and 'Back Color'. By adding external names we can interact with the property pages.

Add the following two lines:

PROPPAGEID(CLSID_CFontPropPage)
PROPPAGEID(CLSID_CColorPropPage)
between
BEGIN_PROPPAGEIDS( )
END_PROPPAGEIDS( )

This helps in adding property pages to the 'Properties' dialog of our control. We have used the color property page to select the color for the background of the edit window and font property page to select the style of text which appears in the edit window. To paint the background of the edit control we have added following lines in the OnDraw( ) function of the CStockpagesCtrl class.

COLORREF clrBackGround = TranslateColor ( GetBackColor( ) ) ;
CBrush* prevbrush ;
CBrush brBackGround ( clrBackGround ) ;
pdc -> FillRect ( rcBounds, &brBackGround ) ;
prevbrush = pdc -> SelectObject ( &brBackGround ) ;
pdc -> SelectObject ( prevbrush ) ;
CRect rc ( rcBounds ) ;
pdc -> DrawEdge ( rc, EDGE_SUNKEN, BF_RECT ) ;

As we type in the edit window we get the default backgorund color of the text. This brings a bad effect of erasing the background color of the edit window. To prevent this we have to make the default background color of the text as transparent. For this we have added a message handler CtlColor( ) for the message ON_WM_CTLCOLOR_REFLECT( ) and have added the following code to it:

pDC->SetBkMode(TRANSPARENT);

To change the font of text we just have to select the type from the property page and the effect is seen without writing a single line of code.

Client Program That Uses Directory List And File List

2008-08-24T22:56:00.003-07:00

This program uses two ActiveX controls: a 'Dir' control and a 'Filelist' control. Creation of these controls has been discussed in the first two articles of the section 'ActiveX' in this same site. We have created the a dialog-based project called 'client' using MFC AppWizard. To use the ActiveX controls they have to be registered with the Windows registry. If you want to register these controls on your machine you will have to download these controls from the first two articles in the section 'ActiveX' on this site. Once registered these controls can be inserted in the dialog box. using the following procedure: From the 'Project' menu select 'Add To Project' then select 'Components and Controls'. A dialog box will be popped up. Open 'Registered ActiveX Controls' folder. Search for the control to be inserted; in our case 'Dir' control and 'Filelist' control. Double click on both the controls to insert them in the project. The bitmaps of these controls would now be visible in the 'Controls' toolbar of the dialog editor. Pick both and paste them side by side. You can see the preview of both in the dialog box. The dialog that we created is shown in Figure 1. Run the application to see the effect. The two controls are independent of one another. Our client program helps them to interact. When we select any directory from the 'Dir' control our client program recieves an event with full path of the selected directory. The client program then calls SetPath( ) and SetFormat( ) functions of the 'Filelist' control. Hence whenever we select the directory from the 'Dir' control the files present in the specified directory are listed in 'Filelist' control. When we click on the filename from the 'Filelist' control our client program recieves an event with full path of the selected filename which is then displayed in the edit box.

File List Control

2008-08-24T22:56:00.001-07:00

Like the standard 'File' dialog that lists files of the specified types we wish to create a control that would list files of the specified type present in the specified directory. As against the standard 'File' dialog this control can be embedded into a dialog or a form. Steps Involved: We have used the 'MFC ActiveX Control Wizard' to develop the directory control. The steps involved are enumerated below:

(a) Select 'MFC ActiveX Control Wizard' as new project type with project name as 'filelist'. Click on 'OK'.

(b) In Step 1 of 2 select '1' for 'How many controls would you like your project to have?'. Click on 'Next'.

(c) In Step 2 of 2 select 'SysListView32' for 'Which window class, if any, should this control subclass?'. Click on 'Finish' to let the wizard generate the code.

Click on the 'Class View' tab and in the PreCreateWindow( ) virtual function you can see the line cs.lpszClass = _T("SysListView32"); This line indicates that SysListView32 window class has been made as a subclass of the listexplorer control. Hence the messages would be received by the control class before reaching the SysListView32 window class. To change the style of the tree window we have added:

cs.style |= WS_CHILD | WS_BORDER | LVS_SMALLICON | LVS_SHOWSELALWAYS ;

Next we have added an OnCreate( ) handler to the CFilelistCtrl class. From the OnCreate( ) handler we have called addtolist( ) function. This function finds the files depending on the type of the specified directory. The default type is '*.*' and the default specified directory is 'c:\'. The default type and the directory are represented by two member variables of the CFilelistCtrl class. The addtolist( ) function uses a pointer to CListCtrl class's object to add filenames to the list control. The pointer variable has been defined as a public data member of the CListexplorerCtrl class. The pointer has been initailised with the handle of the list control in the OnCreate( ) handler. On selecting items (filenames) from the list control we have fired an event consisting the fullpath with filename. This is done in onitemchanged( ) function which gets called on selecting any item. The event has been fired by using the function FireGetPathFromList( ) function. We have also added a custom property page which consists of two edit boxes one for the type of file to be listed and the second for the directory path. This requires two property variables 'path' and 'format' to be added. Using these two variables we can access values from the custom property page in DoPropExchange( ) function. As we add two property variables (path and format) two functions(OnPathChanged( ) and OnFormatChanged( ) respectively) are added to the CFilelistCtrl class. These functions get called as we click on 'Apply' button of the property dialog box. From these functions we have called addtolist( ) function to reflect the changes in the list control. If we run this program the control will register itself with the Windows registry on that machine. A dialog box would be displayed asking for the exe file to be used as a container for this control. We can 'Microsoft's ActiveX Test Container' to display the control. Here we have to insert our control from the 'Insert control' box. The container contains of a splitter window. The upper window displays the control and the lower window displays the events generated by the control.

ActiveX Directory Control

2008-08-24T22:55:00.001-07:00

Frequently we wish to display a list of directories as a control inside a dialog. The standard 'File' dialog is not of much use here since it cannot be used as a control inside another dialog. Also the standard 'File' dialog permits selection of only files and not of directories. To meet this requirement we have developed here an ActiveX directory control. Steps Involved:
We have used the 'MFC ActiveX Control Wizard' to develop the directory control. The steps involved are enumerated below:

Select 'MFC ActiveX Control Wizard' as new project type with project name as 'Dir'. Click on 'OK'.

In Step 1 of 2 select '1' for 'How many controls would you like your project to have?'. Click on 'Next'.

In Step 2 of 2 select 'SysTreeView32' for 'Which window class, if any, should this control subclass?'. Click on 'Finish' to let the wizard generate the code.

Click on the 'Class View' tab and in the PreCreateWindow( ) virtual function you can see the line

cs.lpszClass = _T ( "SysTreeView32" ) ;

This line indicates that SystreeView32 window class has been made as a subclass of the directory control. Hence the messages would be received by the control class before reaching the SystreeView32 window class. To change the style of the tree window we have added:

cs.style |= TVS_HASBUTTONS | TVS_LINESATROOT | TVS_HASLINES | WS_BORDER ;

Next we have added an OnCreate( ) handler to the CDirCtrl class. From the OnCreate( ) handler adddrives( ) function has been called that adds drives to the CString variable. This function in turn calls adddriveitems( ) to add to the tree control drives and a '+' against each drive. The adddriveitems( ) function uses a pointer to CTreeView object to add items to the tree control. This pointer has been defined as a pubic member variable of CDirCtrl class and has been intialised with the handle on the tree control. When we click on '+' sign or double click on the drive name in the tree control, the control tries to send a notification message to the parent that the item is being expanded. Since there is no parent in this control and we want that the control should get the notification we have added the following entry in the message map of CDirCtrl class.

ON_NOTIFY_REFLECT ( TVN_ITEMEXPANDING, onexpanding )

This results into the onexpanding( ) function getting called whenever a notification arrives. This function first deletes the empty enter which was added to get the '+' sign. Secondly, it calls adddir( ) function to add subdirectories of the selected drive. The sub-directories having more directories inside them would get '+' sign before them. On double clicking such sub-directories the control will receive the reflected notification message. Again the control would be transferred to the onexpanding( ) function which will now list the sub-sub-directories of the selected directory. On double clicking the item or single clicking the '-' of the expanded directory, the control gets the reflected message. This time we delete all the entries under this item by calling the deleteallchild( ) function. As we select item in the tree control the control fires an event to the container with the full path of the selected directory. To accomplish this an event with the name sendpath( ) has been added to the CDirCtrl class. The sendpath( ) event has been fired from the handler onSelChange( ) that gets called on selection of any item. If we run this program the control will register itself with the Windows registry on that machine. A dialog box would be displayed asking for the exe file to be used as a container for this control. We can 'Microsoft's ActiveX Test Container' to display the control. Here we have to insert our control from the 'Insert control' box. The container contains of a splitter window. The upper window displays the control and the lower window displays the events generated by the control.

Download