The subsequent aspects might serve as a checklist for new plug-ins, which features should be supported to have the best user experience possible. It does not include "obvious" aspects (e.g. we consider it obvious to use the built-in toolbox instead of re-inventing it on your own).

AutoDeclare

• Allows scanning ST code snippets for identifiers that are currently unknown, and presenting them to the user for automatic declaration (with a good proposal for the variable scope and data type).
• Existing declarations can be changed.
• The AutoDeclare dialog can also be invoked programmatically with the desired preselection, if required.
• See the _3S.CoDeSys.AutoDeclare namespace in AutoDeclare.dll for relevant interfaces

Bookmarks

• A global list of bookmark positions across all objects of a project
• The editor view is responsible for drawing the bookmark positions
• Persistence is handled by the framework
• The toggle and jumping commands are provided by the framework
• See the interfaces _3S.CoDeSys.Bookmarks.IBookmarkManager for accessing the bookmarks functionality, and _3S.CoDeSys.Bookmarks.IHasBookmarks to be implemented by your editor views, both declared in Bookmarks.dll.

Breakpoints

• Objects which are providing language model typically need to include breakpoint functionality in the corresponding editors (or should alternatively switch off breakpoints in the language model)
• The editor view is responsible for drawing the breakpoint, callstack, and watchpoint indicator symbols
• The commands for toggling breakpoints, running to the cursor position, showing the current statement, etc., are provided by the framework
• The breakpoint and callstack views, and the breakpoint settings dialog, are provided by the framework
• See the interface _3S.CoDeSys.Breakpoints.IBPManager interfaces in Breakpoints.dll.

Command line

• In order to evaluate command line parameters that have been passed to the CODESYS process, plug-ins can use the _3S.CoDeSys.Core.IEngine9.CommandLineManager property.
• If a plug-in needs to register its own command line option or switch, it can implement one of the sub-interfaces of _3S.CoDeSys.Core.Commands.ICommandLineDescription in Core.dll.

Edit commands

• The commands Undo, Redo, Cut, Copy, Paste, and Select All are globally provided by the framework
• When implementing the view interface, a corresponding calling interface must be implemented.
• For undo/redo, a ready-to-use implementation of an undo manager can be used: type GUID {80B00ACE-B8B1-454a-83F8-F96F29308EC6}, interface _3S.CoDeSys.Core.Objects.IUndoManager in Core.dll.

Find / Replace

• The commands Find, Replace, Find Next, and Find Previous are provided by the framework
• The corresponding UI views are provided by the framework
• The search algorithms including options like "Match case", "Match whole word", and regular expressions are provided by the framework
• If your plug-in needs to participate in this feature, your IObject implementation must implement _3S.CoDeSys.Core.Objects.IFindReplace, and your editor view can optionally implement _3S.CoDeSys.Core.Objects.IEditorBasedFindReplace, both in Core.dll.

High pixel densities

• Today, user interfaces are expected to look and feel well with high pixel density screen settings (120dpi and higher).
• Although this goal is sometimes cumbersome to achieve with the Windows Forms technology, the framework provides the _3S.CoDeSys.Core.Views.IDpiAdapter system instance which is helpful for scaling dynamic user interfaces correctly.

Input Assistant / IntelliSense

• Every UI widget which accepts an IEC symbol should implement the Input Assistant functionality. The user is then able to open a browse dialog which presents a categorized view of all declared symbols that are meaningful in that context.
• Your editor implementation should implement _3S.CoDeSys.InputAssistant.IInputAssistantTarget from InputAssistant.dll so that the Input Assistant command can make an appropriate callback into your code.
• You can also trigger the Input Assistant dialog programmatically by creating an instance of the _3S.CoDeSys.InputAssistant.IInputAssistantService interface (type GUID {d2f02edb-8505-46aa-a9fa-c12b12910f74}, InputAssistant.dll).
• IntelliSense is typically based on the same information as Input Assistant.
• For textual input, we recommend using our implementation of the IECTextEditor (type GUID {92EABB95-1C9A-4b26-9012-3D9E8A470BE5}, interface _3S.CoDeSys.IECTextEditor.IIECTextEditor in IECTextEditor.dll), or the SingleLineIECTextEditor (type GUID {CAA263F7-7301-49c4-8777-36D1300AFBB5}, interface _3S.CoDeSys.IECTextEditor.ISingleLineIECTextEditor in the same DLL). They have got convenient interfaces to set the desired categories as appropriate, for both Input Assistant and IntelliSense.

