Category Archives: Development

Sharing a Keyboard and Mouse with Windows RT

Anyone who uses computers to create knows that one of the best ways to boost productivity is to add additional screens to your setup. This can be done in several ways. The most direct way is to buy and connect a new display to your system. In addition, applications such as Synergy and Mouse without Borders let you control additional computing devices, such as laptops, using your desktop computer’s mouse and keyboard.

For instance, my current development system uses a primary display and an left-hand display. In addition, I use my laptop as a “third display” with things like Twitter, Skype, and IRC running on it.

Multimonitor

By running Synergy on my desktop computer and my laptop I am abile to freely move my mouse between all three screens, and use my desktop mouse and keyboard with my laptop. Things like copy-and-paste work well too.

One of the cooler ports to come out of the Windows RT jailbreak scene (obviously aside from Quake 2) is the ARM port of Synergy, which you can download here. Setup is simple:

  1. Jailbreak your Windows RT device using this tool
  2. Download the ARM port of Synergy here
  3. Extract the archive and run Launcher.exe
  4. Enter the IP address of your desktop computer (where Synergy should be running in server-mode)
  5. Click Start

Synergy Client Settings

Note that you’ll need to download and run Synergy on your desktop computer as well, and configure Synergy accordingly. If you are using OS X on the desktop, SynergyKM is a friendly Synergy distribution that installs into System Preferences.

SynergyKM

This is great way to use a Windows RT device as an additional small-form display. It’s also very helpful when developing Windows Store apps or WinForms apps for Windows RT. Once you start remote debugging your Windows Store or WinForms app on your Windows RT device, you can simply move your mouse from your development system to your Windows RT device to debug, easily moving the mouse from the app on Windows RT to the IDE for debugging on your desktop.

Visualizing Code Coverage with Xcode

After having a particularly good experience exploring and implementing unit tests in Visual Studio 2012 using the code coverage analysis found in the Premium SKU I decided it was time (past time!) to get a similar handle on testing my iOS applications.

Now I love Xcode but the tooling is, in my opinion, not as mature as Visual Studio in many respects: debugging experience, testing experience, analysis, and integration for 3rd-parties to name a few.

When it comes to unit testing and code coverage with Xcode, the story isn’t nearly as nice as that found in Visual Studio. For instance, your only option for running unit tests is to run all test cases at once. There is no test runner or dedicated UI and there is no way to run individual tests or easily toggle tests (other than individually toggling the membership of .m files in the test target). To put it simply, it’s a far cry from Visual Studio’s Test Explorer, much less something like CodeRush’s Test Runner. See the update at the bottom of the post for clarification on this.

When it comes to visualizing code coverage with Xcode – specifically iOS apps – there are several steps to take and a 3rd-party application is required.

The first step is to configure your iOS app target for code coverage. Select your app target in Xcode (not the unit test target) and, under Build Settings, enable the following settings for the Debug configuration:

  1. Generate Test Coverage Files
  2. Generate Profiling Code
  3. Instrument Program Flow

One Setting

Two Settings

Now, as long as your project is setup with a unit test target, you can click Product and then Test to run your unit tests.

This is where things start to get not-as-pretty-as-Visual-Studio. What this did was generate a bunch of files in a deeply nested location on the file system, namely:

~/Library/Developer/Xcode/DerivedData/[Project Name]-[Random Characters]/Build/Intermediates/[Target Name].build/[Configuration Name]-iphonesimulator/[Target Name].build/Objects-normal/i386

Yes. Really. For example, this is the path for a sample I created:

~/Library/Developer/Xcode/DerivedData/CodeCoverageSample-gtzzspgbzxcdhifewyfazdxkkwum/Build/Intermediates/CodeCoverageSample.build/Test-iphonesimulator/CodeCoverageSample.build/Objects-normal/i386

If you check the contents of this folder after taking the above steps, you should now see a collection of DIA, GCDA, GCNO, and related files.

