Ivo Manolov's Blog : Win32

TestApi v0.4 Released!

ivom — Sat, 21 Nov 2009 21:14:00 GMT

I am happy to announce that we have just released version 0.4 of TestApi – the testing API library - on Codeplex.

Version 0.4 contains the following additions and modifications:

An improved Combinatorial Variation Generation API with added support for parameter value weights and tags (for “negative” variations);
A new Memory Leak Detection API allowing capture, comparison and serialization / de-serialization of memory snapshots of a running process;
A new Object Comparison API allowing comparison of arbitrary .NET objects, using arbitrary object comparison strategies;
A new Text String Generation API, allowing generation of random strings, for testing purposes;
Various documentation and sample improvements.

We will be blogging about some of these API in the near future. As always, TestApi is available on http://codeplex.com/testapi.

TestApi Slide-Deck from the Patterns & Practices Summit

ivom — Thu, 15 Oct 2009 05:23:00 GMT

This week is Microsoft’s Patterns & Practices summit in Redmond . Earlier today I gave a 15-minute presentation on TestApi . Here is the slide-deck: Test Api View more presentations from ivom1234 ....(read more)

TestApi v0.3 Released!

ivom — Fri, 24 Jul 2009 04:52:00 GMT

I am happy to announce that we have just released the third preliminary version of TestApi -- the testing API library. This version introduces some fairly significant changes and new features:

New name spaces (under Microsoft.Test) and new binary names;
New source code organization;
A fairly comprehensive acceptance tests suite (using xUnit);
Fault Injection APIs for managed code (using CLR profiler technology);
Combinatorial Variation Generation API (using the PICT algorithm);
A redesigned Application Control API;
Updates to the Visual Verification API;
Updated samples and documentation; new conceptual documents;

We will be blogging in detail about some of the features in v0.3 in the coming weeks.

TestApi is a policy-free API library, delivering Microsoft testing technology in an easy to use package. It can be used from within any tool (VSTS, NUnit, xUnit, etc.) or environment to automate the testing for desktop and in-browse applications on Windows.

TestApi v0.3 is available on http://testapi.codeplex.com. Thanks for all your feedback. Keep it coming! :)

TestApi v.0.2 Released!

ivom — Fri, 24 Apr 2009 15:53:52 GMT

I am excited to announce that we have just released the second preliminary version of TestApi – the testing API library – on http://codeplex.com/testapi!

The v.0.2 package includes the following additions and modifications:

Improved command-line parsing APIs
Improved visual verification APIs
- A new tolerance map visual verifier in SnapshotToleranceMapVerifier
- New operations on snapshot (And and Or) allowing you to mask
- A new Snapshot.FromWindow(...) constructor with ability to include and exclude the window chrome in snapshots.
- Improved visual verification internals
New application control APIs, enabling in-proc and out-of-proc automation of client applications
Expanded conceptual documentation
CHM API documents (in addition to the HTML documents)
Addition of NUnit and xUnit usage samples (for all of the non-VS crowd out there)

Check out the package and let us know of any feedback.

Introduction to TestApi – Part 2: Command-Line Parsing APIs

ivom — Thu, 18 Dec 2008 01:15:00 GMT

Command-line parsers remind me of linked lists in C++: everybody has written several at various points in their careers. While everybody should write each of those at least once, I doubt that many people out there are particularly excited about writing and re-writing fundamental data structures on a regular basis – it gets old very quickly. Not to mention that doing so is error-prone and decreases the maintainability of a world that’s already hard to maintain.

That’s why modern-day frameworks such as .NET provide standard implementations of the common data structures. And that’s why TestApi provides a reusable command-line parsing APIs via the CommandLineDictionary and CommandLineParser classes, the latter being a type-safe layer on top of the former. Obviously, these are not test APIs per se – they are general utility APIs that happen to be more often used when writing tests.

A few quick examples follow.

Simple Command-Line Parsing

As seen from the first example below, extracting command-line parameters that are primitives is easy. Primitive command-line parameters are either boolean (e.g. the “verbose” flag below), or a key-value pair, that one can extract with the indexer of the CommandLineDictionary instance (see the “testId” key below), just as one would expect from a Dictionary.

