OpenEdge 11.7 has been retired by Progress Software on April 1st 2025. In consequence we urge all customers still using OpenEdge 11 to upgrade to OpenEdge 12.2 or 12.8 as soon as possible.

We are intending to drop the official support of the SmartComponent Library for OpenEdge 11.7 during the second half of the year 2025. We will then no longer ensure that new features of the framework will be usable with OpenEdge 11.7

Customers that are concerned by this intention, should reach out to us as soon as possible, so that we can discuss about a solution.

We are pleased to announce that we are not aware of any issues using the SmartComponent Library on OpenEdge 13.0. We hereby declare OpenEdge 13.0 fully supported for the SmartComponent Library as of the release of February 15th 2026.

We are pleased to announce that we are not aware of any issues using the SmartComponent Library on OpenEdge 12.8. We hereby declare OpenEdge 12.8 fully supported for the SmartComponent Library as of the release of January 15th 2024.

We are pleased to announce that we are not aware of any issues using the SmartComponent Library on OpenEdge 12.2. We hereby declare OpenEdge 12.2 fully supported for the SmartComponent Library as of the release of April 09th 2020.

Our first VS Code extension is available in the VS Code marketplace: https://marketplace.visualstudio.com/items?itemName=ConsultingwerkApplicationModernizationSolutionsLtd.oemanager

The extension supports developers with PASOE related routine tasks during development:

• checking agent or session status

• trimming the PASOE agents

• restarting a new agent vai the ping request

Got questions about using the SmartComponent Library? Wish to discuss feature requests with other users of the SmartComponent Library? To facilitate networking in the growing number of SmartComponent Library users and developers, we've added a developer forum on our new home-page. The developer forum can be found at: https://www.consultingwerk.com/support/forum

A login is required to participate in the forum. Don't be shy - create your account today!

Open

Following the release of the OpenEdge 11.7 Release we have completed our testing of the SmartComponent Library on this release of Progress and are proud to announce formal support for the SmartComponent Library on OpenEdge 11.7 with the 2017-04-24 release of the SmartComponent Library. Generally we recommend customers on OpenEdge 11 to upgrade to OpenEdge 11.7 quickly. Starting the 2017-07-14 release we are supporting OpenEdge 11.7 Service Pack 1 (11.7.1).

Starting the 2015-10-09 release the Business Entity Designer will feature a start page with links to most recent release note articles on this site.

With SCL-751 we have adopted native Enums for OpenEdge 11.6. To activate this feature customers must add a definition to products.i. SCL-751 provides details for this.

With SCL-1113 we have modified the templates for SmartWindowForms and SmartTabFolderPages generated from the Business Entity Designer. We have removed the initialization of the viewer controls SmartTableIOState property (value was set to "NoDataSource" within the InitializeComponent method). Customers using their own set of templates should adopt the same fix to their templates.