The next step is to find a friendly way to view these results. There is nothing for this built into Xcode or provided by Apple. This is where a nice open source application called CoverStory comes in handy. This application loads the files generated by Xcode and displays an output similar to other code coverage tools.

You can download CoverStory here. After running the app, click the File menu, then Open, and navigate to the same ridiculous path mentioned previously (press ⌘⇧. to show hidden files & folders in Finder). This should display the breakdown of code coverage for your application.

CoverStory

Selecting .m files will show the individual lines of code covered by the unit tests.

Finally, depending on the linker flags your project uses there may be additional steps required to generate GCDA files with iOS 6. I’ve covered steps for working around that issue in a separate blog post here.

My next step will be to look into GHUnit, an alternative to the unit testing bundled into the Xcode IDE (OCUnit). While not integrated into Xcode, GHUnit does offer several improvements such as the ability to run individual tests or failed tests.

UPDATE: Martin Pilkington was kind enough to call to my attention that there is another way to enable and disable tests and test cases using Xcode schemes. Click on Product, then Scheme, then Edit Scheme (or press ⌘<). On the left of the scheme sheet select the Test action. On the right, in the list under Tests, you can expand the individual test targets, test cases, and tests, and enable and disable them via the checkbox in the last column.

Scheme Test Action Tests

You can also multi-select multiple tests and test cases and right-click to disable or enable a group.

Disable Tests

Thanks Martin! And while this is absolutely better than toggling the target membership of the .m test case files, I’d still like the ability to easily run a single test or test case. Right now, to target coverage of a single test or test case, I have to disable hundreds (on a larger project) of tests, then work on my one test, only to re-enable hundreds of tests afterwards.

What I’d personally like is the sort of simple features found in other unit test runners: easily select and run a single test, a single test case, failing tests, or all tests (without having to manually and individually select which tests to run).

UPDATE: Xcode 5 has since been released by Apple and now includes a full-blown Test Navigator for running unit tests.

Fix for Missing Code Coverage Files with Xcode

One of the things I’ve been working with lately is code coverage analysis using Xcode and CoverStory.

CoverStory Demo

While the experience is not as polished and complete as Visual Studio 2012, I’ve gotten most things working well enough.

One of the bigger hurdles I ran into was missing code coverage files when using iOS 6 to run unit tests. If I used iOS 5 or 5.1, the code coverage files were generated just fine. However, if I used iOS 6.0 or 6.1 the GCDA files specifically were not created.

I moved past this for a while but, as my code coverage increased, it became more important for me to test the iOS 6 specific code paths. I tried the Apple developer forums but had no luck, so I continued digging myself.

The first thing I noticed was that a brand new project created with Xcode did create GCDA files for iOS 6 and 6.1. This was promising as it meant that the problem was somewhere in my project.

After spending some time comparing project.pbxproj files (thanks to Marc Hoffman for pointing me in that direction), I was finally able to narrow the problem down to its cause. If you have an old enough iOS project, there’s a decent chance you’ll have one of the following flags specified in your Build Settings for Other Linker Flags:

  • -weak_library /usr/lib/libSystem.B.dylib
  • -weak-lSystem

Bad Setting

Among other things these flags allow apps that use features such as blocks and backgrounding to build for iOS 3. As it turns out, this setting also causes GCDA files not to be created when generating code coverage under iOS 6.

There are two options here:

  1. If the flag is not needed anymore you can remove it
  2. If the flag is necessary, you can create a new configuration for unit testing (this is also useful for setting up preprocessor macros)

In Xcode, select your project and select the Info tab. Click the plus button under Configurations and create a new configuration based on Debug.

Add Config
Dupe Debug

Name the new configuration Test.

Name Test

On the Build Settings tab, locate Other Linker Flags. Expand the setting so that each configuration is shown underneath it. For the Test configuration, remove the offending flag.

Clear Flag for Test