License agreements

• We provide an infrastructure to extract licensing information (copyrights, 3rd party information, etc.) from the plug-ins and display them in the About dialog, as required by government regulations.
• In order to participate, your plug-in is required to embed a plain-text resource and add a corresponding _3S.CoDeSys.Core.Components.LicenseAgreementResourceNameAttribute (from Core.dll) in the AssemblyInfo.cs file.

Licensing

• Automation Platform provides an infrastructure for license-protecting plug-ins and features within plug-ins.
• By default, the Wibu CodeMeter (TM) technology is used. We are also able to integrate other technologies, but this is not recommended as the integration would not be as deep and seamless.
• Both hardware protection (USB dongle) and software protection are possible.

Online help

• Users expect online help topics for extended functionality. We provide an infrastructure for dynamically adding online help contents to the existing installation.
• Users also expect to have context-sensitive help by pressing the F1 key. There are built-in mechanisms for detecting the context automatically and browsing to the appropriate page.
• See the interfaces and attributes in the _3S.CoDeSys.Core.OnlineHelp namespace in Core.dll.

Printing

• Editor implementations should also implement either the _3S.CoDeSys.Core.Printing.IPrintable or _3S.CoDeSys.Core.Printing.IPrintableEx interface from Core.dll.
• Doing this, your contents will be printable using the File Print or Project Document command.

Project archive

• The Project archive functionality packs together the project with all the required dependencies (libraries, device descriptions, etc.).
• A user extracting a project archive will gain all those dependencies so that the project will immediately work without having to make further installations to the system.
• If a plug-in deals with external data that are not part of the project itself, but should be part of the project archive, it should contain an implementation of the _3S.CoDeSys.ProjectArchive.IProjectArchiveCategory interface (in ProjectArchive.dll).

Project compare

• Project compare is a global feature which allows the user to show the diffs between two projects, and to visualize the differences for each object in those two projects.
• In conjunction with the SVN Integration, we also offer a three-way merge.
• By default, two objects are compared byte-wise using their serialized representation. The differences are visualized by a generic diff viewer displaying their serialized object graphs.
• It is much more convenient for the user to have a semantic comparison and a dedicated graphical diff viewer because the serialized data streams might include data that are not meaningful at the UI level.
• See the interfaces of the _3S.CoDeSys.ProjectCompare namespace in ProjectCompare.dll.

Refactoring

• Automation Platform provides the capability to rename IEC symbols and signatures (input and outputs) interactively for the entire project. In contrast to global find/replace, refactoring considers the cross reference list of a symbol and leaves other symbols with the name intact.
• For a good user experience, it is necessary that plug-ins support refactoring, i.e. for each renaming of a symbol, a plug-in might need to make adaptions to its data by callback.
• Also, it might be appropriate for an editor to trigger a refactoring operation upon user action.
• See the interfaces of the _3S.CoDeSys.Refactoring namespace in Refactoring.dll.

Scripting

• The programming system contains a Python script interpreter with a set up publicly available functions. Users can automate many things that way.
• Plug-ins which also require some of their functionality to be scriptable are able to implement the _3S.CoDeSys.ScriptEngine.IScriptDriver interface from ScriptEngine.dll.

Temporary files

• The _3S.CoDeSys.Core.IEngine8.TemporaryFileService property provides access to a global temporary file manager.
• It takes care that the 64k file limit is only valid for your own plug-in and not influenced by other plug-ins
• In the case of a CODESYS crash, the temporary files managed by this service will be automatically cleaned up during the next start.

User management

• The programming system contains a role-based user and rights management. The execution of commands and access to database objects can thus be restricted to authorized users only.
• Plug-ins are able to introduce their own permissions by implementing the _3S.CoDeSys.UserManagement.IPermissionCheckerFactory interface in UserManagement.dll.

Version compatibility

• CODESYS provides functionality to automatically update various version-oriented dependencies of a project while loading a project. E.g. a new compiler version or newer versions of certain libraries or visualization profiles might be available. The user can select whether and which aspects he wants to update.
• Plug-ins can include their own aspects into that mechanism by implementing the _3S.CoDeSys.VersionCompatibilityManager.IVersionSelectionControlProvider interface in VersionCompatibilityManager.dll.