Skip to content

What's New in DataFlex 18.2

DataFlex 18.2 (Released July 2016)

Introducing DataFlex 18.2

DataFlex 18.2 is a maintenance release that builds on the foundation of DataFlex 18.1. It focuses on developer suggestions and bug fixes. The enhancements and fixes range from the base system, up through data dictionaries and the framework, and the developer tools themselves (especially the Studio).

This release contains over 230 implemented suggestions and bug fixes.

If this is your first look at DataFlex 18.2, be sure to read Working with a New Release.

If you are not already using the prior release and are updating from revisions older than DataFlex 18.1, please be aware that this section of the help only contains details on changes between DataFlex 18.1 and 18.2. There are detailed sections for each past revision in the Table of Contents (to the left), and we recommend reviewing every revision that you are unfamiliar with (especially the most recent: DataFlex 18.1, DataFlex 18.0, and DataFlex 17.1).

The changes in DataFlex 18.2 are widely spread across the system, including the Studio, Web and Windows Frameworks, base system (runtime, packages, etc.), and documentation, including the highlights listed below.

You can read the complete details on the suggestions that have been implemented and bugs that have been fixed in their respective lists.

Windows Framework

  • A new Windows class, dbParentCombo, provides the same capability as the new web class, cWebParentCombo. Both of these classes now support a more flexible method for displaying custom combo-list content.
  • A new Month Calendar control for prompts and other custom uses (see the Order view in the Order Entry example). If seeded dates are empty, we pick good defaults for them, and if a seeded date range exceeds the control’s max range (piMaxSelectedCount), a handled error is raised. SelectedDate and SelectedDateRange can be called after the control is closed.
  • We've changed the default of pbSuppressCacheError in cDbCJGrid from False to True. While we generally avoid changing default properties, we felt that in the long run this is warranted for the following reasons:
  • Suppressing re-read errors in grids is really the best default for end users using a deployed application. Real-world, multi-user conditions arise where a row cannot be re-read, and providing an error message (even a handled one) to an end-user serves little purpose.
  • The automatic grid refresh recovery process introduced in 18.1 has worked really well. When a row cannot be re-read, the grid’s refresh process works great. Having this preceded by an error message somewhat defeats the automatic recovery.
  • Our web and windows grid classes were not consistent. In Web, we suppress the error, and we've had no complaints or comments. In Windows, we don’t suppress the error, and we get complaints and comments. We should change one or the other.
  • This property was introduced in 18.1 – we don’t have much compatibility history, so now is the time to make the change.

The only downside of suppressing cache errors is that it may suppress programming errors. For testing purposes, developers can set this property to False and then remove it upon deployment. They can also place a breakpoint in HandleCacheError or SetGridCacheError and wait for the code to get executed. If you work with dynamic constraints, this is probably something you want to do when testing your application.

Since most developers create class layers, you can set pbSuppressCacheError in your subclass to whatever you want. Our advice will be to leave it True (suppress the handled error) because that is what is best for a deployed application. If you have already set this to True, as many have, nothing changes, although you may now remove that Set.

  • Windows applications now do a better job of sizing and locating the main panel when moving from a multi-screen to single-screen environment.
  • Windows 10 font spacing (kerning) issues are resolved.
  • The latest CodeJock controls (16.4.0) are used and supported.

Web Framework

  • Complex views display much faster on clients.
  • New parent combo control. When using the parent combo control, the Entry_Item command determines the parent table and column that will be used, and the combo automatically fills itself by searching the parent table.
  • Web-based Data Dictionary Inspector (Web_DDDebug) - Be sure to check out these user interface improvements (contributed by Raveen Sundram); cleaned up the UI, added a Treeview to display the DDOs in a structure, and added a Grid to show the Field information.
  • Improved cookie management.
  • Better error handling.
  • Many JavaScript engine improvements:
  • Better cross-platform compatibility and performance.
  • Many layout and alignment improvements.
  • New Desktop Theme:
  • The DF_Flat_Desktop theme has the same modern look of the mobile/touch (DF_Flat_Touch) theme but with smaller control sizing and condensed spacing that is more appropriate for desktop monitors and precision pointing devices.

Studio

  • Better Table Explorer Table Filter options:
  • Table list (filelist) filtering is now applied more widely throughout the Studio, e.g., the DDO Table Selector.
  • Generates .DEF files whenever .FD files are generated (configurable). You can also explicitly generate .DEF files.
  • Configurable pre & post compile processing.
  • Optimized Web Designer (much faster).
  • Better support for JavaScript subclassing in the Designer.