// 
// EXAMPLE #1: Parsing a command-line such as "RunTests.exe /verbose /testId=123"
// 

using System;
using Microsoft.Test;

public class Program 
{ 
    public static void Main(string[] args) 
    { 
        CommandLineDictionary d = new CommandLineDictionary(args);

        bool verbose = d.ContainsKey("verbose");
        int testId = Int32.Parse(d["testId"]);
                
        // use the parsed command-line parameters
    }
}

By default flags/keys are indicated with the forward slash (“/”) character and values are indicated with the equals character (“=”), but the user can override that upon initialization of of the CommandLineDictionary object:

// 
// EXAMPLE #1b: Parsing a command-line such as "RunTests.exe –verbose –testId:123"
// 

...
        CommandLineDictionary d = new CommandLineDictionary(args, '-', ':');
...

Finally, you one can use the ToString method to get a string representation of the command-line arguments.

Command-Line Argument Structures

Another common pattern when dealing with command-line arguments is populating a structure which contains all parsed arguments. The CommandLineParser class makes this easy:

// EXAMPLE #2:
// Sample for parsing the following command-line:
// Test.exe /verbose /runId=10
// This sample declares a class in which the strongly typed arguments are populated
public class CommandLineArguments
{
   bool? Verbose { get; set; }
   int? RunId { get; set; }
}

CommandLineArguments a = new CommandLineArguments();
CommandLineParser.ParseArguments(a, args);

Type-Safe Commands

A third common approach is forming strongly-typed commands from the command-line parameters. This is common for cases when the command-line looks as follows:

some-exe COMMAND parameters-to-the-command

The parsing in this case is a little bit more involved:

Create one class for every supported command, which derives from the Command abstract base class and implements an expected Execute method.
Pass an expected command along with the command-line arguments to CommandLineParser.ParseCommand – the method will return a strongly-typed Command instance that can be Execute()-d.

// EXAMPLE #3:
// Sample for parsing the following command-line:
// Test.exe run /runId=10 /verbose 
// In this particular case we have an actual command on the command-line (“run”), 
// which we want to effectively de-serialize and execute.
public class RunCommand : Command
{
   bool? Verbose { get; set; }
   int? RunId { get; set; }

   public override void Execute()
   {
      // Implement your "run" execution logic here.
   }
}

Command c = new RunCommand();
CommandLineParser.ParseArguments(c, args); 
c.Execute();

Besides the parsing logic, CommandLineParser provides a few additional helper methods. One of them is CommandLineParser.PrintCommandUsage, which prints the usage for specific commands (or all supported commands) to the console.

In Conclusion

The command-line parsing APIs released with TestApi provide a simple and “layered” access to the command-line. Strictly speaking these APIs are not test APIs, but have nevertheless been included in TestApi as tests often have a need of parsing parameters on the command-line.

TestApi v.0.1 Released

ivom — Sat, 06 Dec 2008 21:30:00 GMT

On Friday, we released the first preliminary version of an experimental library with test APIs, named ... TestApi :). With this library, we are sharing internal Microsoft testing technology with the developer and tester community.

We wanted to keep the first release small and contained, so that it can be easily grasped and critiqued, but complete enough to provide actual user value and to clearly demonstrate the direction of this effort.

In addition to the binaries and the source code, we have provided full documentation (both MSDN-style API documents and conceptual documents) as well as a couple of VSTS samples to get you started.

Check out the release on http://codeplex.com/TestApi and let us know what you think.

WPF-Win32 Interop Part 2: Hosting Win32 Controls (ListBox) in WPF Windows

ivom — Mon, 08 Oct 2007 07:07:00 GMT

Introduction

This article describes hosting of a Win32 user control in a WPF window. It is supplemented by the following two projects, which show working examples of the material presented in the document:

Win32ControlInWpfWindow_CompositeWin32Messages
Win32ControlInWpfWindow_SimpleWin32Messages

The only difference between the two projects is the Win32ListBoxHost.cs file. The differences between the two versions of the file are related to the material covered in the “Simple” Messages vs “Composite” Messages section below. You can view the differences between the two versions of the file by using a utility such as WinDiff.exe, which is shipped with the Windows SDK.

This article is based on the material available on the WPF/Win32 interoperability portal on MSDN.

