Visual dBASE 7.5 Release Notes

Following are some items which describe significant product changes which represent noticeable differences between version 7.5 and prior 7.x versions of Visual dBASE. These changes may affect operations in the design environment, or the operation of applications.

• The default year for SET EPOCH... for new installs has been changed to 1950. The default year for SET EPOCH... for prior versions of Visual dBASE was 1900. This includes new installs of Visual dBASE 7.5 and your applications that are run using the Visual dBASE 7.5 runtime engine. If your applications rely on an Epoch setting of 1900, after installing Visual dBASE 7.5, change the Epoch setting through the Visual dBASE main menu Properties | Desktop Properties in the Data Entry tab. Also, if you will be using the Visual dBASE 7.5 runtime engine for existing applications that rely on an Epoch setting of 1900, be sure that the following entry exists in the application's INI file:

  [CommandSettings]
  EPOCH=1950

  Also ensure that no other EPOCH entry exists in the [CommandSettings] section of the application's INI file.

• Version 7.5 enforces strict qualification of the Rowset.IndexName assignment. In prior versions, no such qualification was performed for Rowset.IndexName. Therefore, if an invalid Rowset.IndexName was assigned, or if the Rowset.IndexName was padded with spaces, no error occured, and an index was not used for the Rowset. In version 7.5, the specified Rowset.IndexName is verified to exist in the Rowset's table. If the index does not exist, or if the index name assignment is padded with extra spaces, an error message will be displayed.
  
  
• Version 7.5 has changed some streaming conventions in forms and reports. In prior versions, the verbose this.Parent.Parent... reference chain was used to reference a parent object. In Version 7.5, for those classes which support the 'form' reference, the 'form' reference is used instead. This is functionally equivalent to the older this.Parent.Parent... referencing scheme. However, you may notice that the byte count of form (*.WFM) and report (*.REP) files is now smaller after saving the form or report from the Form Designer or Report Designer in Version 7.5.
  
  
• Version 7.5 has stopped streaming some unnecessary code in forms and reports. For example, in prior versions, the statement 'value = false' was streamed to the form (WFM) file for a PushButton. Streaming this statement is not necessary because false is the default for this property. Version 7.5 has stopped streaming some of these types of unnecessary statements to form (WFM) and report (REP) files. You may notice that the byte count of form (WFM) and report (REP) files is now smaller after saving the form or report from the Form Designer or Report Designer in Version 7.5.
  
  
• Version 7.5 has stopped padding Grid HeadingControl.Value assignments with extra spaces. In prior versions, the HeadingControl.Value was padded with trailing spaces to 25 characters. In Version 7.5, no extra spaces are added to the HeadingControl.Value assignment that is specified in the Form Designer Inspector or Source Editor. However, if you add either leading or trailing spaces to the assignment in the Inspector or the Source Editor, these extra spaces will be preserved.
  
  
• Version 7.5 now displays the name of data access objects directly below the object in the Form Designer, Report Designer, and DataModule Designer. Prior versions did not display the data access object names. Therefore, when opening a Form, Report, or DataModule in their respective designers, the objects may now appear to be jumbled together and overlap each other, or appear to overlap other objects. This is due to the increased width and height of the data access objects to accommodate the display of the names of the objects.
  
  
• Version 7.5 now creates a DataModule object in a Form or Report when dragging a DataModule (DMD) file from the Navigator to the Form Designer or Report Designer. In previous versions, when a DataModule (DMD) file was dragged from the Navigator to the Form Designer or Report Designer, a DataModRef object was created. Existing Forms and Reports will not be affected by this change. With the DataModule, you can drill down in the Inspector to view the data access objects (and their properties) contained within the DataModule. Note that changes made to data access objects that are contained within a DataModule on a Form or Report will not be streamed to the Form (WFM) file or Report (REP) file. These changes should be made to the DataModule in the DataModule Designer or in the DataModule (DMD) source file.
  
  
• Version 7.5 has discontinued firing child rowset events when a corresponding event occurs in a parent (master) rowset. In previous versions, when an event occurred in a parent rowset, the corresponding event in all child rowsets that were linked to the parent rowset was also fired, even though the action did not actually occur in the child rowset. In version 7.5, child rowset events will not fire unless that particular event has actually occurred in the child rowset, independent of the parent rowset. The events affected by this change are:

  OnSave
  CanAbandon
  OnAbandon
  CanDelete
  OnDelete
  CanEdit
  OnEdit

• Version 7.5 has changed the operation of the Date class such that the properties and methods associated with the year portion of a date always return a 4-digit year. In prior versions, the properties and methods of the Date class that are associated with the year portion of a date always returned a 2-digit year. The properties and methods affected by this change are:

  GetYear
  Year

• Version 7.5 has changed the display of forms which are updated during loop processing. Some example code:

  For x = 1 To 1000
  // Some processing here.
  FORM.Text1.Text := "Processing record: " + x
  Next x

  When the code in the example above was run, the Text object display was not updated until some time after the loop had completed. In Version 7.5, the Text object display update is forced on each assignment change to the Text1.Text property. It was common practice in prior versions to use a workaround with the Windows API in application code to force the update to occur. These types of workarounds should no longer be necessary in most situations and should be removed from application source code after testing to ensure that the new default behavior satisfies the application's requirements. The classes affected by this change are:

  EntryField
  PushButton
  Text
  TextLabel