Language and Code Cleanup

Read this before attempting to migrate and compile your application.

One of the important changes in DataFlex 19.1 is that we have provided a way for you to modernize your existing code. This is an optional process and is mostly handled through a new compiler warning system. Your existing applications will continue to run the same. There are some cases where your existing application may generate compiler errors. These are easily addressed.

If you receive compile errors, it will be for one of three reasons:

You are using some very old commands that have been removed from the basic command set (i.e., these commands have finally been removed from fmac. They have been moved to OldFmacCommands.pkg.
You are using some classes that are obsolete and have been removed from DFAllent.pkg. These classes still exist and may still be used. They can be added individually as needed or added by using the OldDFAllent.pkg package.
The compiler is better detecting and reporting errors. This is always a good thing. The most likely error is a redefinition of a symbol via the Define command. This has never worked and until now it has just silently done the wrong thing. This is a real error.

Therefore, if you see compiler errors, do the following:

If needed, add a “Use OldFmacCommands.pkg” to the top of your application.
If needed, add a “Use OldDfAllEnt.pkg” immediately following the current “Use DfAllent.pkg”
Fix those other real compiler errors.

So your project will have a starting block that looks like this...

Use DFAllent.pkg

Use OldDFAllent.pkg

Use OldFmacCommands.pkg

And then as time permits:

See if you can remove the need for OldFmacCommands.pkg. These are very old commands that may not even be working.
See if you can remove some of the old obsolete classes. This might be a longer term project.

Once you have your applications compiling and running properly, you are now ready for the next level of code cleanup by using the new compiler warning system.

If / Else / Case Debugging and Warnings

In 19.1 we have added the capability to actually break on If, Else and Case statements as long as the line is separated with a “;”. For example:

If (doThis) ;

Send Do That // You can now put a break point here as well as the line above.

In the past you could not do this and we had always recommended using Begin/End blocks for If/Else/Case commands. Using Begin/End blocks is now only one method of structuring your conditional code to allow for improved debugging. Now, if you prefer to use a single line If/Else/Case (i.e.., no Begin/End block) we recommend that that you break the line using the “;” separator. This makes it much easier to debug the line.

DataFlex 19.1 generates an optional compiler warning so you can see all the places where such a line separator would be suggested. This can generate a lot of warnings! Technically, there is nothing wrong with these lines and this represents more of a coding preference than an obsolete technique. As these are optional warnings, you should not feel the need to change your code – unless you want to adhere to this new suggestion.

DataFlex Code Cleanup

As we moved further into the design and implementation of the 64-bit and UNICODE projects we realized that now was the time to take a solid pass at cleaning up the older aspects of the DataFlex language and our code base (both the underlying C code and the DataFlex code in the utilities and examples).

We set out initial goals for this process...

Remove really old commands from FMAC
These may not even work in windows or web applications as they date back to character mode and pre-OOP days.
Mark old classes obsolete and private
This gets them out of the documentation
This includes some older windows classes and web classes
Remove the obsolete classes from DFAllEnt.pkg
Remove packages that don't belong in Web applications
Restructure some class hierarchies
Make sure we are not using obsolete commands, classes or techniques

We soon realized that we would need tools to help us take our own code through this process and lead the development community through their own code cleanup. We added a compiler warning system to do this. This allows us and you to quickly find old obsolete code and deal with it.

Compiler Warnings

As we embarked on our Language and Code Cleanup we determined that the task would be cumbersome unless the Studio and compiler supported a new warning system to systematically find and work through the massive amount of code that makes up the product (and your applications). We designed a system so that the Studio provides compile time warnings for…

Obsolete commands
Obsolete global functions
Use of Indicate command instead of Move command
Use of “Local” in commands to define local variable
Use of “public” or "private" in property commands
Obsolete classes
Inclusion and use of obsolete packages (raised when a pkg is used)

Warnings are just that – warnings. A project with warnings will run just fine.

Showing warnings can be enabled and disabled at the project level. At a more advanced level, you can also control warnings as the file or code level. The Studio shows the warnings in the output panel. This makes it easy to jump to the code in question.

Project Level Warnings

The Project Properties dialog has a new checkbox to Suppress Compiler Warnings.

Controlling Warnings at File or Code Level

The #WARNING command causes compiler to output a warning. This is non-fatal and the application will compile. The syntax is

#warning ErrorNum “error text”

...just like the #error command.

You can use this new compiler command in your code to add your own warnings.

Commands to Control Warnings

There are two commands to control the behavior of various warnings.

CompilerWarnings Off|On|Suspend|Restart

This lets you control the entire warning system.

Off – disables compiler warnings until they are reenabled
On – reenables compiler warnings
Suspend – disable compiler warnings until end of the current file
Restart – unconditionally turns compiler warnings back on

The warning system allows these commands to be nested. Each level of nesting increments an internal warnings-off counter, which will not be reenabled until that count goes to 0. Think of it as Lock/Unlock.

CompilerLevelWarning IfExp|Item|IfLine|All On|Off

This is an advanced command that gives you some control over how strict your warning checking should be. By default, these are all off. Not all compiler warnings are optional like this – only the ones that are high overhead, falling on the “picky, picky” side or more a matter of programming preference.

IfExp – raises warnings when if/else/case uses old style “if x eq y” type of syntax instead of “if (x=y)”
Item – raises warnings when the Item keyword is used. It is never needed but there is nothing wrong with using it.
IfLine – raises warning when If/else/case is used in a single line.
All – turns all extended warnings on. If you want the strictest warnings just add this line to the top of your code:

CompilerLevelWarning All On