Development Team Blog

In Visual DataFlex 14.1 we added data dictionary modeling to the Studio. This task used to be performed by the Database Builder tool.

Database Builder used a quite primitive approach to source code modeling. It relied on special marker comments and a set of hard-coded symbols to understand how to model a data dictionary class.

The Studio's modeler is more powerful and flexible. It properly analyzes the source code of the data dictionary file and all of the files used by the data dictionary file so that it has a complete picture of each symbol and each declaration. It does not rely on any special comment markers or hard-coded rules.

When you migrate a workspace from Visual DataFlex 14.0 or below to Visual DataFlex 14.1 or above, the migration tool makes some special changes to your data dictionary classes so they can be properly modeled in the Studio.

A developer recently asked me...

why can't the Studio analyze an unmigrated DD source ? Seems DAW put the markup in the old DD in first place and so knows what they mean. This is a sticking point for me (and others) that you have to migrate an entire workspace to get a proper DD in 14.x and 15.x

.
When data dictionary code was modeled by Database Builder there were some severe restrictions regarding your ability to freely edit the data dictionary source code. These files were peppered with special comment markers that delimited special "zones" where you could not edit the code. If you did edit code in these zones then those changes would be erased by Database Builder.

Most of the changes that are made by the migration tool is to code that used to live within these special "zones". We felt that the migration could justifiably adjust code within these zones since that code was effectively 100% generated and maintained by the Database Builder tool in the first place.

One change that the migration tool makes which is outside these zones is that it modifies the Procedure Define_Fields declaration and places its contents inside of Procedure Construct_Object. Why do this? and why the need to change code the inside these special "zones"?

Class Modeling

When we created the Data Dictionary Modeler in VDF 14.1 we had to teach the Studio a new skill. That was the ability to model a Class declaration. Previously, our parser did not analyze the Set statements inside the Construct_Object procedure of a class declaration and therefore did not have a model of any initial property values determined by Set statements in the class constructor. This is the reason why you needed to add...

Code:

{ OverrideProperty = aaaa  InitialValue = xxxx }

...meta tags to your class declarations whenever you changed a property value in the Construct_Object of a subclass.

With Visual DataFlex 14.1 these meta-tags are no longer needed, at least in the case of Set statements inside of Construct_Object. Construct_Object is a special part of a Class declaration. It is the point were code is executed each time an object of that Class is created. In object-oriented terms Procedure Construct_Object acts like a class constructor.

We taught the Studio to parse Set statements that are executed in the class constructor and adjust the initial values of the class's properties accordingly. This is why you no longer need to add special meta-tags for these Set statements. (I already covered this in greater detail in previous Blog article).

One problem with data dictionary classes prior to Visual DataFlex 14.1 is that all of the modeled code is placed inside Procedure Define_Fields, not inside the class constructor (Construct_Object). Clearly the Studio parser should not analyze all the set statements inside every procedure declaration of a class because this would create an incorrect picture of the properties' initial values. Should we hard-code a special exception for Procedure Define_Fields? This is exactly the kind of hard-code rule that we are trying to avoid. Also, people who are new to Visual DataFlex might rightly ask why data dictionary classes look different to every other class in this way. This could be a point of confusion for them.

For backwards-compatibility reasons Procedure Define_Fields will still compile and run as it always did but the Studio will not try to model any data dictionaries containing Procedure Define_Fields. It is a pretty good assumption that the Studio would incorrectly model such files because it would not know about any Set statements inside Define_Fields. It is also a pretty good assumption that the data dictionary was not migrated and that this might be deliberate e.g. the developer might be sharing the data dictionary with a pre-Visual DataFlex 14.1 project. In this case the Studio's modeler would be adding syntax to the data dictionary that would not compile in Visual DataFlex 14.0 or below. So in this case the Studio takes a "hands-off" approach.

What about all the other changes that the migration tool makes?

Here we are referring once again to code that was previously generated and maintained by Database Builder. Some of the syntax for setting properties in a data dictionary class did not lend itself very well to analytical modeling. Instead of being declarative e.g. Set MyProperty to "X", there were cases where properties are set implicitly by sending messages. e.g. Send Add_Server_File.

The Studio's parser analyses code "declarations" and builds a model from them. It is not designed to understand what happens when messages are sent from object to object. This would require a code interpreter and any model built by such an interpreter would vary depending on the state of the application at any given moment.

To model statements like Send Add_Server_File we would have to make more hard-coded exceptions and the parser would have to build a model of every Send statement in your application. We decided instead to modify the syntax of these statements to make them more declarative. Once again these changes are fully backwards compatible, but the old syntax is not understood by the Studio's various modelers.

The migration tool also cleans out all of the old special comment markers that were inside the data dictionary files. Many developers complained in the past that the Studio kept legacy code markers in the source code that were no longer needed (or wanted). I'm talking about those old //AB- markers. Keeping markers in the data dictionary files might also suggest to some people that the data dictionaries could still be modeled in the old Database builder tool, which is not true. For these reasons we decided to clean out those marker comments during migration.