Hosting of a Win32 Control in a WPF Window

In traditional Win32 programming, user controls (buttons, listboxes, etc.) are instantiated through a call to the CreateWindow or CreateWindowEx APIs. Every control has a unique (per session) identifier of type HWND[1] and is recognized as a separate window (albeit a child window) by the window manager of the OS. What this means is that the window manager of the OS has the ability to do hit-testing[2] of the user control without the assistance of the parent window and is thus capable of sending window messages (e.g. WM_LBUTTONDOWN, etc.) directly to the user control. These window messages are typically intercepted and processed by the message loop of the parent window, but can also be processed by the user control.

In WPF programming user controls are not separate windows with separate HWNDs. Hit-testing is accomplished by the Visual layer in the WPF stack. Thus the window manager of the OS sends messages only to the top-level WPF window.

Hosting of a Win32 user control in a WPF window is accomplished using the following steps:

Create a class deriving from HwndHost;
In the HwndHost-derived class implement 3 methods declared in HwndHost (BuildWindowCore, DestroyWindowCore and WndProc):

class MyHost : HwndHost

{

// Public adapter interface goes here

protected override HandleRef BuildWindowCore(HandleRef hwndParent)

{

// PInvoke to CreateWindow(Ex)...

return new HandleRef(this, hwnd);

}

protected override void DestroyWindowCore(HandleRef hwnd)

{

// PInvoke to DestroyWindow

}

protected override IntPtr WndProc(

IntPtr hwnd,

int msg,

IntPrt wparam,

IntPtr lparam,

ref bool handled)

{

// Handle incoming messages here.

// The incoming messages are typically delegated

// to the hosted control.

}

You use the BuildWindowCore to instantiate the Win32 user control you want to host. This is typically done through a call to the CreateWindow / CreateWindowEx API. Similarly, in DestroyWindowCore you destroy your Win32 user control, typically by a call to the DestroyWindow API.

The WndProc method allows you to handle incoming window messages.

In your HwndHost-derived class (MyHost in this particular example), declare an adapter interface[3] to allow communication with the hosted Win32 control. In order to ensure reusability of the host class in different WPF applications, you should strive to avoid any Win32 idiosyncrasies in the interface. Instead, the adapter interface should conform to the .NET coding and style guidelines and should hide the fact that there is an underlying Win32 control.

For example, if your HwndHost-derived class is wrapping a Win32 listbox, then it probably makes sense to expose basic listbox methods such as:

· AddItem

· DeleteItem

· SelectedItemIndex {get; set}

· SelectedItemText {get;}

· SelectionChanged event (see the “Communicating Win32 Events to the WPF Window” section later in this document)

Conversely, it is not a good idea to expose a method such as SendMessage, wrapping the Win32 SendMessage API.

In the XAML file declaring the UI of your WPF window, add a declaration for your HwndHost class:

<Window

x:Class="Win32ControlInWpfWindow.MainWindow"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:custom="clr-namespace:Win32ControlInWpfWindow;assembly="

Title="Win32 Control in a WPF Window"

Height="500" Width="600"

<custom:Win32ListBoxHost x:Name="listbox" Width="100" Height="100"/>

</StackPanel>

</Window>

Note how the XAML file above defines the name space for your HwndHost-derived class (the “custom” namespace) and the assembly where the class is implemented. In this particular case the “assembly=” directive points to nothing, which indicates that the host class is implemented in the same assembly as the one of the MainWindow class.

“Simple” Messages vs “Composite” Messages

In a traditional Win32 application, you display a number of Win32 user controls in a top-level Win32 window. The top-level window is typically handling all window messages resulting from interaction of the user with the controls through a top-level WindowProc.

As the user interacts with the controls on the window, the top-level WindowProc receives both “simple” messages (e.g. WM_LBUTTONDOWN, etc.) that are generated by the OS window manager as well as “composite” messages (e.g. WM_COMMAND, etc.) that are generated by the user controls and sent as notifications to the parent window[4].

These “composite” notifications present a problem in the WPF hosting case, because there is no parent window WindowProc to process them[5]. As a result, in the code below would not really work as expected:

class MyHost : HwndHost

{

protected override HandleRef BuildWindowCore(HandleRef hwndParent)

{

_hwndListBox = CreateWindowEx(

0, "listbox", "",

WS_CHILD | WS_VISIBLE | LBS_NOTIFY | WS_VSCROLL | WS_BORDER,

0, 0,

(int)Width, (int)Height,

hwndParent.Handle,

IntPtr.Zero,

0);

return new HandleRef(this, _hwndListBox);

}

protected override IntPtr WndProc(

IntPtr hwnd,

int msg,

IntPrt wparam,

IntPtr lparam,

ref bool handled)

{

switch (msg)

{

case WM_COMMAND:

// This code-path will never get hit as the listbox control will

// never receive the WM_COMMAND message that it posts to its parent

break;

case WM_LBUTTONDOWN:

// This code-path will get hit as the listbox control will

// be receiving the message from the OS window manager

break;

}

...

}

In most cases handling “simple” messages in the WndProc method is sufficient, although it may be somewhat cumbersome.

There are, however, cases in which you would want to receive “composite” messages. To achieve this, you need to create an artificial parent HWND, so that you can receive the “composite” notifications, generated by the hosted child windows. In other words you end up with the following general structure:

This is achieved as follows:

class MyHost : HwndHost

{

protected override HandleRef BuildWindowCore(HandleRef hwndParent)

{

_hwndListBoxParent = CreateWindowEx(

0, "static", "",

WS_CHILD,

0, 0,

(int)Width, (int)Height,

hwndParent.Handle,

IntPtr.Zero,

0);

_hwndListBox = CreateWindowEx(

0, "listbox", "",

WS_CHILD | WS_VISIBLE | LBS_NOTIFY | WS_VSCROLL | WS_BORDER,

0, 0,

(int)Width, (int)Height,

_hwndListBoxParent,

IntPtr.Zero,

0);

return new HandleRef(this, _hwndListBoxParent);

}

...

Private IntPtr _hwndListBoxParent = null;

Private IntPtr _hwndListBox = null;

}

Communicating Win32 Events to the WPF Window

With the code above we can capture and process the window messages sent to the hosted Win32 user control. We do that in the WndProc method.

In addition to that we need to be able to inform interested WPF elements of the fact that we have received a certain event. For example, a hosted Win32 button may need to inform a WPF textbox that is has been clicked, a hosted Win32 listbox may need to inform a WPF textbox that the selection in the listbox has been changed, etc. The traditional way to do expose that capability in .NET is through events.

So we declare a public event and a protected event handler as follows:

class MyHost : HwndHost

{

...

public event EventHandler SelectionChanged;

protected void OnSelectionChanged(EventArgs args)

{

EventHandler handler = SelectionChanged;

if (handler != null)

{

handler(this, args);

}

...

}

This allows the users of the class to write code such as:

class Test

{

public static void Main()

{

...

myHost.SelectionChanged += MySelectionChangedHandler;

...

}

public void MySelectionChangedHandler(EventArgs args)

{

// This method gets called whenever someone changes the selection in the Win32

// control (which is presumably a listbox) hosted in MyHost.

}

...

}

Adding Tab and Accelerators Support for the Hosted Win32 Control

One current problem that you will see in the application is that keyboard navigation does not work well with the Win32 control. Keyboard navigation has several aspects:

a) Enabling tabbing into and out of the hosted Win32 control (listbox)

b) Enabling keyboard navigation within the hosted Win32 control (e.g. moving the selection in the listbox)

c) Supporting access keys