Now that the Test configuration is setup not to use the offending flag, you need to tell Xcode to use this configuration when testing. You can do this using schemes. Click on Product, then Scheme, then Edit Scheme (or alternatively press ⌘<). On the left of the scheme sheet select the Test action.

Scheme Test Action

On the Info tab, change Build Configuration from Debug to Test.

Select Test Config

With these settings in place the proper code coverage files should now be generated when running unit tests with iOS 6. Note that the path to the code coverage files will change, as the path is based on the configuration name which is now Test.

CoverStory

This took a while to figure out and hopefully Apple will fix the issue (I’ve submitted a bug report). In the meantime hopefully this post helps others who run into this issue!

Hip Shot Version 1.5 Available

Version 1.5 of Hip Shot is now available for download on the Apple App Store. This update to Hip Shot introduces the following improvements:

  • Added the ability to disable individual positions within each location
  • Added support for displaying information in Spanish and German

The #1 request from users since the release of Hip Shot has been the ability to disable individual positions in the application, for example subregions of the left thigh:
Disable Position

With this update it is now possible to customize these individual disabled positions in the Settings tab.

This update also brings localized translations for both Spanish and German. Now, if you have your language in iOS set to either of these languages the text in Hip Shot will be shown in your native language.

If you are able to help translate the phrases in Hip Shot, visit hipshotapp.com and click the link at the bottom of the page.

Remote Debugging WinForms Desktop Apps on Windows RT

Once you have your Windows RT device jailbroken and running your WinForms applications it would be very handy to be able to remotely debug those apps running on Windows RT, similar to what can be done when developing Windows Store apps.

The first step is to share the project folder. Right-click the project in the Solution Explorer in Visual Studio and click “Open Folder in File Explorer”. Then use the context menu in Explorer to share the folder with a common Windows user. The basic sharing wizard worked fine in my testing.

Sharing Wizard

Next we need to setup debugging for the project. Unlike a Windows Store application the remote debugger options aren’t available from the Start debugging button in VS2012. Each project type in Visual Studio seems to surface its remote debugging options in a slightly different way.

Right-click the project in Solution Explorer and click Properties. On the Debug tab, select “Start external program” and enter the path to your exe using the UNC (network) path. Then, check “Use remote machine” and enter either the computer name or IP of your Windows RT device.

Debug Settings

Switch to the Windows RT device and start the Remote Debugger from the Start screen. If you do not have the Remote Debugger for Windows RT installed you can download the Remote Tools for Visual Studio 2012 on your Windows RT device here, under Additional software. Make sure you select the ARM download.

With the Remote Debugger running on your Windows RT device, you should now be able to click Play in VS2012. The application will launch on your Windows RT device, and you can set breakpoints and debug as you normally would.

Windows RT Debugging

Throw in the Remote Desktop app in Windows RT along with the split screen feature and you’ll be debugging from your couch in no time!

RDP Debugging

Creating and Running WinForms Desktop Apps on Windows RT

I’ve been following the developments on the home-brew front for Windows RT for the past few months. As you’ve probably heard, a “jailbreak” for Windows RT was documented several days ago. This “jailbreak” allows the user to run desktop applications that are not signed by Microsoft. You can ready more about how the exploit works here.

The original exploit was pretty difficult to do and involved using a combination of a Windows Store app to open a command prompt that is then able to run some unsigned applications, and then using that command prompt to exploit a bug in Windows RT that stores a new value in memory used when checking if an app is signed. The actual exploit also required the user to use remote debugging from VS2012 in order to get the exploit payload into memory on the Windows RT device and then setting several breakpoints, redirecting the RT device to that payload in memory. Yikes. This mostly just led me to BSOD my device repeatedly.

However, a couple of days ago a much simpler jailbreak tool was released that just involves a double-click and following a few prompts. You can read about the tool and download it here.

