Each new release of DataFlex brings you fixes and7 new features to advance your development environment. To take full advantage of those, you may need to adjust your current workspaces’ settings and structures.
In order to speed up that process and have your current workspaces comply with the new environment requirements, DataFlex Studio includes a Studio Workspace Migration Wizard that will bring your workspaces and all its resources (e.g. libraries used in the workspace, paths containing directories outside the workspace root) up to the current revision requirements, i.e. it will migrate all that is needed for your workspace to be used in the current revision of DataFlex.
With the Studio Workspace Migration Wizard you will be able to migrate your workspace in place or, copy it to a different location and migrate it there. Combined with the ability to run multiple revisions of DataFlex concurrently on a single operating system, keeping a copy of your workspaces allows you the ultimate in flexibility for maintaining code in multiple revisions and/or testing code in current versus prior revisions.
To migrate a Studio Workspace to the current DataFlex revision, simply open the existing workspace in the DataFlex Studio. The Studio will detect that the workspace requires migration to be compatible with the latest revision and will automatically start the Workspace Migration Wizard.
The Studio Workspace Migration Wizard will analyze the workspace's Studio Workspace file (.sws) and the Workspace Configuration file (.ws) and determine whether other source code and files are referenced by the workspace being migrated. This may include Library Workspaces or external directories (i.e. directories not under the workspace root) used in the paths in the Workspace Configuration file.
Please pay particular attention to the following information.
Existing DataFlex 17.1 Web Framework applications that manually fill lists or grids using tWebRow structure (aValues array) will need to be updated as the definition of the tWebRow struct has changed from...
Struct tWebRow
String[] aValues
End_Struct
to...
Struct tWebCell
String sValue
String sTooltip
String[] aOptions
End_Struct
Struct tWebRow
String sRowID
String sCssClassName
tWebCell[] aCells
End_Struct
Developers will need to search for each .aValues within the application and replace with the corresponding variable from aCells. For example, all .aValues[0] should be replaced with .sRowID and all other aValues[n] should be replaced with .aCells[n-1].sValue since aValues[0] became sRowID.
In the WebOrder sample, DemoFileDialog.wo (oDemoFileDialog cWebModalDialog object) had the following piece of code:
// Populate the row....
Move sFileName to aTheRows[iRow].aValues[0] // row id
Move sFileName to aTheRows[iRow].aValues[1] // File Name
Move sSize to aTheRows[iRow].aValues[2] // File Size
That had to be changed to the code below to conform with the new tWebRow structure:
// Populate the row....
Move sFileName to aTheRows[iRow].sRowID // row id
Move sFileName to aTheRows[iRow].aCells[0].sValue // File Name
Move sSize to aTheRows[iRow].aCells[1].sValue // File Size
Note: If the change described above is not made, Developers will experience compiler errors when trying to compile/run a migrated web framework application.
Note that this section only applies if you are migrating from DataFlex 16.1 or earlier.
Be sure to read...
Understanding Fonts in DataFlex
What's New in DataFlex 2012 - Font Changes
You can easily run a quick test to see how your application looks with pbUseWindowsFont set to True. It will probably look pretty good. Don't assume you are done. There will likely be changes you will need to make.
If you don't have time to properly test the changes and make adjustments, don’t switch over. You can continue to run your applications in DataFlex 17 in legacy font mode.
If you want your application to scale at different DPIs, you absolutely want to review Writing High-DPI Win32 Applications. DataFlex will handle many of these issues for you, but you need to realize that you must develop (or change) your applications with high DPI settings in mind.
Be aware that the size of your application’s panels, containers and controls will change when you use the Windows system font. The physical size of a dialog unit is based on the font being used. This is a good thing as everything will get bigger or smaller in a proper proportion to your font. This makes you application look good and consistent.
As you test, you want to test your application under different DPI settings (Normal, Large and Extra Large). Depending on the Windows version, changing these settings may require that you log out or even reboot. You also want to test using different Windows versions (at least XP and Windows 7). Both of these tasks can be simplified by using virtual machines on your computer.
We are allowing Windows do most of the work and sometimes Windows does strange things. Compare your results against other applications before deciding that you have a problem. For example, Windows Vista and 7 do a better job of scaling DPIs than XP. There is not much that you or we can do about that.
The Studio will allow you view your modeled views and dialogs with the new system fonts and using the legacy method. The setting pbUseWindowsFont in your cApplication object will determine which mode the Studio will display by default. You can switch between modes using the context menu. This provides a quick to check out each of your modelable components and it provides a great way to make changes and see the results.
You should search your source for code that explicitly sets font code. Load your workspaces in the Studio and perform global file searches for the following:
Get / Set Typeface: if the typeface is MS Sans Serif, you probably want to remove it. Anything else should be marked for testing.
Get/Set FontSize: You want to get rid of this. First try removing it, as it may be unnecessary. If you need to set a custom height, use FontPointHeight instead.
Get/Set Physical_FontSize: You want to get rid of this. First try removing it, as it may be unnecessary. If you need to set a custom height, use FontPointHeight instead.
Get/Set Form_FontSize: see FontSize
Get/Set Form_Typeface: see Typeface
Get/Set Form_PhysicalFontSize: PhysicalFontSize
Applications may contain GUI properties such as GuiSize, GuiLocation, GuiClientSize and GuiWindowSize and it may contain methods such as GuiToDialog and DialogToGui. In most cases, this code will be fine. This is usually used to handle custom control placement where you get a current GUI value and make adjustments to it. If you’ve done that, things should work as before. However, if you are setting explicit constant value settings such as “Set GuiSize to 100 120” in place of using dialog settings such as “Set Size to 10 14”, you have created code that may not scale at other DPIs and may not look as good with different fonts. This code will require attention.
The font changes work well with anchoring. However, when there is a problem, anchoring will make a simple problem appears complex. If you run into any inexplicable sizing issues, make sure you set peAnchors to anNone, set piMinSize and piMaxSize to 0. Also set pbPreserveEnvironment to False in your cApplication object. When you’ve resolved any issues, you can restore these properties.
If you are using non-stretched bitmaps in BitmapContainer, dbBitmap and Container3d dialogs, those dialogs are probably set in dialog units. When you use the Windows system font or when you change DPIs, those containers will change size while your bitmap will not. When you mix scaling and non-scaling controls you have to plan and adjust for this. Here are three ways to approach this:
Bitmaps in containers can be stretched to fit the container size (Set Bitmap_Style to Bitmap_Stretch). Depending on the bitmap, this may be a simple and satisfactory solution. Make sure you test this at various DPIs.
Arrange the images on your views so that a smaller bitmap still looks appropriate at higher resolution DPI. Leaving enough whitespace around the image so that it does not look like it is supposed to fill an area can help. You might also want to center the bitmap (Set Bitmap_Style to Bitmap_Center) in the container. If you get this right, you can make a single bitmap container work well in all environments.
Set the size of the container with GUI units that match the pixel size of the bitmap. This is one time where you might want to use GUI units. If you have controls located to the right or below a bitmap container and want your view to look perfect, you may need to write custom code to adjust the location of those controls to handle the mixing of scaling and non-scaling controls. If you place those other controls inside their own containers, your task is simplified by only having to customize the location of the containers. This solution has the disadvantage that it cannot be fully visually modeled (although you can get it close in Studio and handle the final adjustments in code).
Note that this section only applies if you are migrating from DataFlex 14.0 or earlier.
The DataFlex 2012 Studio supports Data Dictionary modeling and the Studio Workspace Migration Wizard will automatically make the appropriate adjustments to your data dictionaries.
The changes that are made when migrating are:
A backup file is created by appending .bak (e.g. Customer.DD.bak).
All the properties previously set in Define_Fields are moved to Construct_Object. In this process Define_Fields is removed from the file and replaced by Construct_Object. Any existing code in Construct_Object is merged with these changes.
Define_Auto_Increment statements are changed to 'set Field_Auto_Increment' statements.
'Send Add_Client_File', 'Send Add_Server_File' and 'Send Add_System_File' statements are changed to 'Set Add_Client_File', 'Set Add_Server_File', 'Set Add_System_File' statements, respectively.
'Set Field_Options' statements are changed to multiple 'Set Field_Option' statements .
'Set Foreign_Field_Options' statements are changed to multiple 'Set Foreign_Field_Option' statements.
Object references for Field_Prompt_Object and Field_Value_Table are changed to simple object names.
Foreign Field Options statements for KeyField, IndexField and Default are separated into individual 'set Foreign_Field_Option' statements for each option.
All DD markups used by prior revisions are removed.
All comments created & maintained by Database Builder in prior revisions are removed.
The migration process will examine all data dictionaries that are contained in the workspace and used in any registered project.
Since Library Workspaces are also standard DataFlex workspaces, any such Library Workspaces found in the workspace being migrated will be analyzed to see if they require to be migrated too. If they do, the Studio Workspace Migration Wizard will prompt you to review those libraries and choose from migrating the library, leaving the library as it is (i.e. you don’t want to deal with that at that moment; you will review it later) or removing it from the workspace.
Note that if you choose to leave the library as it is, your workspace will not be able to use that library until that library is migrated. Also, if you choose to migrate a library that in turn uses other libraries, those used libraries will also be analyzed.
Once you select how the Studio Workspace Migration Wizard should handle that library, the wizard will carry out the operations what your selection entails.
After reviewing all the libraries, you will need to review the paths specified in the Workspace Configuration file (.ws) that contain directories outside the workspace root. For those, you can copy them into a different directory, you can simply select a different directory to be used instead or, you can keep the current directory in the file and continue to use it in your migrated workspace. Beware of that last option because if you have workspaces from different revisions sharing the files in that directory, you may run into problems – like sharing source code that is not valid throughout revisions.
Library Workspaces and Migration
The Workspace Migration Wizard in DataFlex supports migrating older workspaces to the DataFlex 2008 environment the same way that earlier versions of DataFlex 12.x did. It supports all revisions from DataFlex 8.0 through DataFlex 11.1.
Opening the workspace file (.ws file) in the Programs folder of any older workspace will automatically start the Workspace Migration Wizard.
Migrating older workspaces to DataFlex
What's New in DataFlex 2017 - 19.0