In order to achieve a) and b), your HwndHost-derived class needs to implement two methods of the IKeyboardInputSink interface: TabInto and TranslateAccelerator.

The TabInto method gives you (as the name suggests) tabbing into the Win32 listbox (by pressing either Tab or Shift+Tab). In this particular case, the implementation of TabInto is trivial because we only have a single Win32 control:

class Win32ListBoxHost : HwndHost, IKeyboardInputSink

{

...

bool IKeyboardInputSink.TabInto(TraversalRequest request)

{

if (request.FocusNavigationDirection == FocusNavigationDirection.Next)

{

NativeMethods.SetFocus(_hwndListBox);

}

else

{

NativeMethods.SetFocus(_hwndListBox);

}

return true;

}

...

}

The TranslateAccelerator method gets called whenever the OS sends keyboard messages (WM_KEYDOWN or WM_SYSKEYDOWN) to the application. We use the method to intercept pressing of the up and down arrow so that we can change the selected item in the hosted Win32 listbox:

class Win32ListBoxHost : HwndHost, IKeyboardInputSink

{

...

bool IKeyboardInputSink.TranslateAccelerator(ref MSG msg, ModifierKeys modifiers)

{

bool isHandled = false;

if (msg.message == NativeMethods.WM_KEYDOWN)

{

if (msg.wParam == (IntPtr)NativeMethods.VK_UP)

{

if (this.SelectedItemIndex > 0) { this.SelectedItemIndex--; }

else { this.SelectedItemIndex = 0; }

isHandled = true;

}

if (msg.wParam == (IntPtr)NativeMethods.VK_DOWN)

{

this.SelectedItemIndex++;

isHandled = true;

}

return isHandled;

}

The only thing that remains is supporting access keys (also known as mnemonics). In order to do that, you need to provide an implementation for the IKeyboardInputSink.OnMnemonic method.

Conclusion

The attached projects demonstrate the final solution for hosting a Win32 listbox in a WPF window. The final interface of the HwndHost-derived Win32 listbox container class is:

class Win32ListBoxHost : HwndHost, IKeyboardInputSink

{

public void AddItem(string item);

public void DeleteItem(int itemIndex);

public int SelectedItemIndex { get; set; }

public string SelectedItemText { get; }

public event EventHandler SelectionChanged;

protected override HandlerRef BuildWindowCore(HandleRef hwndParent);

protected override void DestroyWindowCore(HandleRef hwnd);

protected virtual void OnSelectionChanged(EventArgs args);

protected override IntPtr WndProc(IntPtr hwnd, int message,

IntPtr wParam, IntPtr lParam, ref bool handled);

bool IKeyboardInputSink.TabInto(TraversalRequest request);

bool IKeyboardInputSink.TranslateAccelerator(ref MSG msg, ModifierKeys modifiers);

}

For demonstration purposes only, I have included both a project that only uses “simple” (aka “raw”) window messages only and one that uses composite window messages. The only differences between the two projects are in the Win32ListBoxHost.cs file. In most real-world situations, you will end up using “composite” window messages – otherwise you would have to re-implement parts of the business logic of the component you are hosting, which is obviously undesirable.

[1] A handle to a window

[2] Hit-testing is the act of determining whether the position of the mouse coincides with the control representation on the screen

[3] “Adapter” in this context refers to the Adapter design pattern

[4] The notion of “simple” and “composite” messages is not something that is defined by the OS API or documentation. It is introduced in this text only as a way to illustrate the need for a parent HWND in order to be able to handle certain window messages. Instead, I could have used “OS generated” and “control generated” messages, etc.

[5] Strictly speaking, there is a parent WindowProc, but you don’t have direct access to it from within your HwndHost-derived class.

WPF-Win32 Interop Part 1: Hosting WinForms Controls (DataGridView) in WPF Windows

ivom — Fri, 27 Jul 2007 04:46:00 GMT

It's no secret that Win32 has been an extremely successful GUI platform over the past 15 or so years. The overwhelming majority of desktop components and applications for Windows in existence today are Win32-based. So although WPF is (compared to Win32) a vastly superior platform, we did not really expect everybody to turn around a rewrite all of their existing code and applications in WPF. We knew that we had to provide a bridge between Win32 and WPF to allow easy migration between the two platforms.

There are quite a few ways in which you can use Win32 content in your WPF applications and I will cover them in several posts. This series of posts is based on the material available on the WPF/Win32 interoperability portal on MSDN.

I'll start by covering the simplest scenario of using Win32 content in a WPF application: hosting of a WinForms control in a WPF window. Since WPF currently does not have a DataGrid control out of the box, the code below will demonstrate hosting of the WinForms DataGridView control in a WPF application. A VS2005 project with the full source code is attached here.

WinForms Control (DataGridView) in a WPF Window

In traditional Win32 programming user controls (buttons, listboxes, etc.) are created through a call to the CreateWindow or CreateWindowEx APIs. Every control has a unique (per session) identifier of type HWND (a handle to a Win32 window) and is recognized as a separate window (albeit a child window) by the window manager of the OS.

Windows Forms (aka WinForms) is a GUI framework, released as part of .NET 1.0, which provides a cleaner programming model around traditional Win32 that conforms to the paradigms of the .NET framework. Fundamentally, WinForms is a wrapper of Win32, so WinForms controls conform to the same WPF hosting restrictions as any other Win32 control.

Hosting of a WinForms user control in a WPF window is accomplished using the following steps:

1. In the XAML file declaring the UI of your WPF window, add a WindowsFormsHost element. As content of the WindowsFormsHost element, add the WindowsForms control you want to instantiate (DataGridView in this particular example):

<Window

x:Class="WinFormsControlInWpfWindow.MainWindow"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:wf="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms"

Title="WinForms Control (DataGridView) in a WPF Window"

Height="400" Width="750"

<Button Click="ButtonInsertSongOnClick">_Insert Song</Button>

<Button Click="ButtonDeleteSongOnClick">_Delete Song</Button>

<WindowsFormsHost>

<wf:DataGridView

x:Name="dataGridView"

Location="0, 0"

ColumnHeadersVisible="True"

SelectionMode="FullRowSelect"

MultiSelect="False"

SelectionChanged="DataGridViewOnSelectionChanged"

</WindowsFormsHost>

</StackPanel>

</Window>

2. Note how the XAML file above defines the name space for your WinForms control (the “wf” namespace) and the assembly where the WinForms class is implemented:

<Window

...

xmlns:wf="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms"

...

</Window>

The directive above points to System.Windows.Forms, as that’s where the standard WinForms controls are implemented.

Note also that the DataGridView control is instantiated through XAML (see http://msdn2.microsoft.com/en-us/library/ms742875.aspx for XAML instantiation of WinForms controls). This is possible, because XAML provides a generic means of instantiating any .NET class and because of an interop technology known as Property Mapping:

...

<wf:DataGridView

x:Name="dataGridView"

Location="0, 0"

ColumnHeadersVisible="True"

SelectionMode="FullRowSelect"

MultiSelect="False"

SelectionChanged="DataGridViewOnSelectionChanged"

</WindowsFormsHost>

...

</Window>

The mark-up above is equivalent to the following code (see http://msdn2.microsoft.com/en-us/library/ms751761.aspx for code instantiation of WinForms controls):

...

public partial class MainWindow : System.Windows.Window

{

public MainWindow()

{

InitializeComponent();

}

private void WindowLoaded(object sender, RoutedEventArgs args)

{

WindowsFormsHost host = new WindowsFormsHost();

DataGridView dataGridView = new DataGridView();

dataGridView.Location = new Point(0, 0);

dataGridView.ColumnsHeadersVisible = true;

dataGridView.SelectionMode = DataGridViewSelectionMode.FullRowSelect;

dataGridView.MultiSelect = false;

dataGridView.SelectionChanged += DataGridViewOnSelectionChanged;

host.child = dataGridView;

...

}

...

}

Communicating WinForms Events to the WPF Window

WinForms events are convenient .NET wrappers around the underlying Win32 events. Because WinForms events conform to the .NET event programming model, you can directly reuse them in your WPF application.

You attach event handlers to a WinForms control the same way you would attach event handlers to a WPF control, i.e. in XAML mark-up:

...

<wf:DataGridView

...

SelectionChanged="DataGridViewOnSelectionChanged"

</WindowsFormsHost>

...

</Window>

Or, in code:

public partial class MainWindow : System.Windows.Window

{

...

private void WindowLoaded(object sender, RoutedEventArgs args)

{

...

dataGridView.SelectionChanged += DataGridViewOnSelectionChanged;

...

}

...

}

Then, you provide the implementation of the event handler in code:

public partial class MainWindow : System.Windows.Window

{

...

private void DataGridViewOnSelectionChanged(object sender, EventArgs args)

{

// Implementation of the event handler goes here

}

...

}

Tab and Accelerators Support for the Hosted WinForms Control

The WindowsFormsHost takes care of adding tab and accelerator support behind the scenes, so the hosted WinForms control is fully accessible without the need for any additional code. This is not necessarily the case when hosting unmanaged Win32 controls -- a topic which I will cover in upcoming posts.