Previous versions of the Add-In, including the version for VB6, use a tree/grid component called SftTree/OCX from softel vdm. The tree functionality is used in the controls and source code grids. The control is also used as a simple grid in many dialogs.
For a long time, I have thought that it would be better to switch to a pure .NET grid component. If possible, I wanted to use a standard control, or one available in source code. The problem with licensed controls it that is that you can't easily share the source code with another developer. It would also be an irritation if I ever decided to sell the source code. Otherwise, I am quite happy to pay for a commercially available control (as I hope others are prepared to pay for this Add-In).
In all dialogs with a simple grid, I have replaced SftTree with the standard DataGridView.
In the two main grids (controls and source code) and in one or two other places, I have replaced SftTree with the TreeGridView. This is an extension of the DataGridView, created by Mike Rideout at Microsoft, although it is not a supported Microsoft Product.
I have in fact converted the TreeGridView source code from C# to VB.NET (mostly with an online tool) and integrated it directly into the Add-In source code. Since then, I have made some minor changes and extensions to the component. I would be happy to share my modified source code for the TreeGridView, if anybody is interested.
Although this is a minor change from a user's point of view, it has been a massive internal change to the Add-In.
Finally, in fairness to softel vdm, I must say that I always liked working with SftTree and found the quality of the software and the support first rate.
Another hang over from the VB6 Add-In is, that some parts of the Add-In still used ADO and not ADO.NET.
Access to the project database was restructured and converted to ADO.NET in version 4.54 of the Add-In. Access to the global database still used ADO. In addition, some database update functions used the ADOX component.
I have now converted all database access to ADO.NET.
There is one remaining reference to the ADO library, required for the datalink dialog (MSDASC.DataLinks) which returns an ADO connection object. The datalink dialog is used for the global database connection. I don't know of any .NET way to show this dialog.
Again, although this is no real change at all from a user's point of view, it has been a major internal change.
From the very first version of the Multi-Language Add-In for VB6, the concept has been to:
The add runtime support step has to be repeated after modifying translations.
This is non intuitive for a lot of users and I have decided to change it.
In version 4.65, modified texts are stored immediately to the resource files. If this works, it means that you no longer heed to use the add runtime support command.
This will only be a minor improvement for existing users of the Add-In. The real target group for this change are people who download a trial version, find that it doesn't work properly and then give up. For new users, this could be the difference between a product that just works and that just doesn't work.
At present, I am still testing this feature.
This is very similar to the change described above.
If you select either of the options
the Add-In generates a method ml_UpdateControls in all Forms and UserControls.
If you then select additional properties for translation, or deselect previously selected properties, then this function is out of date and has to be updated.
In version 4.65, the Add-In will make this change immediately.