We have updated proparse with further enhancements in this release (see https://github.com/consultingwerk/proparse/releases/tag/4.0.1.1177). Please download the .NET Assemblies ZIP file from our ESD and replace the proparse.net.dll in your environment with the latest one. The new assembly reference is:

As proparse is used by our Business Entity Generator, this new version of the proparse.net Assembly is also relevant for customers not doing GUI for .NET development and require support for parsing new ABL language constructs.

This version of proparse provides additional debug information when errors are thrown from proparse.net.dll.

To support the new SmartFilterControl and the "Filter" link between the SmartFilterControl/SmartDynamciFilterControl and a SmartBusinessEntityAdapter or SmartDatasetChildAdapter we have updated the Consultingwerk.SmartComponents.dll. The new Assembly reference is:

Customers need to update this Assembly in order to compile the latest releases of the SmartComponent Library.

We've updated the SmartHybridRealm class used for http authentication to leverage the IAuthenticationService. It is therefor required that for AppServers requiring http Authentication (e.g. REST or Web) the correct IAuthenticationService implementation is registered (using service.xml files).

Customers relying on the previous behavior should ensure that the Consultingwerk.SmartFramework.Authentication.AuthenticationService is regsitered as the IAuthenticationService. This implementation will auhtenticate users against the password stored in the SmartUser database table.

When users with no Login Company set should be able to login using the SmartHybridRealm, it's required to set the Login Company Tennant Domain (similar to the field in the Login Company Maintenance) in the .restapplicationsettings / .applicationsettings, e.g.:

This is required as the Hydrid Realm Interface from Progress does not provide the domain name to the authentication method.

This is an overview of the web handlers supported by this release

Starting August 14th 2016 we ship our source code also as UTF-8 encoded. The ZIP files ending with _utf8.zip contain the source code encoded with that code page. The source code in the remaining archives is still encoded in ISO8859-1. Also on Github there is a new branch containing the OpenEdge 11 based source code in UTF-8.

Related article (Progress K-Base): How to get Progress Developer Studio to save in UTF-8 encoding

• FSWatcher – Node.js daemon for triggering ANT tasks

• Peer Dependencies for v20.1.0

• Using the CalculatedFieldHelper

• SmartFramework MCP Server

• Telemetry Service

• Scaffolding Tools

• Excel Exporter and Importer using OpenXML Libraries

• ExcelWorksheetExporter and Importer using OpenXML Libraries

• SmartComponent Library Theming System

• Using DetailForms from MetaGrids

• Building Applications

• Server-Side Event Handler (SSEH)

• Peer Dependencies for v20.0.0

• Peer Dependencies for v19.1.0

• VS Code - Ant Target Runner sample configuration

http://esd.consultingwerkcloud.com/

https://github.com/consultingwerk/SmartComponentLibrary

Toolbar button definitions can now reference a form and/or a menu function whose authorization is evaluated in addition to the toolbar item security. A button that primarily launches a form is therefore disabled when the user is not authorized for that form or for the menu function behind it, instead of relying on the toolbar item security alone. Developers add the form or menu function reference to the button definition; existing buttons without such a reference keep their current behaviour.

Repository based containers (MetaForm and MetaControlGroup, including sub types such as MetaTreeViewForm, MetaPanelContainer and MetaDetailTemplate) now get a Mermaid flowchart diagram generated automatically whenever they are changed - from the SmartObjectMasterForm, the Web frontend, the repository wizards of the Business Entity Designer and the SmartFramework MCP server. The diagram is a Markdown file showing one subgraph per page with the object instances (instance name, object master name and description, layout position and parent instance) and one labeled edge per link. The generation is driven by the new ObjectMasterChanged event on ISmartRepositoryService and implemented by the new service Consultingwerk.SmartFramework.Repository.Mermaid.ContainerMermaidDiagramService, which is registered in services.xml and services_studio.xml. The output folder is configurable through the static property ContainerMermaidDiagramService:MermaidPath (default RepositoryLayouts, resolved relative to the ABL folder), and files are deleted or moved automatically when a container is renamed, moved to another product module or deleted. Adding the new members to ISmartRepositoryService is a breaking change for customer classes that implement that interface directly.

Consultingwerk.Util.LogManager no longer writes to the ABL LOG-MANAGER handle itself but forwards all logging to an ILoggingStream implementation. The actual writing moved into LogManagerLoggingStream, which remains the default, so applications that configure nothing produce identical log output. The new static method LogManager:SetLoggingStream (poLoggingStream) and the read-only static property LogManager:LoggingStream allow an application to redirect the logging of the entire framework - to NDJSON, a file, a parallel or pub/sub stream, or an in-memory stream in unit tests - without changing a single call site. Custom log entry types now live in the current stream instance and are carried over when a new stream is registered, and the new member ILoggingStream:IsLoggingAvailable () replaces the previous logging-available guards. ILoggingStream was extended with WriteError, WriteIgnoredError, IsLoggingAvailable and the structured dump methods WriteAllObjectInstances, WriteDatabases, WriteClassPath and WriteWidgetHierarchy; this is a breaking change for customer classes that implement ILoggingStream directly instead of inheriting the abstract LoggingStream base class.

The MetaEditor object type has a new TextFormat design attribute with the values Text (default), RTF and HTML, modelled after the InputType attribute. When TextFormat is set to RTF, Consultingwerk.Windows.Framework.Repository.Rendering.EditorRenderer renders the new reusable SmartRichTextEditorControl instead of the UltraTextEditor; the control was extracted from the SmartCommentControl and provides a formatting toolbar (font face, font size, bold, italic, underline, font color) as well as image insertion through a toolbar button, clipboard paste and drag and drop. The bound field may be CHARACTER, LONGCHAR or CLOB and is read and written through the Telerik RtfFormatProvider, while update mode, dirty tracking and the Leave, Validating and ValueChanged events behave as for the existing editor rendering. The web rendering emits the attribute as inputSettings.textFormat with the values text and html; RTF is a desktop-only format and EditorWebRendering now throws a dedicated SmartException naming the instance and object master instead of silently rendering a text area. The attribute is repository meta data, so the SmartDB registration, the RepositoryData export and DB/SmartDB/dump have to be taken over together.

A MetaEditor instance with the TextFormat attribute set to HTML is now rendered by Consultingwerk.Windows.Framework.Repository.Rendering.EditorRenderer as the reusable SmartRichTextEditorControl, which selects the Telerik HtmlFormatProvider through its TextFormat property so that one control serves both RTF and HTML. The HTML is exported as a fragment with inline styles, so content edited in GUI for .NET loads into the Kendo Editor of the Angular front end and vice versa; images inserted through the toolbar, the clipboard or drag and drop are embedded as base64 data URIs, the same representation the Angular editor uses. Data binding, update mode, dirty tracking and the Leave, Validating and ValueChanged events behave as for the existing editor rendering, and the bound field may be CHARACTER, LONGCHAR or CLOB. Plain text for backend processing is available through StringHelper:ConvertHtmlToText and StringHelper:ConvertHtmlToMarkdown; see the Customer Explorer of the SmartComponentsDemo for a sample.

Reading an RTF document with a large embedded picture was disproportionately slow: Consultingwerk.Util.DocumentConverter.RtfReader needed about 37 to 41 seconds for a document holding a 3.4 MB photo, roughly ten times as long as RtfWriter needs to write the same document. The hot spots in RtfReader and the hex decoding it uses have been reworked, so reading now takes time in the same order of magnitude as writing. This benefits every application that converts stored RTF to HTML per request, for example through Consultingwerk.Util.StringHelper:ConvertRtfToHtml. No changes required in customer code.

The JSON session configuration file supports a new optional loggingStream section that replaces the ILoggingStream used by Consultingwerk.Util.LogManager as early as possible during startup of an AppServer, PASOE or GUI client session. The section names a class implementing the new Consultingwerk.Util.LoggingStream.ILoggingStreamFactory interface, which receives its own free-form configuration JSON object, and can optionally keep the current stream active in parallel through a ParallelLoggingStream. The SmartComponent Library ships the factories NdjsonLoggingStreamFactory and FileLoggingStreamFactory, supporting the configuration keys fileName, append, uniqueFileName and context, with uniqueFileName producing one log file per session in a multi-session agent. When the section is absent or set to null, nothing changes and the default LogManagerLoggingStream stays in use, so no changes are required in customer code.

Framework code that still wrote log messages directly through LOG-MANAGER:WRITE-MESSAGE now uses the Consultingwerk.Util.LogManager facade, so its output also reaches a registered logging stream such as an NDJSON file. This affects the simple profiler service, the temp-table and table statistics monitors, the folded preprocessor trace, the test runner and the assemblies generator. Output that is already switched on by its own setting is written with LogManager:WriteUnfilteredMessage, so it does not disappear when the sub-system is not listed in the custom log entry types. A new static method LogManager:IsLoggingAvailable () forwards to the current logging stream and replaces the previous checks on the client log file name, so statistics are written even when the registered logging stream does not depend on one. The output of the default logging stream is unchanged, so no changes are required in customer code; applications that register their own logging stream now receive these messages as well.

The EA entry has been removed from the probing privatePath in assemblies.config and from the assemblies-generator configuration of the release branch, as that folder is only relevant for Consultingwerk's internal development environment. The assemblies.xml Generator no longer aborts with "Assemblies/EA was not found. (293)" in customer environments. No changes required in customer code.

The unit test for SessionHelper:ProVersionNumeric () determined its expected value from a hard-coded list of OpenEdge releases that ended at 13.0, so it failed on OpenEdge 13.1 with "Unable to determine expected result for OpenEdge release". The expected value is now derived from PROVERSION itself, with the known special case 10.2B still asserted explicitly, so no maintenance per release is required. The method under test was always correct. No changes required in customer code.

All conditional compilation that tested for OpenEdge 10 (and, in combination, for OpenEdge 11.0 to 11.6) was removed from the ABL code base: roughly 400 guard sites in over 340 files, including the products.i variants, the Business Entity Designer templates and the generated table model classes, which were regenerated so the dead code does not return. Since the SmartComponent Library is built for OpenEdge 12.2 and later, these guards always evaluated the same way, so the change is preprocessor-only and behaviour-neutral and was verified by comparing preprocess listings before and after. The framework rules documentation was updated accordingly. Customer code that still carries such guards keeps compiling unchanged; when generating new forms or user controls from the updated templates, the guard around the components collection is no longer emitted.

Two constructs in Consultingwerk/products.i were accepted by the OpenEdge preprocessor but rejected by other ABL parsers: a :U attribute inside a preprocessor expression and a built-in macro reference inside a disabled documentation comment. Both were removed, which is behaviour-neutral on OpenEdge and unblocks tooling such as Proparse and other parsers that process the SmartComponent Library sources. The same fix was applied to the copy of products.i in the Telemetry Toolkit. No changes required in customer code.

Since the SmartComponent Library supports OpenEdge 11.7 and later only, the compile switches in Consultingwerk/products.i that were tied to older releases (for example PacificAppServer, PacificWebSpeed, ProgressIDE and NoStaticsInHybrids) are now commented out with an explanation of why they are obsolete, and the framework code guarded by them was simplified to the branch that always applies. Switches that customer code may still reference - among them SERIALIZABLE, FrameworkSerializationType, NativeEnums, AblReflection and CommonComponentSpecification - stay defined; only their version guards were removed. Opt-in workarounds for defects of unsupported releases were removed as well, and the same decisions were applied to the copy of products.i in the Telemetry Toolkit. The change is preprocessor-only and behaviour-neutral, so no changes are required in customer code.

The conditional compilation for OpenEdge releases before 11.7 and the guards around compile switches that are always defined were removed from the Tests and UnitTests projects, completing the cleanup started in the main ABL project. Affected are mostly generated table model and Business Entity fixtures as well as form and user control constructors. Parser test input that exercises version or switch handling on purpose was left unchanged. This is a preprocessor-only, behaviour-neutral change to the internal test projects. No changes required in customer code.

The Business Task used by the SCL2589 unit test was moved into the UnitTests project, together with its parameter class, and now calculates the remaining credit from the existing Customer dataset model. The unused domain driven design sample below Tests/Consultingwerk/SmartComponentsDemo was removed completely, along with the three related Business Entity images in the Windows image resources. This only affects the internal test projects of the SmartComponent Library. No changes required in customer code.

The RepositoryBusinessTask now publishes DuplicateObjectInstance over REST, alongside the existing ReplaceObjectInstance and CreateObjectMasterFromInstance methods. The caller passes the source object instance and receives the ObjectInstanceGuid of the new instance back, so a client can position on the duplicate right away. This is an exposure of the existing ObjectInstanceDuplicator introduced with SCL-5393 — the duplication behaviour (unique instance name, copies of attribute values, positioning) is unchanged. The Angular based Object Master Designer can now offer the Duplicate Instance action on the Instances grid.

The file header comment of Consultingwerk.Windows.Controls.RichTextEditorControl now marks the class as deprecated and names the SmartRichTextEditorControl (SCL-5845), based on the Telerik RadRichTextEditor, as its replacement. The old control remains part of the product and is unchanged functionally, so existing forms continue to work without modification. The Visual Designer reference sample for UserControls in the layout rules documentation was switched to a non-deprecated control. New development should use the SmartRichTextEditorControl, which offers a public API for the content, font colours and image support.

When a request from the Business Entity Tester ran into a timeout, the CATCH block in sicatch.i threw the error object instead of the stop object, so the user saw the misleading messages "The CATCH and UNDO, THROW statements can only be used with a valid object ..." (18968) and "THROW statement failed" (14456) rather than the actual stop condition. The include file now throws the stop object, so the timeout surfaces with its real cause. No changes required in customer code.

Consultingwerk.OERA.ServiceInterface:ValidateBusinessEntityName returned the unknown value instead of FALSE when starting the Business Entity raised an error, because the CATCH block did not execute a RETURN. As a result callers written as "if not ValidateBusinessEntityName (...) then" did not reject an invalid or non-existing name, which affected SmartBusinessEntityBusinessEntity:ValidateData, the SmartBusinessEntityViewerControl and the design time validation of the SmartBusinessEntityAdapter. The method now returns FALSE in this case. No changes are required in customer code, but applications that deliberately relied on the unknown value in their own callers of ValidateBusinessEntityName or ServiceAdapter:ValidateEntityName should review that logic.

Consultingwerk.CommonUi.Components.TreeView.SerializableTreeNode and SerializableTreeRootNode have a new NodeIcon property that holds a Font Awesome class (for example fa-solid fa-user), following the ButtonIcon repository attribute of toolbar and ribbon buttons. A tree node provider can now decorate a root node or a child node with a font icon instead of an image file; the property is part of the serializable properties list, is available through additional constructor overloads and is serialized into the tree node payload as NodeIcon. The existing ImageUrl property keeps working unchanged, and the desktop tree ignores the font icon class because SetMainColumnImage only loads existing files. The ISmartTreeNodeProvider implementations shipped with the product and the demo now supply font icons for their nodes; the rendering of the icon in the Angular front end is delivered with SCLNG-1806.

A toolbar or ribbon button with launchMenuFunction that supplied its own label and images skipped the menu function and function group security check in SmartToolbarControllerRenderer:UpdateButtonProperties and stayed enabled for unauthorized users; an operator precedence issue in the same condition could also make a button with an empty launchMenuFunction pick up the caption, images and security state of an unrelated function. The check is now performed for every button with a function code, independent of whether the button definition provides its own label or images, while caption and images are still only filled in when they are missing. No changes required in customer code.

The method Consultingwerk.SmartFramework.Repository.RepositoryBusinessTask:GetTemplateProperties is now annotated as a POST REST method at /SmartFramework/Repository/GetTemplateProperties, so the web frontend can use it in the New-from-template wizard. The request carries the dsTemplates dataset with the selected template and the chosen replacement masters plus the template name as a Consultingwerk.CharacterHolder parameter; the response returns the dataset with the filled ttObjectProperty rows together with the list of data sources whose Business Entity could not be loaded. No schema change was required, as dsTemplates.xsd already describes ttObjectProperty. Developers who maintain their own annotation caches should regenerate RepositoryBusinessTask.annotations and delete restresources-cache.json so the new endpoint is registered at runtime.

ToolbarButtonEnableRule:Evaluate assigned the result of the enableRule expression directly to the tool, so a button that had been disabled by menu function security or toolbar item security became enabled again as soon as the rule evaluated to true - at the latest on the first row change of a linked data adapter. The effective state is now the rule result combined with the restriction state of the tool (IsToolRestricted), and the renderer registers menu function restrictions in the same restricted tools list as toolbar item security, so there is a single source of truth for all security restrictions of a tool. Unrestricted buttons continue to follow their rule. No changes required in customer code.

The Business Entities of the SmartFramework package now define relations (relation_<n> table properties of the BusinessEntityRelationsPlugin) between the temp-tables of related Business Entities, covering the Menu, Authentication and Authorization, Repository, System, Scheduler and Workflow packages. For every relation the Model Class Generator adds a navigation method to the generated TableModel class that returns the DatasetModel of the target Business Entity filtered by the foreign fields, so a developer can write code such as oModule:SmartModule:GetProduct() or oUser:SmartUser:GetUserGroups() instead of building the filter by hand. To-one relations are named Get<Entity> and to-many relations Get<Entities>; relations inside one ProDataset, polymorphic keys and Business Entities without generated model classes are deliberately not covered. Existing code is unaffected: only the .bedgm files and the generated *TableModel_Generated classes change.

Several code paths asserted the existence of the default settings file .restapplicationsettings (typically FileAssert:Exists followed by FileHelper:FindFile) even though the startup JSON allows a different file name or an inline JSON blob of application settings. Those explicit assertions have been removed; the file name remains the default and its existence is only verified in the constructor of the ConfigurationProvider class, while the configuration service is now obtained through the get-mandatory-service include. Applications that configure their settings under a different file name or inline now start without a spurious file-not-found error. No changes required in customer code.

With repository customization, a plain object name is no longer ambiguous: it always resolves to the base object master (empty CustomizationResultGuid), while a customized variant is addressed by its ObjectMasterGuid. ObjectMasterDataAccess:GetObjectMasterGuidFromObjectName, GetObjectMasterName, GetObjectMasterDescription and FetchRepositoryObject were changed accordingly, and the ISmartRepositoryService APIs that funnel through them benefit automatically. For compatibility with existing databases, a name that has no base object master but exactly one matching object master still resolves to that record and writes a log entry, so every lookup that succeeds today returns the same record; SmartRepositoryIntegrityCheckTask reports object masters that carry a customization result without a base. No changes required in customer code.