Recent changes to Dialog_Data_Transfer

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Mon, 27 Oct 2025 00:45:49 -0000

--- v102
+++ v103
@@ -24,17 +24,17 @@
 public:

   TSearchDialog(TWindow* parent, TSearchArguments& a)
-    : TDialog(parent, IDD_SEARCH_DIALOG), arguments(a) {}
+    : TDialog(parent, IDD_SEARCH_DIALOG), Arguments(a) {}

 protected:

-  TSearchArguments& arguments;
+  TSearchArguments& Arguments;

   virtual void SetupWindow()
   {
     TDialog::SetupWindow();
-    SetDlgItemText(IDC_SEARCH_STRING, arguments.SearchString.c_str());
-    CheckDlgButton(IDC_SEARCH_UP, arguments.Flags & TSearchArguments::SearchUp ?
+    SetDlgItemText(IDC_SEARCH_STRING, Arguments.SearchString.c_str());
+    CheckDlgButton(IDC_SEARCH_UP, Arguments.Flags & TSearchArguments::SearchUp ?
       BST_CHECKED : BST_UNCHECKED);
   }

@@ -42,8 +42,8 @@
   {
     char buf[256]; // NB! Arbitrary size!
     GetDlgItemText(IDC_SEARCH_STRING, buf, COUNTOF(buf));
-    arguments.SearchString = buf;
-    arguments.Flags = IsDlgButtonChecked(IDC_SEARCH_UP) == BST_CHECKED ?
+    Arguments.SearchString = buf;
+    Arguments.Flags = IsDlgButtonChecked(IDC_SEARCH_UP) == BST_CHECKED ?
       TSearchArguments::SearchUp : 0;
     TDialog::CmOk();
   }
@@ -71,26 +71,26 @@
 public:

   TSearchDialog(TWindow* parent, TSearchArguments& a)
-    : TDialog(parent, IDD_SEARCH_DIALOG), arguments(a) {}
+    : TDialog(parent, IDD_SEARCH_DIALOG), Arguments(a) {}

 protected:

-  TSearchArguments& arguments;
+  TSearchArguments& Arguments;

   virtual void TransferData(TTransferDirection d)
   {
     if (d == tdSetData)
     {
-      SetDlgItemText(IDC_SEARCH_STRING, arguments.SearchString.c_str());
-      CheckDlgButton(IDC_SEARCH_UP, arguments.Flags & TSearchArguments::SearchUp ?
+      SetDlgItemText(IDC_SEARCH_STRING, Arguments.SearchString.c_str());
+      CheckDlgButton(IDC_SEARCH_UP, Arguments.Flags & TSearchArguments::SearchUp ?
         BST_CHECKED : BST_UNCHECKED);
     }
     else if (d == tdGetData)
     {
       char buf[256]; // NB! Arbitrary size!
       GetDlgItemText(IDC_SEARCH_STRING, buf, COUNTOF(buf));
-      arguments.SearchString = buf;
-      arguments.Flags = IsDlgButtonChecked(IDC_SEARCH_UP) == BST_CHECKED ?
+      Arguments.SearchString = buf;
+      Arguments.Flags = IsDlgButtonChecked(IDC_SEARCH_UP) == BST_CHECKED ?
         TSearchArguments::SearchUp : 0;
     }
   } 
@@ -119,11 +119,11 @@
 void CSearchDialog::DoDataExchange(CDataExchange* pDX)
 {
   CDialog::DoDataExchange(pDX); // Must call base.
-  int up = (arguments.Flags & arguments.SearchUp) ? BST_CHECKED : BST_UNCHECKED; 
-  DDX_Text(pDX, IDC_SEARCH_STRING, arguments.SearchString);
+  int up = (Arguments.Flags & Arguments.SearchUp) ? BST_CHECKED : BST_UNCHECKED; 
+  DDX_Text(pDX, IDC_SEARCH_STRING, Arguments.SearchString);
   DDX_Check(pDX, IDC_SEARCH_UP, up);
   if (pDX->m_bSaveAndValidate)
-    arguments.Flags = (up == BST_CHECKED) ? arguments.SearchUp : 0;
+    Arguments.Flags = (up == BST_CHECKED) ? Arguments.SearchUp : 0;
 }
 ~~~

@@ -131,8 +131,8 @@

 ~~~C++
 CDialog::DoDataExchange(pDX); // Must call base.
-DDX_Text(pDX, IDC_SEARCH_STRING, arguments.SearchString);
-DDX_Check(pDX, IDC_SEARCH_UP, arguments.Flags, arguments.SearchUp);
+DDX_Text(pDX, IDC_SEARCH_STRING, Arguments.SearchString);
+DDX_Check(pDX, IDC_SEARCH_UP, Arguments.Flags, Arguments.SearchUp);
 ~~~

 This is short and sweet. The pDX parameter carries information about the direction of transfer and a reference to the parent window. That gives the DDX functions all the information needed to perform the transfer.
@@ -310,10 +310,10 @@
 ~~~C++
 struct TOptionProxy
 {
-  TSearchArguments& a;
-  TSearchArguments::TFlag flag;
-  bool Get() const {return a.GetOption(flag);}
-  void Set(bool s) {a.SetOption(flag, s);}
+  TSearchArguments& Args;
+  TSearchArguments::TFlag Flag;
+  bool Get() const {return Args.GetOption(Flag);}
+  void Set(bool s) {Args.SetOption(Flag, s);}
 };

 virtual void DoTransferData(const TTransferInfo& i, TSearchArguments& a)

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Fri, 29 Aug 2025 22:06:09 -0000

--- v101
+++ v102
@@ -1,6 +1,6 @@
 # Dialog Data Transfer

-Getting data in and out of dialog boxes is an essential task in GUI application programming. While OWL provided a nice set of control encapsulation classes, it failed to provide a good mechanism for transferring data into and out of the dialog. The mechanism provided by OWL — the *transfer buffer* feature — is fraught with dangers such as buffer overflow and type mismatches \[[1](#references)\]. Transfer buffers also do nothing to help transfer data from the buffer to application data structures. In short, a better solution is desirable for new code. Here we describe the Dialog Data Transfer framework, which was developed for this purpose.
+Getting data in and out of dialog boxes is an essential task in GUI application programming. While OWL provided a nice set of control encapsulation classes, it failed to provide a good mechanism for transferring data into and out of the dialog. The mechanism provided by OWL — the *transfer buffer* feature — is fraught with dangers such as buffer overflow and type mismatches \[[1](#h-references)\]. Transfer buffers also do nothing to help transfer data from the buffer to application data structures. In short, a better solution is desirable for new code. Here we describe the Dialog Data Transfer framework, which was developed for this purpose.

 [TOC]

@@ -113,7 +113,7 @@
 ---
 ## The DDX way

-The MFC DDX framework \[[2](#references)\] is very similar to the the code above. It too is based on overriding a single transfer function. But it has a wealth of free helper functions that assist in the transfer of data. These are given a DDX prefix by convention and come as a set of functions for each control type with further overloads for different data types; e.g. DDX_Text and DDX_Check for transferring text and boolean values. In MFC our example transfer function above may be translated as follows:
+The MFC DDX framework \[[2](#h-references)\] is very similar to the the code above. It too is based on overriding a single transfer function. But it has a wealth of free helper functions that assist in the transfer of data. These are given a DDX prefix by convention and come as a set of functions for each control type with further overloads for different data types; e.g. DDX_Text and DDX_Check for transferring text and boolean values. In MFC our example transfer function above may be translated as follows:

 ~~~C++
 void CSearchDialog::DoDataExchange(CDataExchange* pDX)
@@ -448,7 +448,7 @@
 }
 ~~~

-The function _bind_ (introduced in C++ TR1, and standardized in C++11 \[[3](#references)\]) creates function objects on the fly, and the TTransferFunction class can encapsulate any free function, member function, functor and lambda function. In C++11 you can also use a lambda expression to create the transfer function in-place:
+The function _bind_ (introduced in C++ TR1, and standardized in C++11 \[[3](#h-references)\]) creates function objects on the fly, and the TTransferFunction class can encapsulate any free function, member function, functor and lambda function. In C++11 you can also use a lambda expression to create the transfer function in-place:

 ~~~C++
 void TSearchApplication::CmSearch()

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Wed, 04 Jan 2023 07:22:28 -0000

--- v100
+++ v101
@@ -527,14 +527,14 @@

 
 
-examples/classes/dialogdatatransfer.cpp
+examples/classes/dialogdatatransfer.cpp
 
 
 This example demonstrates alternative mechanisms and programming styles for transferring data to and from controls, using a simple search dialog as a case study. This is a complete example based on the code snippets used in this article.
 

 
-examples/classes/transfer.cpp
+examples/classes/transfer.cpp
 
 
 This project is the test ground for the Dialog Data Transfer framework. It tests transfer for all the supported controls, using both control instances and child identifiers (integers). It also tests the DDX-like versions of the transfer functions.

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Sat, 26 Feb 2022 22:42:57 -0000

--- v99
+++ v100
@@ -11,8 +11,7 @@

 The data transfer between the application and the dialog must happen at window setup and at commit; usually the press of the OK button. The manual solution is to override the setup and commit events of the dialog and handle data transfer explicitly. In OWL the obvious way to do this is to override the SetupWindow virtual function and handle the CmOk event. The latter requires an entry in the response table for the dialog. For example:

-~~~~
-:::C++
+~~~C++
 struct TSearchArguments
 {
   tstring SearchString;
@@ -55,7 +54,7 @@
 DEFINE_RESPONSE_TABLE1(TSearchDialog, TDialog)
   EV_COMMAND(IDOK, CmOk),
 END_RESPONSE_TABLE;
-~~~~
+~~~

 While the number of lines of boiler-plate code here is hardly dramatic, there are a few alternative ways to do this that can save some lines of code; especially the need for a response table entry. One alternative is to override CloseWindow instead of handling the CmOk event. CloseWindow has a parameter that indicates how the dialog was closed. The argument passed through this parameter can be checked to see if we should commit the control data or not. If the dialog was closed with the OK button, the value is IDOK. (Actually, for dialogs, CloseWindow is only called by TDialog::CmOk, but you should test the argument anyway in case this changes in the future.)

@@ -66,8 +65,7 @@

 An alternative to overriding setup and commit separately is to override the TransferData function in the transfer buffer mechanism. Conveniently, TransferData is called at window setup and commit, and has a parameter TTransferDirection that tells us whether to set or get data. With the TransferData override solution the example dialog code above shrinks to:

-~~~~
-:::C++
+~~~C++
 class TSearchDialog : public TDialog
 {
 public:
@@ -98,7 +96,7 @@
   } 

 };
-~~~~
+~~~

 We can now handle the data transfer in a single function, and we no longer require a response table entry.

@@ -117,8 +115,7 @@

 The MFC DDX framework \[[2](#references)\] is very similar to the the code above. It too is based on overriding a single transfer function. But it has a wealth of free helper functions that assist in the transfer of data. These are given a DDX prefix by convention and come as a set of functions for each control type with further overloads for different data types; e.g. DDX_Text and DDX_Check for transferring text and boolean values. In MFC our example transfer function above may be translated as follows:

-~~~~
-:::C++
+~~~C++
 void CSearchDialog::DoDataExchange(CDataExchange* pDX)
 {
   CDialog::DoDataExchange(pDX); // Must call base.
@@ -128,16 +125,15 @@
   if (pDX->m_bSaveAndValidate)
     arguments.Flags = (up == BST_CHECKED) ? arguments.SearchUp : 0;
 }
-~~~~
+~~~

 We could further abstract the data transfer between the check-box and the search flags by introducing an overload for function DDX_Check. Then our DDX transfer function would contain just three lines:

-~~~~
-:::C++
+~~~C++
 CDialog::DoDataExchange(pDX); // Must call base.
 DDX_Text(pDX, IDC_SEARCH_STRING, arguments.SearchString);
 DDX_Check(pDX, IDC_SEARCH_UP, arguments.Flags, arguments.SearchUp);
-~~~~
+~~~

 This is short and sweet. The pDX parameter carries information about the direction of transfer and a reference to the parent window. That gives the DDX functions all the information needed to perform the transfer.

@@ -157,8 +153,7 @@

 Here is a DDT version of our example dialog code above:

-~~~~
-:::C++
+~~~C++
 class TSearchDialog
   : public TTransferDialog<tsearcharguments>
 {
@@ -176,7 +171,7 @@
   }

 };
-~~~~
+~~~

 Note that we inherit our dialog class from TTransferDialog and pass the type of the data source we want to use as a template argument. Passing the type of the data source allows the base class to declare the DoTransferData function with the correct parameter type for our data source. TTransferDialog inherits from TDialog (by default) and the window mix-in class template TTransferWindow. It is the latter class template that provides the framework of the transfer mechanism, so data transfer can be implemented for window classes in general, not just TDialog derivatives.

@@ -187,14 +182,13 @@

 DDT passes information to the transfer functions containing details about the transfer, such as the parent window handle and the direction of transfer. This information is passed as a reference to a TTransferInfo object, which is currently defined as follows:

-~~~~
-:::C++
+~~~C++
 struct TTransferInfo
 {
   HWND Window;
   TTransferDirection Operation;
 };
-~~~~
+~~~

 The Window member is the handle to the parent window (dialog), and the Operation member tells the transfer functions what to do. Note that TTransferDirection has one of three possible values; tdGetData, tdSetData and tdSizeData. It may get more states in the future (e.g. tdValidate), so you should never assume that TTransferDirection has a fixed set of possible values.

@@ -212,8 +206,7 @@

 If you prefer, you can handle the transfer in each direction separately by overriding DoGetData and DoSetData. Although this could of course be done manually with a few lines of user code, the TTransferWindow base has already arranged the split. It is up to you which functions you want to override. A notable benefit is that DoGetData and DoSetData are const-correct. Here is the example above with DoGetData and DoSetData overrides:

-~~~~
-:::C++
+~~~C++
 class TSearchDialog
   : public TTransferDialog<tsearcharguments>
 {
@@ -237,7 +230,7 @@
   }

 };
-~~~~
+~~~

 Overriding the DoGetData and DoSetData functions is most useful in situations where one or both need very distinct handling. Normally that should be rare. Most often you will find that the distinct code belongs in other functions that override the setup or the shut-down of the dialog.

@@ -264,11 +257,10 @@

 Every transfer function has overloads that allow you to identify the control by child ID, window handle or control encapsulation class reference, as well as overloads for getters and setters. The basic signature of a transfer function can be described by the following function template:

-~~~~
-:::C++
+~~~C++
 template <class tchildid,="" class="" tdatasource="">
 void TransferControlData(const TTransferInfo&, TChildId, TDataSource&);
-~~~~
+~~~

 The first argument is always the TTransferInfo. It tells the function which way to transfer data and the parent window involved. The second parameter identifies the child, and as noted above, this may be an integer child ID, a HWND handle or a reference to a control encapsulation class; e.g. TEdit&. The third argument is a reference to the data source; e.g. tstring& for a text source. The functions may have further parameters as needed, but the first three should always adhere to this template.

@@ -279,47 +271,43 @@

 For example, to display floating point coordinates with two decimals:

-~~~~
-:::C++
+~~~C++
 virtual void DoTransferData(const TTransferInfo& i, TPointF& p) // override
 {
   TTransferFormat fmt = {ios::fixed, 2}; // Show two decimals.
   TransferEditData(i, IDC_X, p.x, fmt);
   TransferEditData(i, IDC_Y, p.y, fmt);
 }
-~~~~
+~~~

 

 ### Using getters and setters

 Often the data source that we want to use is an encapsulated object with getter and setter functions. In this case the ordinary Transfer functions are less convenient, because we have to use an intermediate variable to pass as an argument. Also, we have to test the TTransferInfo argument to see if we are setting or getting. While we can use the separate DoGetData and DoSetData to avoid this latter inconvenience, life would be much easier if we could just tell the Transfer function the getter and setter to use. DDT provides overloads to do just that.

-~~~~
-:::C++
+~~~C++
 template <class tchildid,="" class="" t,="" r,="" a="">
 void TransferControlData(const TTransferInfo&, TChildId, T*, 
   R (T::*get)(), 
   void (T::*set)(A));
-~~~~
+~~~

 Instead of the data source reference in the basic signature, this signature takes pointers to an object and two member functions; a getter and a setter. The Transfer implementation deduces the type of data to be transferred based on the return type of the getter. It then creates an intermediary transfer variable and calls the basic Transfer overloads.

 Usage of this indirect overload is very simple when the data source supports the getter and setter needed, i.e. the data source has members with compatible signatures and a data type compatible with the control. For example:

-~~~~
-:::C++
+~~~C++
 virtual void DoTransferData(const TTransferInfo& i, TSearchArguments& a)
 {
   typedef TSearchArguments D;
   TransferEditData(i, IDC_SEARCH_STRING, &a, &D::GetSearchString, &D::SetSearchString);
   TransferCheckBoxData(i, IDC_SEARCH_UP, &a, &D::IsSearchUp, &D::SetSearchUp);
 }
-~~~~
+~~~

 Unfortunately, life is not always this easy. In practice you may have to convert the data from the control to some application-specific value. Or, the getter and setter may require extra parameters. In this case, there are no suitable data source member functions to use as a direct getter and setter for the control value. It may be tempting to add such member functions to the data source, but that creates undesirable coupling between the UI and the application logic. A better solution is to define and use proxy classes that translate between control and application values. For example:

-~~~~
-:::C++
+~~~C++
 struct TOptionProxy
 {
   TSearchArguments& a;
@@ -336,27 +324,25 @@
   TOptionProxy searchUp = {a, a.SearchUp};
   TransferCheckBoxData(i, IDC_SEARCH_UP, &searchUp, &TOptionProxy::Get, &TOptionProxy::Set);
 }
-~~~~
+~~~

 DDT also offers transfer function overloads that take getter and setter functors that are fully generic. You can pass functors instantiated from manual functor classes, composed using std::bind (C++11), or written inline using lambdas (C++11). This makes it possible to write the data transfer code in a compact functional style which avoids having to define proxy classes. When there is little potential reuse of a proxy class you may prefer this alternative. For example:

-~~~~
-:::C++
+~~~C++
 TransferCheckBoxData(i, IDC_SEARCH_UP,
   bind(&D::GetOption, &a, a.SearchUp),
   bind(&D::SetOption, &a, a.SearchUp, _1)
 );
-~~~~
+~~~

 With lambdas the same call would look like this:

-~~~~
-:::C++
+~~~C++
 TransferCheckBoxData(i, IDC_SEARCH_UP,
   [&] {return a.GetOption(a.SearchUp);},
   [&] (bool s) {a.SetOption(a.SearchUp, s);}
 );
-~~~~
+~~~

 

 ### Alternative DDX names
@@ -368,18 +354,16 @@

 DDX provides a function called DDX_Control that, despite appearances, isn't a transfer function at all. Its purpose is not to transfer data but to sub-class a control. This is not needed in OWLNext, since a TWindow instance can easily be created to sub-class a child by passing the child handle to the TWindow constructor. An instance created like this is called an _alias_ in OWLNext. For example:

-~~~~
-:::C++
+~~~C++
 TWindow alias(GetDlgItem(IDC_SEARCH_STRING));
 alias.SetCaption("Test");
-~~~~
+~~~

 An alias can be useful whenever you have a window handle and need to use functionality within TWindow, or functions and classes that require a TWindow argument, and you have no TWindow instance readily available. In earlier versions, only TWindow could be used for aliasing, but since version 6.32 OWLNext now supports aliasing for most native controls as well. For example:

-~~~~
-:::C++
+~~~C++
 TCheckBox(GetDlgItem(IDC_SEARCH_UP)).Toggle();
-~~~~
+~~~

 

 ### Little helpers
@@ -402,15 +386,14 @@

 Several useful overloads are provided, such as overloads for window handle, control class instance, and integer child ID. In addition, many of these functions have overloads for sequences and arrays of child IDs. This is especially useful for enabling and disabling controls in response to dialog state changes. For example:

-~~~~
-:::C++
+~~~C++
 void BnCreditcardClicked()
 {
   bool s = IsChecked(IDC_CREDITCARD);
   const int c[] = {IDC_VISA, IDC_MASTERCARD, IDC_AMERICAN_EXPRESS};
   EnableDlgItem(c, s);
 }
-~~~~
+~~~

 

 ### The flexibility of parameterization
@@ -419,8 +402,7 @@

 The GetData and SetData functions make it easy to implement advanced features such as support for presets. The dialog can let the user choose among a list of presets and let the user save new ones. All you have to do is keep a collection of presets (data source instances) and add a handler to create new presets and retrieve saved ones. For example, the following code adds support for presets to our search dialog above:

-~~~~
-:::C++
+~~~C++
 void EvContextMenu(HWND, int x, int y)
 {
   static std::vector<tsearcharguments> presets;
@@ -436,7 +418,7 @@
   else if (s > 0)
     SetData(presets[s - 1]); // Use preset.
 }
-~~~~
+~~~

 You will have to add an entry in the response table for EV_WM_CONTEXTMENU as well, but that's all. You can now save the settings of the dialog by right-clicking within the window and selecting "Add preset" from the pop-up menu. The next time you right-click the mouse, you will see the preset on the menu. If you select a preset on the menu the dialog will be restored to the settings stored in that preset.

@@ -449,8 +431,7 @@

 A little add-on to the the basic DDT framework is a generic dialog class that delegates the data transfer work to a specified function. The specified function may be a free function, member function, a functor (function object) or lambda function (C++11). Often, for simple dialogs, the transfer work is the only customization needed for the dialog. In these cases TDelegatedTransferDialog can be used as a generic solution and save you from having to derive a dialog class. Instead, you can just write the transfer function and then create a TDelegatedTransferDialog, passing the transfer function to the constructor. Here is an example based on the code above:

-~~~~
-:::C++
+~~~C++
 void TransferSearchArguments(const TTransferInfo& i, TSearchArguments& a)
 {
   TransferEditData(i, IDC_SEARCH_STRING, a.SearchString);
@@ -465,12 +446,11 @@
   if (dlg.Execute() == IDOK)
     Search(a);
 }
-~~~~
+~~~

 The function _bind_ (introduced in C++ TR1, and standardized in C++11 \[[3](#references)\]) creates function objects on the fly, and the TTransferFunction class can encapsulate any free function, member function, functor and lambda function. In C++11 you can also use a lambda expression to create the transfer function in-place:

-~~~~
-:::C++
+~~~C++
 void TSearchApplication::CmSearch()
 {
   static TSearchArguments a = {"", 0};
@@ -483,7 +463,7 @@
   if (dlg.Execute() == IDOK)
     Search(a);
 }
-~~~~
+~~~

 You can hardly boil it down more than that!

</tsearcharguments></class></class></tsearcharguments></tsearcharguments>

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Fri, 15 May 2020 01:39:05 -0000

--- v98
+++ v99
@@ -547,14 +547,14 @@

 
 
-examples/classes/dialogdatatransfer
+examples/classes/dialogdatatransfer.cpp
 
 
 This example demonstrates alternative mechanisms and programming styles for transferring data to and from controls, using a simple search dialog as a case study. This is a complete example based on the code snippets used in this article.
 

 
-examples/classes/transfer
+examples/classes/transfer.cpp
 
 
 This project is the test ground for the Dialog Data Transfer framework. It tests transfer for all the supported controls, using both control instances and child identifiers (integers). It also tests the DDX-like versions of the transfer functions.

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Sun, 01 Apr 2018 01:28:36 -0000

--- v97
+++ v98
@@ -57,7 +57,7 @@
 END_RESPONSE_TABLE;
 ~~~~

-While the number of lines of boiler-plate code here is hardly dramatic, there are a few alternative ways to do this that can save some lines of code; especially the need for a response table entry. One alternative is to override CloseWindow instead of handling the CmOk event. CloseWindow has a parameter that indicates how the dialog was closed. The argument passed through this parameter can be checked to see if we should commit the control data or not. If the dialog was closed with the OK button, the value is IDOK. (Actually, CloseWindow is only called by TDialog::CmOk in a dialog, but you should test the argument anyway in case this changes in the future.)
+While the number of lines of boiler-plate code here is hardly dramatic, there are a few alternative ways to do this that can save some lines of code; especially the need for a response table entry. One alternative is to override CloseWindow instead of handling the CmOk event. CloseWindow has a parameter that indicates how the dialog was closed. The argument passed through this parameter can be checked to see if we should commit the control data or not. If the dialog was closed with the OK button, the value is IDOK. (Actually, for dialogs, CloseWindow is only called by TDialog::CmOk, but you should test the argument anyway in case this changes in the future.)

 There is another, possibly overlooked, alternative which is even simpler, and that is to hi-jack the transfer buffer mechanism.

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Fri, 16 Mar 2018 09:55:08 -0000

--- v96
+++ v97
@@ -3,6 +3,8 @@
 Getting data in and out of dialog boxes is an essential task in GUI application programming. While OWL provided a nice set of control encapsulation classes, it failed to provide a good mechanism for transferring data into and out of the dialog. The mechanism provided by OWL — the *transfer buffer* feature — is fraught with dangers such as buffer overflow and type mismatches \[[1](#references)\]. Transfer buffers also do nothing to help transfer data from the buffer to application data structures. In short, a better solution is desirable for new code. Here we describe the Dialog Data Transfer framework, which was developed for this purpose.

 [TOC]
+
+


 ---
 ## Background
@@ -108,6 +110,7 @@
 Until recently there was a serious issue with TransferData. In the original OWL code TransferData(tdSetData) was called at the end of TWindow::SetupWindow in the window initialization sequence. The usual idiom for derived window classes is to override SetupWindow and do any extra setup work after calling the base class version of SetupWindow. Unfortunately the defect in the calling sequence meant that the data transfer had already performed before the setup code in the derived class had a chance to run. This defect was fixed in OWLNext 6.31. Now SetupWindow will have fully completed before TransferData is called. The dialog data transfer mechanism described here relies on this fix, as it is based on overriding TransferData.

 Note that this fix is not applied when OWLNext is built with the OWL5_COMPAT compatibility option. This means that you ideally should upgrade your application code to not use the OWL5_COMPAT option before starting to use DDT. If you do decide to use OWL5_COMPAT mode and DDT together, you need to be keenly aware of the calling sequence issue.
+


 ---
 ## The DDX way
@@ -142,6 +145,7 @@
 ### Drawbacks in DDX

 What is lacking in the DDX mechanism is a reference to the data source. DDX leaves the data source up to the dialog class and the implementation of the transfer function. The convention is to use class members to buffer the data between the application and the dialog. This is automatically enforced by the ClassWizard in the Visual Studio IDE, and is assumed in the documentation, so it has become a deep-rooted idiom. But as with the OWL transfer buffers, this is not ideal, since it requires an extra transfer step to get data from the buffered values to and from the application data structures. In the code above we did not use the normal DDX idiom. Instead we kept a reference to our data source as a protected member and transferred the data through it. Later we will see that we can gain additional benefits by having a reference to the data source passed to us in the transfer function.
+


 ---
 ## Stealing the idea and building on it
@@ -484,6 +488,7 @@
 You can hardly boil it down more than that!

 While the utility of the TDelegatedTransferDialog is limited, it can be a time saver for simple dialogs; e.g. plain form filling.
+


 ---
 ## Data validation
@@ -491,6 +496,7 @@
 DDT currently relies on the established validation mechanism in OWL, which is based on the dialog overriding TWindow::CanClose and returning 'true' only if the dialog data is valid.

 This mechanism is activated for dialogs derived from TDialog and tabbed property sheets. For property sheets in wizard mode, you have to handle data validation yourself (see below).
+


 ---
 ## Exception handling
@@ -498,6 +504,7 @@
 If an exception is thrown by DoTransferData, DoGetData, DoSetData or CanClose, the dialog will be forcefully closed and the exception will be rethrown. Unless you want this behaviour, you have to carefully handle all exceptions within your code.

 This mechanism is activated for dialogs derived from TDialog and tabbed property sheets. For property sheets in wizard mode, you have to handle exceptions yourself (see below).
+


 ---
 ## Property sheets and wizards
@@ -525,11 +532,13 @@
 ### Sheet and wizard state

 Most sheets and wizards should not commit data until the whole sheet or wizard is committed by the user pressing OK or Finish. This means that you should think carefully about the data source you use for the pages, when to call TransferData (tdGetData), and when to commit data to the application. The most appropriate solution might be to use a specially designed class to hold the complete sheet or wizard state. This class can then serve as a data source for DDT, storing dialog settings (persistence), presets handling, etc.
+


 ---
 ## Conclusion

 The original OWL transfer buffer mechanism for dialog data transfer has many problems. OWLNext has since added checks and extensions to make transfer buffers safe. But transfer buffers still have problems rooted in a poor design. New code should use more flexible alternatives such as the Dialog Data Transfer framework discussed here. Existing code that so far has preferred the manual approach may also benefit from a transition to DDT.
+


 ---
 ## Example code
@@ -553,6 +562,7 @@
 

 Ready-made projects for C++Builder and Visual Studio are provided for both examples.
+


 ---
 ## References
@@ -560,3 +570,5 @@
   1. ["Safe Transfer Buffers"](Safe_Transfer_Buffers), OWLNext Wiki.
   2. ["Dialog Data Exchange in MFC"](http://www.codeproject.com/KB/cpp/DialogDataExchange.aspx), Hitesh Sharma, The Code Project.
   3. ["C++11"](http://en.wikipedia.org/wiki/C%2B%2B0x), Wikipedia.
+
+

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Mon, 26 Feb 2018 14:31:28 -0000

--- v95
+++ v96
@@ -55,7 +55,7 @@
 END_RESPONSE_TABLE;
 ~~~~

-
While the number of lines of boiler-plate code here is hardly dramatic, there are a few alternative ways to do this that can save some lines of code; especially the need for a response table entry. One alternative is to override CloseWindow instead of handling the CmOk event. CloseWindow has a parameter that indicates how the dialog was closed. The argument passed through this parameter can be checked to see if we should commit the control data or not. If the dialog was closed with the OK button, the value is IDOK. (Actually, CloseWindow is only called by TDialog::CmOk in a dialog, but you should test the argument anyway in case this changes in the future.)
+While the number of lines of boiler-plate code here is hardly dramatic, there are a few alternative ways to do this that can save some lines of code; especially the need for a response table entry. One alternative is to override CloseWindow instead of handling the CmOk event. CloseWindow has a parameter that indicates how the dialog was closed. The argument passed through this parameter can be checked to see if we should commit the control data or not. If the dialog was closed with the OK button, the value is IDOK. (Actually, CloseWindow is only called by TDialog::CmOk in a dialog, but you should test the argument anyway in case this changes in the future.)

 There is another, possibly overlooked, alternative which is even simpler, and that is to hi-jack the transfer buffer mechanism.

@@ -98,7 +98,7 @@
 };
 ~~~~

-
We can now handle the data transfer in a single function, and we no longer require a response table entry.
+We can now handle the data transfer in a single function, and we no longer require a response table entry.

 But the main chore is the implementation of data transfer between the controls and the application data structures. Unfortunately, OWL did little to help in this area. Strings had to be handled as character arrays, and there were few helpers for converting text to other data types; edit fields to strings, check-boxes to boolean values, etc. Here the rival MFC does much better with its dialog data exchange mechanism (DDX), with a plethora of function overloads to convert between text and other types.

@@ -127,7 +127,7 @@
 }
 ~~~~

-
We could further abstract the data transfer between the check-box and the search flags by introducing an overload for function DDX_Check. Then our DDX transfer function would contain just three lines:
+We could further abstract the data transfer between the check-box and the search flags by introducing an overload for function DDX_Check. Then our DDX transfer function would contain just three lines:

 ~~~~
 :::C++
@@ -136,7 +136,7 @@
 DDX_Check(pDX, IDC_SEARCH_UP, arguments.Flags, arguments.SearchUp);
 ~~~~

-
This is short and sweet. The pDX parameter carries information about the direction of transfer and a reference to the parent window. That gives the DDX functions all the information needed to perform the transfer.
+This is short and sweet. The pDX parameter carries information about the direction of transfer and a reference to the parent window. That gives the DDX functions all the information needed to perform the transfer.

 

 ### Drawbacks in DDX
@@ -174,7 +174,7 @@
 };
 ~~~~

-
Note that we inherit our dialog class from TTransferDialog and pass the type of the data source we want to use as a template argument. Passing the type of the data source allows the base class to declare the DoTransferData function with the correct parameter type for our data source. TTransferDialog inherits from TDialog (by default) and the window mix-in class template TTransferWindow. It is the latter class template that provides the framework of the transfer mechanism, so data transfer can be implemented for window classes in general, not just TDialog derivatives.
+Note that we inherit our dialog class from TTransferDialog and pass the type of the data source we want to use as a template argument. Passing the type of the data source allows the base class to declare the DoTransferData function with the correct parameter type for our data source. TTransferDialog inherits from TDialog (by default) and the window mix-in class template TTransferWindow. It is the latter class template that provides the framework of the transfer mechanism, so data transfer can be implemented for window classes in general, not just TDialog derivatives.

 The implementation of the DoTransferData function here uses two helper functions. TransferEditData is provided by DDT. TransferFlag is provided by the application. The latter transfers the checked state of a checkbox to a corresponding bit in a flags variable.

@@ -192,7 +192,7 @@
 };
 ~~~~

-
The Window member is the handle to the parent window (dialog), and the Operation member tells the transfer functions what to do. Note that TTransferDirection has one of three possible values; tdGetData, tdSetData and tdSizeData. It may get more states in the future (e.g. tdValidate), so you should never assume that TTransferDirection has a fixed set of possible values.
+The Window member is the handle to the parent window (dialog), and the Operation member tells the transfer functions what to do. Note that TTransferDirection has one of three possible values; tdGetData, tdSetData and tdSizeData. It may get more states in the future (e.g. tdValidate), so you should never assume that TTransferDirection has a fixed set of possible values.

 Also, DDT may extend the contents and purpose of TTransferInfo in the future, so nothing should be assumed about its size.

@@ -235,7 +235,7 @@
 };
 ~~~~

-
Overriding the DoGetData and DoSetData functions is most useful in situations where one or both need very distinct handling. Normally that should be rare. Most often you will find that the distinct code belongs in other functions that override the setup or the shut-down of the dialog.
+Overriding the DoGetData and DoSetData functions is most useful in situations where one or both need very distinct handling. Normally that should be rare. Most often you will find that the distinct code belongs in other functions that override the setup or the shut-down of the dialog.

 

 ### Control data transfer functions
@@ -266,7 +266,7 @@
 void TransferControlData(const TTransferInfo&, TChildId, TDataSource&);
 ~~~~

-
The first argument is always the TTransferInfo. It tells the function which way to transfer data and the parent window involved. The second parameter identifies the child, and as noted above, this may be an integer child ID, a HWND handle or a reference to a control encapsulation class; e.g. TEdit&. The third argument is a reference to the data source; e.g. tstring& for a text source. The functions may have further parameters as needed, but the first three should always adhere to this template.
+The first argument is always the TTransferInfo. It tells the function which way to transfer data and the parent window involved. The second parameter identifies the child, and as noted above, this may be an integer child ID, a HWND handle or a reference to a control encapsulation class; e.g. TEdit&. The third argument is a reference to the data source; e.g. tstring& for a text source. The functions may have further parameters as needed, but the first three should always adhere to this template.

 

 ### Formatted data transfer
@@ -298,7 +298,7 @@
   void (T::*set)(A));
 ~~~~

-
Instead of the data source reference in the basic signature, this signature takes pointers to an object and two member functions; a getter and a setter. The Transfer implementation deduces the type of data to be transferred based on the return type of the getter. It then creates an intermediary transfer variable and calls the basic Transfer overloads.
+Instead of the data source reference in the basic signature, this signature takes pointers to an object and two member functions; a getter and a setter. The Transfer implementation deduces the type of data to be transferred based on the return type of the getter. It then creates an intermediary transfer variable and calls the basic Transfer overloads.

 Usage of this indirect overload is very simple when the data source supports the getter and setter needed, i.e. the data source has members with compatible signatures and a data type compatible with the control. For example:

@@ -312,7 +312,7 @@
 }
 ~~~~

-
Unfortunately, life is not always this easy. In practice you may have to convert the data from the control to some application-specific value. Or, the getter and setter may require extra parameters. In this case, there are no suitable data source member functions to use as a direct getter and setter for the control value. It may be tempting to add such member functions to the data source, but that creates undesirable coupling between the UI and the application logic. A better solution is to define and use proxy classes that translate between control and application values. For example:
+Unfortunately, life is not always this easy. In practice you may have to convert the data from the control to some application-specific value. Or, the getter and setter may require extra parameters. In this case, there are no suitable data source member functions to use as a direct getter and setter for the control value. It may be tempting to add such member functions to the data source, but that creates undesirable coupling between the UI and the application logic. A better solution is to define and use proxy classes that translate between control and application values. For example:

 ~~~~
 :::C++
@@ -334,7 +334,7 @@
 }
 ~~~~

-
DDT also offers transfer function overloads that take getter and setter functors that are fully generic. You can pass functors instantiated from manual functor classes, composed using std::bind (C++11), or written inline using lambdas (C++11). This makes it possible to write the data transfer code in a compact functional style which avoids having to define proxy classes. When there is little potential reuse of a proxy class you may prefer this alternative. For example:
+DDT also offers transfer function overloads that take getter and setter functors that are fully generic. You can pass functors instantiated from manual functor classes, composed using std::bind (C++11), or written inline using lambdas (C++11). This makes it possible to write the data transfer code in a compact functional style which avoids having to define proxy classes. When there is little potential reuse of a proxy class you may prefer this alternative. For example:

 ~~~~
 :::C++
@@ -344,7 +344,7 @@
 );
 ~~~~

-
With lambdas the same call would look like this:
+With lambdas the same call would look like this:

 ~~~~
 :::C++
@@ -370,7 +370,7 @@
 alias.SetCaption("Test");
 ~~~~

-
An alias can be useful whenever you have a window handle and need to use functionality within TWindow, or functions and classes that require a TWindow argument, and you have no TWindow instance readily available. In earlier versions, only TWindow could be used for aliasing, but since version 6.32 OWLNext now supports aliasing for most native controls as well. For example:
+An alias can be useful whenever you have a window handle and need to use functionality within TWindow, or functions and classes that require a TWindow argument, and you have no TWindow instance readily available. In earlier versions, only TWindow could be used for aliasing, but since version 6.32 OWLNext now supports aliasing for most native controls as well. For example:

 ~~~~
 :::C++
@@ -434,7 +434,7 @@
 }
 ~~~~

-
You will have to add an entry in the response table for EV_WM_CONTEXTMENU as well, but that's all. You can now save the settings of the dialog by right-clicking within the window and selecting "Add preset" from the pop-up menu. The next time you right-click the mouse, you will see the preset on the menu. If you select a preset on the menu the dialog will be restored to the settings stored in that preset.
+You will have to add an entry in the response table for EV_WM_CONTEXTMENU as well, but that's all. You can now save the settings of the dialog by right-clicking within the window and selecting "Add preset" from the pop-up menu. The next time you right-click the mouse, you will see the preset on the menu. If you select a preset on the menu the dialog will be restored to the settings stored in that preset.

 Note that the code above uses GetData without an argument to retrieve the settings. This is simply a functional style overload of GetData that creates and returns an instance of the data source, initialized with the settings of the dialog. It requires that the data source is a value type; i.e. is default and copy constructible. If your data source is not a value type, then the functional style GetData is not available, and trying to use it will cause a compilation error.

@@ -463,7 +463,7 @@
 }
 ~~~~

-
The function _bind_ (introduced in C++ TR1, and standardized in C++11 \[[3](#references)\]) creates function objects on the fly, and the TTransferFunction class can encapsulate any free function, member function, functor and lambda function. In C++11 you can also use a lambda expression to create the transfer function in-place:
+The function _bind_ (introduced in C++ TR1, and standardized in C++11 \[[3](#references)\]) creates function objects on the fly, and the TTransferFunction class can encapsulate any free function, member function, functor and lambda function. In C++11 you can also use a lambda expression to create the transfer function in-place:

 ~~~~
 :::C++
@@ -481,7 +481,7 @@
 }
 ~~~~

-
You can hardly boil it down more than that!
+You can hardly boil it down more than that!

 While the utility of the TDelegatedTransferDialog is limited, it can be a time saver for simple dialogs; e.g. plain form filling.

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Thu, 26 Jan 2017 18:17:36 -0000

Dialog_Data_Transfer modified by Vidar Hasfjord

Vidar Hasfjord — Thu, 26 Jan 2017 18:17:29 -0000

--- v93
+++ v94
@@ -161,7 +161,7 @@
 public:

   TSearchDialog(TWindow* parent, TSearchArguments& a)
-    : TTransferDialog(parent, IDD_SEARCH_DIALOG, a) {}
+    : TTransferDialog<TSearchArguments>(parent, IDD_SEARCH_DIALOG, a) {}

 protected:

@@ -216,7 +216,7 @@
 public:

   TSearchDialog(TWindow* parent, TSearchArguments& a)
-    : TTransferDialog(parent, IDD_SEARCH_DIALOG, a) {}
+    : TTransferDialog<TSearchArguments>(parent, IDD_SEARCH_DIALOG, a) {}

 protected: