Skip to content

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:

  1. 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.
  2. 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.
  3. 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 Use OldFmacCommands.pkg to the top of your application.
  • If needed, add 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.

New Compiler Features

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 breakpoint 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 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.

See Also

How we cleaned up our own code

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 at 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 the 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.

Warning Control Commands

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 re-enabled.
  • On – re-enables compiler warnings.
  • Suspend – disables compiler warnings until the 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 re-enabled 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 warnings 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

See Also

What's New in DataFlex 19.1