Once you have Windows RT able to run unsigned desktop apps you can download a whole set of FOSS apps that have been recompiled for ARM such as Notepad++, PuTTY, bochs, and 7-Zip. The list is growing daily, and there’s even an app you can install on Windows RT that makes for a non-official “RT Desktop Store”.

RT Desktop Store

One of the very cool and often overlooked aspect of all this, though, is that any pure .NET 4.5 application will also run on Windows RT once jailbroken. I tested this myself and it worked without any extra steps. I created a new C# .NET 4.5 application and was able to run it, unmodified, on my Surface RT.

WinForms on Windows RT

Microsoft has stated that they do not see the current jailbreak as a security vulnerability, though they could also (obviously) not promise that the exploit will remain unpatched. If you want to ensure your device remains “vulnerable” there are steps to disable automatic updated for Windows RT here.

Using RemObjects Train for Automated Testing and Building

Train
I was recently tasked with coming up with an automated build process for one of my projects. Given the available free and commercial tools on the market I decided to give RemObjects Train a try. Train is an Open Source project from RemObjects Software (one of their many Open Source offerings). Benefits of Train include:

  • It is Open Source
  • It has a simple, extensive, extensible API
  • Scripts are friendly to version control (based on ECMAScript rather than, say, XML)
  • The tool is simple, light-weight
  • It’s free – as in beer

My requirements for the build process were limited (one of the reasons I wanted a free, simple tool rather than a capable commercial tool such as FinalBuilder or Automated Build Studio):

  1. Support for running and failing based on unit tests (using MSTest)
  2. Support for building a release configuration of several .NET assemblies
  3. Support for packaging assemblies using Inno Setup
  4. Configurable version number used for assemblies and installer

Train ended up being a very elegant and useable solution. The scripts are easy to create and maintain – I used Sublime Text 2 with its JavaScript syntax highlighting.

In the end I created two scripts: RunTests.train and BuildRelease.train. By naming my scripts with a .train extension I was able to associate them with Train.exe and can run my unit tests and build releases with a simple double-click.

My RunTests script looks like this:

//rebuild unit tests
msbuild.rebuild("../ExchangePurge.UnitTests/ExchangePurge.UnitTests.csproj", { configuration: "Release" });
msbuild.rebuild("../ExchangeSync.UnitTests/ExchangeSync.UnitTests.csproj", { configuration: "Release" });

//function for running MSTest unit tests, detecting failures
function runTest(testAssemblyPath) {
	var mstestPath = "C:/Program Files/Microsoft Visual Studio 11.0/Common7/IDE/MSTest.exe";
	shell.exec(mstestPath, "/testcontainer:" + testAssemblyPath);
}

//run unit tests
runTest("../ExchangePurge.UnitTests/bin/Release/ExchangePurge.UnitTests.dll");
runTest("../ExchangeSync.UnitTests/bin/Release/ExchangeSync.UnitTests.dll");

The script is pretty straight-forward. It builds release versions of my unit test assemblies using the msbuild API provided by Train (API documentation can be found here). It then defines a simple function – runTest – for running unit tests with MSTest.exe using the shell API. Finally, the function is called for each unit test assembly.

My BuildRelease script looks like this:

//run unit tests
run("RunTests.train");

//get version info from VersionInfo.ini
var versionInfoIni = ini.fromFile("VersionInfo.ini");
var appVersion = versionInfoIni.getValue("VersionInfo", "AppVersion", "1.0");

//update the assembly versions for each .NET project using the above version info
msbuild.updateAssemblyVersion("../ExchangePurge/Properties/AssemblyInfo.cs", appVersion);
msbuild.updateAssemblyVersion("../ExchangeSync/Properties/AssemblyInfo.cs", appVersion);
msbuild.updateAssemblyVersion("../ExchangeSyncAdmin/Properties/AssemblyInfo.cs", appVersion);

