The document "control" does not exist in the newer framework. There is still a document class, but it is not a user control. The SyntaxEditor.Document property defines the current document, and it is initialized with a default value. This property expects a class that implements the IEditorDocument interface, and most users will utilize our EditorDocument class. Even so, the SyntaxEditor.Document property is pre-populated with a document instance, so you shouldn't need to assign it a new document unless you are wanting to use the document swapping feature.
I should note that migrating from .NET 4.0 to .NET 4.8 should not require moving to new versions of our controls since .NET Framework is backwards compatible. You might find it easier to first move your project to .NET 4.8 with the existing controls and ensure everything is working as expected before attempting to upgrade the controls. That will help isolate if any compiler errors are related to the newer .NET Framework target or the newer controls.
If you do want to update to the latest controls from a version that old, you will not be able to do so using existing designer code. Any code serialized by the Visual Studio designer for that version is not compatible with the newer API's. An approach you might follow could be:
- Ensure your solution compiles with .NET 4.0 and backup all your files.
- Change your project targets to .NET 4.8.x and ensure your solution still compiles.
- Make a note of which projects are currently using the older Actipro assemblies and which ones.
- Open the Visual Studio designer for any Forms or UserControls that use Actipro controls
- Make a note of which ones used which controls.
- Make a note of the control names.
- Make a note of any non-default property values and events that are being monitored.
- Delete the control instances from the designer.
- Deleting the controls will typically result in syntax errors for any references to those controls. Comment out any code that referenced Actipro controls and leave a "TODO:" comment that the code needs to be restored. Repeat this until the solution compiles again.
- Remove all references to the older assemblies from all projects.
- Refer to the Converting to v12.1 topic for a list of which newer assemblies map to the older assemblies and add references to those assemblies. You should need:
- ActiproSoftware.Shared.WinForms.dll
- ActiproSoftware.Text.WinForms.dll
- ActiproSoftware.Text.LLParser.WinForms.dll
- ActiproSoftware.Text.Addons.DotNet.WinForms.dll
- ActiproSoftware.SyntaxEditor.WinForms.dll
- ActiproSoftware.SyntaxEditor.Addons.DotNet.WinForms.dll
- Refer to the Converting to v21.1 topic for a list of namespace changes that were made. Using find-and-replace functionality of Visual Studio, you should be able update all your using statements to the new namespaces by following the list in the topic. The replacements should be performed in the order listed.
- At this point you may still have compiler errors.
- If any using statements are giving errors, remove the statement and address any unresolved types one-by-one. If Visual Studio finds an unresolved type, it will suggest the using statements you need.
- For any other errors, comment out that code and leave a "TODO:" comment to come back to it.
- Repeat this process until all errors have been resolved or commented out.
- Open the Visual Studio designer for any Forms or UserControls where Actipro controls were deleted and add the new control to the designer.
- Give the new controls the same name as the old controls.
- Attempt to restore any non-default property values.
- Attempt to restore any event handlers that were not commented out.
- It is recommended to ensure the solution will still compile after each individual Form or UserControl is updated.
- Using one Form or UserControl at a time, begin to uncomment the previously commented code that had errors until all functionality is restored. For commented out event handlers that need to be restored, it may be better to use the Visual Studio designer to add the event handler and then copy the old method body into the new method since some of the EventArgs implementations may have changed.
- Search the rest of your solution for any TODO: comments and either restore or delete the related code until the solution is fully migrated.
For any code that has errors, you will have to try to resolve the error by looking at our documentation or extensive set of samples in the Sample Browser application. Since you are attempting to migrate from a very old version of the controls, you will likely have several errors to address. Our Sample Browser application has many examples of using SyntaxEditor and most of them are broken out into individual feature concepts. If you are having trouble with bookmarks, for example, you should look at the Bookmarks sample and compare how that sample works and adjust your code accordingly.
The biggest migration hurdle involves any custom syntax languages that might have been developed. Since it appears you are using the pre-defined .NET Add-on, hopefully that does not apply to you.
Please reach out with any individual issues you may encounter during your migration and we'll do our best to point you in the right direction.