Data Dictionaries

New Smart Relates

The new pbSmartRelate property controls whether Data Dictionaries perform relates on parent tables that are not connected to the DDO (Data Dictionary Object) structure. Normally, a DDO structure should be complete and contain all parents. When saving data, this is a requirement. For batch and reporting processing, developers often remove parent DDOs if they are not needed for the process. If pbSmartRelate is set to True, these non-connected parent records will not be found as part of the relate. This can result in noticeable performance improvements when finding many records (e.g., batch processes or grids that load many records). This will be even more noticeable when using SQL back-ends.

When False, DDOs perform relates on all open parent tables up the ancestor tree. A parent record is found (related) even if there is no parent DDO associated with it. Until version 18.2, this was standard behavior. The default is True in the Data Dictionary class and False in the abstract DataSet class.

Compatibility Notes

The pbSmartRelate property is new to DataFlex 18.2. Prior to this, a DDO find was followed by a relate that would read in all related parents, even if the parent was not part of the DDO structure. You can maintain this legacy behavior by setting pbSmartRelate to False. Almost all developers were not aware of this global relate behavior and naturally assumed that a related find would not occur on parent tables that were not in the DDO structure. Therefore, smart-relates (pbSmartRelate = True) probably now works the way you expected it always did.

The default for pbSmartRelate is True. While we normally err on the side of maintaining backwards compatibility, we felt that this behavior change was the best choice. Our reasoning was as follows:

  • Smart-relates mean fewer finds, which can be significant, especially in SQL. If we don't make this the default, you will have to actually set this to gain the benefits of this feature – it’s too easy to overlook a new property.
  • The value of pbSmartRelate should never be an issue with edits, saves, or deletes. If a DDO structure is incomplete, you will not be allowed to make changes anyway. Therefore, smart-relates and any potential legacy issues only come into play when you are querying data.
  • This is already the behavior that most developers expect and develop around. We felt it was unlikely that developers were counting on the old behavior and that any behavior difference would be accidental.

When migrating up to 18.2, our advice is as follows:

  1. If you actually knew that DDO relates were unconditional and you wrote code that counted on this behavior, change the default of pbSmartRelate to False. We assume you are using your own DD class layer, and you can set the property to False in your subclass. As time permits, study your code and make the required changes so you can take full advantage of smart relates.
  2. If you have any concerns that you may be accidentally relying on the legacy behavior, set pbSmartRelate to False in your subclass. Keep in mind that this accidental behavior can only matter when querying data.
  3. Otherwise, keep pbSmartRelate set to True and take advantage of the increased performance with no required programming changes.

Constraints

Added RebuildAllConstraints message to base_data_set. This sends Rebuild_Constraints to all DDOs in a structure.

Whenever a constraint is changed, rebuild_constraints must be sent to the DDO that was changed. In addition, rebuild_constraints should be sent to all DDOs that might be impacted by the change. This is required when constraints are inherited. We therefore advise that you send rebuild_constraints to all DDOs within a DDO structure. RebuildAllConstraints does this. It sends Rebuild_Constraints to all DDOs in the structure. We now advise that you send RebuildAllConstraints, instead of sending Rebuild_Constraints. It is easier and less error-prone. You still might use rebuild_constraints for augmentation, but even this is unlikely.

Note that this was a change actually made in 18.1, but the documentation was not in the What's New (only the DataDictionary class documentation).

Base System

We've added lots of new functions and methods in DataFlex 18.2, including...

Array and String Manipulations

See the full lists of Array and String functions.

Time and Date Manipulations

We've added 20 new functions that make it easier to set dates and perform datetime arithmetic.

See the full list of Time and Date Functions.

Class and Object Information

There are four new functions/methods added to cObject which allow you to interrogate a class or object’s class hierarchy.

Help System

There are very significant changes in what is (and is not) listed in a class's attributes pages (events, properties, procedures) in the Class Reference. Depending on the class, many of the attributes were missing from those pages, and they should all now be properly listed (some may still need additional documentation). This change may be hard to initially verify because the improvement is widespread, and a lot of the methods that were impacted are deep in the class hierarchy. An interesting example is comparing the 18.1 and 18.2 pages for the dbForm list of Properties, Events, or Methods. The bottom line is that the Class Reference in DataFlex 18.2 is much more accurate than in any prior version of the product.

See Also