//rebuild each .NET project
msbuild.rebuild("../ExchangePurge/ExchangePurge.csproj", { configuration: "Release" });
msbuild.rebuild("../ExchangeSync/ExchangeSync.csproj", { configuration: "Release" });
msbuild.rebuild("../ExchangeSyncAdmin/ExchangeSyncAdmin.csproj", { configuration: "Release" });

//export environment variable for InnoSetup to use for app version
export("ES_AppVersion", appVersion);

//build an InnoSetup installer
inno.build("Installer.iss", { });

//copy setup.exe to folder for this version
folder.create("Output/" + appVersion);
file.copy("Output/setup.exe", "Output/" + appVersion);

This script is a bit more complex but still pretty easy to understand. It starts by using the Train API to run the RunTests script. Because of the nature of MSTest.exe and Train.exe, if the RunTests.train script fails then the BuildRelease.train script will be aborted.

The script then uses Train’s ini API to read a configurable version from VersionInfo.ini. Next, the msbuild API is used to both update the assembly version information and build release versions of each assembly.

Next, I used the Train API to export an environment variable – ES_AppVersion – with the version information read earlier from the INI file. My Inno Setup script uses ISPP, which is installed by default if you download an Inno Setup QuickStart Pack. At the top of my Installer.iss Inno Setup script I used the following code (thanks to Carlo from RemObjects):

#define MyAppVersion GetEnv("ES_AppVersion")
#if MyAppVersion == ""
#define MyAppVersion "1.0"
#endif

And then further down use the MyAppVersion ISPP macro:

