Keep up to date with the Symphony Framework by subscribing to the mailing list.

Check out the new Symphony Framework Academy! It’s the home for information and tutorials to help you get the most from the Symphony Framework! Click on the Academy option below.

Symphony Framework Release Notes

Symphony Framework Version 2.7.7.5.


Significant work has been done internally within the Symphony Framework to improve the execution of thread based applications. Creating desktop applications requires the use and control of threads to execute elements of code.

IMPORTANT NOTE. To ensure that the Symphony Framework can correctly dispatch execute of code onto the right threads it is imperative that you add the following line of code at the very beginning of your application start-up code;

Symphony.Conductor.Static.ThreadSafe.AnchorToUIThread()

For example if you have a Windows Presentation Foundation application you can add this code to the constructor in your App.xaml.dbl file.

Failure to add this code BEFORE any other code executes may prevent the Symphony Framework from establishing the right User Interface thread causing your program no not function correctly.

The ThreadSafe class has been extended with a new static method AnchorToUIThread(). This static method should be called prior to any other logic being executed within your application. A new static variable BaseUIDispatcher has been added. This is now used throughout the Symphony Framework to ensure that all UI code is executed on the UI thread.

A New BackgroundDispatcher class has been added to the Symphony Framework. This class is used to control execution of logic on the right thread. Many elements of the Symphony Framework utilize this new class. You use the backgroundWorker to create a “dispatcher”. This dispatcher is like a pipe onto a code execution thread where we push logic to run. The execution of the code on a thread always happens in the order in which it is placed onto the thread, therefore you can ensure that logic happens in the right sequence. This is very important when using Synergy file IO operations. Inside the BackgroundDispatcher we create a collection of active dispatchers. When we get to a certain number of active dispatchers we create a new thread and put subsequent dispatchers on that thread. This is basic load balancing. You can utilise the class and perform background tasks easily, for example;

lambda doWork()
begin
;;do processing
end

Symphony.Conductor.Utility.BackgroundDispatcher.UtilityBackgroundDispatcher.Dispatch(doWork)

A new UIDispatcher class has been added to ensure execution of code targeted to the UI thread is run on the right UI thread. This class is used within the Symphony Framework.

The Symphony Data Object (BaseDataObject) has been siginificatly improved:

  • A new enumeration type has been added. The DataObjectNotificationState enumeration can be either DataObjectNotificationState.RaiseEvents or DataObjectNotificationState.NoNotifications. This enhancement allows you to block UI updates being raised by the Data Object. The new ObjectRaisesPropertyChanged property can be used to set if the Data Object should raise ProperyChanged events to the UI. This property is DataObjectNotificationState.RaiseEvents by default. This significantly improves the performance of a Data Object if;
    • They are being processes in the background and not attached to any UI components.
    • The Data Object is being added to an Observable type of collection. The individual field notifications are not required as the object is being constructed and added to the collection.
  • A new property, ObjectRaisesPropertyChanged, has been added. When using Data Object’s that are not bound to any UI, for example when iterating through a SynergyDE.Select collection you can prevent notifications being raised. You can either set this property directory after the Data Object has been created, or pass the DataObjectNotificationState enumeration to the alternate constructor. This property can be set to:
    • DataObjectNotificationState.RaiseEvents which will ensure that and field changes will be notivief to any bound UI control
    • DataObjectNotificationState.NoNotifications which prevents PropertyChanged notifications being raised.
  • Minor internal performance improvements have been made reduce the object creation time.
  • Added a new method GetFieldReadOnlyState(field_index). This new method is used by the code generated Data Object to interrogate the read only status of a field.
  • Added a new method SetFieldReadOnlyState(field_index, value). This new method is used by the code generated Data Object to set the read only status of a field.
  • Enhanced the SetFieldEnabledStatus method so it now accepts a field name of “*ALL*”. This allow to set/reset the enabled state of all the fields within a Data Object.
  • A new public method SetFieldReadOnlyStatus has been added to the BaseDataObject class that allows you to set/reset multiple or “*ALL*” field read-only status setting. You can pass a single field name, comma separated string of field names or “*ALL*” and the boolean read-only value.
  • The property changed notifications are now correctly raised on the UI thread.
The base FileIO class within the Symphony Framework has been significantly improved to enforce the execution of code when your applications uses multiple threads. The class utilizes the new BackgroundDispatcher (see discussion below) to control processing all IO logic on the right thread. The BaseFieldInformation class has been modified to use public fields and not properties. This is to improve the performance of the Data Object construction.

Template changes.

The Symphony_CRUDMainView.tpl template file has been changed to correct the spelling of the ConfirmState (it was ConfirmyState). This change, if you regenerate, may break your code unless you regenerate all code generated elements of a CRUD application. You can check for this by searching your entire solution for “ConfirmyState”. The Symphony_CRUDMainWindow.tpl template file has been changed to correct the spelling of the ConfirmState (it was ConfirmyState). This change, if you regenerate, may break your code unless you regenerate all code generated elements of a CRUD application. You can check for this by searching your entire solution for “ConfirmyState”. A new constructor has been added to the Symphony_Data.tpl. This new constructor accepts the string record area and the new DataObjectNotificationState enumeration. See the discussion on DataObjectNotificationState above. The template has been correct to use the right field_nameIsReadOnly backing field. A new constructor has been added to the Symphony_DataNoExcel.tpl. This new constructor accepts the string record area and the new DataObjectNotificationState enumeration. See the discussion on DataObjectNotificationState above. The template has been correct to use the right field_nameIsReadOnly backing field. Unless you are planning to utilize the Microsoft Excel adaptor it is recommended that you use this template instead of the Symphony_Data.tpl template. The BackgroundLoadedSearchViewModel no longer cancels the background worker. This was causing lists to not load correctly. Within the BaseViewModel a new overload for the MoveToState() method has been added. The new overloaded method allows you to request that the UI is updated once the visual state has been navigated to. This helps when navigating to a “working” visual state and you want the UI to respond.

Core changes.

The WriteException method has been enhanced to write the complete stack trace to the event viewer.

Crescendo changes.

The SynergyDecimalBox class has been fixed when processing fields with more than two decimal digits. The DialogControl has been updated to look more like a form. It has a dragbar within which a title can be placed by setting the Title property in the DialogControlViewModel object.