Full DD Support for Text Fields
Next: Null Parent Support
Previously, with Windows DEOs, the DDs and DEOs only partially supported a DD representation of text fields. Text field data was moved directly between the table buffer and the DEO, bypassing the DD buffer. Most of the time, this did not matter (which is why we did this). However, there are times when this proves to be a limitation.
With WebApp and batch processes, you could use DD text fields, but you had to explicitly specify in your DDO that you wanted to use extended DD fields.
Now, text DEOs (cDbTextEdit and cDbRichEdit) are full DEOs and can use the local DD buffers for text fields, just like the other DD fields. For backward compatibility purposes, this is optional.
In addition, you no longer need to specify that you want to define an extended field – it’s automatic. Previously, you needed to declare that you wanted an extended DD Text field with the messages:
This is no longer required. The first time you send a message that needs an extended field, it will be created for you. This means you no longer need to use these messages in WebApp WBOs and batch process BOs.
A new property, pbBypassDDFieldBuffer, has been added to all DEOs. This property allows you to determine if a DEO that uses extended fields should bypass updating the DD and perform updates directly against the file buffer. When set to True, the bypass is in effect, and the text field DEOs in Windows will behave as they always did.
For now, we are setting the default value of pbBypassDDFieldBuffer to True in the cDbTextEdit and cDbRichEdit classes. This means that, by default, the extended DD support is not enabled. This was done by weighing compatibility concerns against the fact that this extended support is rarely needed. If you need this enabled, set the pbBypassDDFieldBuffer property to False.
The legacy Edit class does not use this feature at all and works as it always did.
Compatibility Issues
Existing programs should work exactly as they did. Although the use of the DD messages DefineExtendedField and DefineAllExtendedFields are still supported, they should no longer be required. These were used primarily with WebApp.
See Also
- Data Dictionary Improvements 17.0