[Setup]
AppVersion={#MyAppVersion}

This bit of ISPP macro code will make use of the ES_AppVersion environment variable set by the BuildRelease.train script to define the installer’s version.

Finally, the last lines of the BuildRelease.train script use the folder and file Train API’s to copy the created installer to a folder named after the version read from the INI file.

So far I’m very happy with Train as a simple, capable tool for automated testing and building. If you’d like to read more about Train you can refer to Marc Hoffman’s post on the project as well as the official documentation.

Improvements to Server Mode Grid in DevExpress VCL 12.2

Version 12.2 of the DevExpress VCL controls brings several improvements to the Server Mode feature of the ExpressQuantumGrid control. Both Advantage Database and PostgreSQL are now supported. There is also now support for in-place editing and banded table views when using Server Mode.

But one of the most welcome improvements, I think, is the new capability to specify custom SQL for the SELECT statement that the Server Mode data source components will use. When I last blogged about ExpressQuantumGrid Server Mode, the most vocal feedback was the need to specify custom SELECT statements. Until now this was only possible using Views within the underlying database. But starting with 12.2, DevExpress has introduced two new entries to the collection of Server Mode components to support using custom queries: TdxServerModeADOQueryDataSource and TdxServerModeDBXQueryDataSource. These are counterparts to the existing data source components that feature a SQL property for specifying the SELECT statement.

To see how easy this is to put into practice, download an open my sample from this blog post. Make sure you’ve also created a database and used the contained SQL scripts to create and populate the LotsaRows table.

Open Unit1 and select the Design tab. Delete the existing TdxServerModeADODataSource and replace it with a TdxServerModeADOQueryDataSource.

Setting up the TdxServerModeADOQueryDataSource component is very similar to setting up its non-query counterpart. For the Connection property select the existing ADOConnection1 component and for the SQLAdapter property, specify MSSQL Adapter. For the new SQL property, click the ellipsis button and enter the following SQL statement:

With the SQL statement specified, click the drop down arrow next to KeyFieldNames and select the ID column. Finally, set Active to True.

That’s it for setting up the TdxServerModeADOQueryDataSource. Now, select the Server Mode table view on the form and bind it to the TdxServerModeADOQueryDataSource using the DataController.DataSource property.

At this point you should see that the project is working again more or less as it did in my previous blog post. A million rows of data show, quickly, within the TcxGrid control, featuring fast grouping and sorting.

To actually see the new feature in practice, add a new TcxCheckBox to the main form, adjusting the grid control and giving it a proper caption.

And handle the Click event of the TcxCheckBox with the following code:

procedure TForm1.Column3CheckBoxClick(Sender: TObject);
var
  SQL: string;
begin
  //improve performance by disabling gridview updates during data operations
  cxGrid1DBTableView1.BeginUpdate;
  try
    dxServerModeADOQueryDataSource1.Active := False;

    //build SQL statement based on checkstate
    SQL := 'SELECT * FROM LotsaRows';
    if Column3CheckBox.Checked then
      SQL := SQL + ' WHERE Column3 = 1';

    dxServerModeADOQueryDataSource1.SQL.Text := SQL;
    dxServerModeADOQueryDataSource1.Active := True;
  finally
    cxGrid1DBTableView1.EndUpdate;
  end;
end;

And that’s it! By swapping out the existing TdxServerModeADODataSource for its query-enabled counterpart, we can now specify a custom SQL SELECT statement and still benefit from “blazing fast” population, sorting, and grouping of one million rows of data.

You can download the updated Delphi sample source code here.

Open Source Solution for Migrating from ExpressScheduler to XtraScheduler

Introduction

Express2XtraScheduler is a .NET solution consisting primarily of two assemblies and a WinForms utility that simplify importing database data from the format stored by the DevExpress VCL ExpressScheduler into a format supported by the WinForms XtraScheduler control.

Contents

  • Express2XtraScheduler.Core.dll provides the functionality needed to import data from one format to another given a pair of database settings
  • Express2XtraScheduler.UI.dll provides UI controls for mapping source and destination database settings
  • Express2XtraScheduler.exe uses these assemblies to provide a simple utility for transferring data
  • ExpressSchedulerInterop.dll is a Delphi DLL used to read resource information stored as Delphi variants

Express2XtraScheduler App

The solution also contains two simple applications that allow testing both VCL and WinForms scheduler data: ExpressSchedulerApp and XtraSchedulerApp.

Resources

Below are links to blog posts that discuss some of the techniques used by this solution:

Availability

The source code for the Express2XtraScheduler solution is available immediately on this public Git repo hosted at Bitbucket.

Getting Started with the DevExpress VCL Wizard Control

Version 12.2 of the DevExpress VCL controls contains the long awaited ExpressWizard control. DevExpress released a WinForms version, their XtraWizard control, over four years ago. They have now delivered a native version of this same control for the Delphi VCL.

Features of the ExpressWizard control mirror those touted by DevExpress for their XtraWizard control:

  • You can design dialogs that conform to either the Wizard 97 or Wizard Aero standard… creating standard based UIs has never been easier.
  • Cutting-edge interfaces are only a few clicks away and developers can be certain that their wizard control will look and feel the same as all other DevExpress controls within their applications.
  • By using DevExpress fade in/fade out effects, developers can easily enhance their wizards during page transition operations.

It’s worth noting that the ExpressWizard control is a new product in the VCL subscription. This means that, when installing 12.2, you should select “Modify and Update” rather than simply “Update”. This will allow you to select ExpressWizard for installation.

DX VCL Setup

To get started with the ExpressWizard control, create a new VCL Forms Application in Delphi. Next, use the File, New, Other menu item to display the New Items dialog. Select Delphi Files on the left. On the right you’ll see a new entry: DevExpress 12.2 Wizard Form.

New Items Template

Select this item and click OK.

Using this Wizard Form template nets you three things:

  1. A new form descended from TdxWizardControlForm. This is necessary to support the Aero glass features of the TdxWizardControl (similar to the TdxRibbonForm).
  2. A TdxWizardControl parented on the new form
  3. A single TdxWizardControlPage added to the wizard control

The TdxWizardControl is also found on the component palette and can be dropped on any form. However, if you want to use the Aero style wizard, you’ll need to change your form’s ancestor. Starting in this manner (versus the template) will also give you an empty wizard control with no pages.

To check out the basic features of the wizard control, I’d like a total of three pages: a Welcome page, an Agreement page, and a Finished page. For the Agreement page, I’d like the Next button disabled until the user checks a checkbox. I’d also like the wizard to use the Aero style rather than the Wizard 97 style.

Pages can be added to the wizard control in two ways, both available from the TdxWizardControl and TdxWizardControlPage context menus.

Wizard Context Menu

You can either click New Page directly, or click Page Collection Editor to display a dialog for managing the wizard pages.

Page Collection Editor

Using one of these two methods, add two new pages to the TdxWizardControl. As with the rest of the DevExpress VCL controls, the designtime editors and experience are top notch. You can actually click on the Next and Back buttons at designtime to switch through the wizard pages.

Use the Next and Back buttons to select each wizard page. Then, adjust the Header.Title property so that the pages read Welcome, Agreement, and Finish. You can also adjust the Header.Description property, but this line of text will not be visible when using the Aero style wizard.

Next, add a TcxCheckBox to the Agreement page in the wizard and adjust its Caption property to indicate accepting the agreement.

Added Checkbox

In order to show the wizard we’ll need some code on our main form. Open up Unit1 and click the Design tab. Add a TcxButton to the form. While we’re here, let’s take a very quick look at a new feature of the TcxButton in 12.2. Set the Kind to cxbkCommandLink. Assign values to both the Caption and CommandLinkHint properties. Bump the Font.Size property up to 12 and resize the control to fit its contents. Finally, assign a OnClick event handler with the following code:

uses Unit2;

{$R *.dfm}

procedure TForm1.cxButton1Click(Sender: TObject);
begin
  Form2 := TForm2.Create(Self);
  try
    Form2.ShowModal;
  finally
    Form2.Free;
  end;
end;

Click Run (or press F9) to check out the new button style.

TcxButton Runtime

Pretty nice huh?

Click the TcxButton to show the wizard dialog. You’ll see that, with no code, you can click Back and Next to navigate through the pages. In addition, the Back button automatically disables when you are on the first page. Also, the Next button caption automatically changes to Finish when you are on the last page of the wizard. However, clicking Finish and Cancel do not currently do anything. In addition, we need some code for our “agreement” and the wizard is still not the Aero style.

Close the app and return to Unit2. Select the TdxWizardControl and set the ViewStyle property to wcvsAero in the Object Inspector. Handle the OnCreate event of the TdxWizardForm itself with the following code to initialize the wizard:

procedure TForm2.FormCreate(Sender: TObject);
begin
  dxWizardControl1.ActivePageIndex := 0;
end;

Next, handle the OnClick event of the TcxCheckBox with the following code:

procedure TForm2.cxCheckBox1Click(Sender: TObject);
begin
  dxWizardControl1.Buttons.Next.Enabled := cxCheckBox1.Checked;
end;

Select the TdxWizardControl and handle its OnPageChanged event with the same logic:

procedure TForm2.dxWizardControl1PageChanged(Sender: TObject);
begin
  dxWizardControl1.Buttons.Next.Enabled := (dxWizardControl1.ActivePageIndex <> 1) or cxCheckBox1.Checked;
end;

Finally, handle the TdxWizardControl’s OnButtonClick event with the following code:

procedure TForm2.dxWizardControl1ButtonClick(Sender: TObject; AKind: TdxWizardControlButtonKind; var AHandled: Boolean);
begin
  if AKind = wcbkCancel then
    ModalResult := mrCancel
  else if AKind = wcbkFinish then
    ModalResult := mrOk;
end;

If you run the application again you’ll see the wizard is now functional. It starts on the Welcome page, and the Next button is disabled for the Agreement page unless the checkbox is checked. Finally, clicking Cancel or Finish dismisses the dialog.

Wizard Animated

Also, notice that each screen of the wizard fades in and out smoothly. Very nice!

You can download the Delphi source code for this example here.