Multi-Language Add-In for Visual Studio

Version 4.65

Internal changes

• New grid component
• ADO.NET

Changes to the functionality

• Making changes to resource files immediately
• Making changes to the function ml_UpdateControls immediately

User interface changes

• Handling hidden items
• Column mode

Installation changes

• Global database using SQL Server

New grid component

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.

ADO.NET

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.

Making changes to resource files immediately

From the very first version of the Multi-Language Add-In for VB6, the concept has been to:

• enter translations
• add runtime support (store resources)

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.

Making changes to the function ml_UpdateControls immediately

This is very similar to the change described above.

If you select either of the options

• Runtime language switching
• Alternative runtime support

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.

Handling hidden items

In the original VB6 Add-In, I added a mechanism to hide items in the source code grid using the tree/grid functionality. Where one or more lines were hidden, an additional node was added, and the hidden lines were made into child nodes of this additional node. This node would usually be collapsed, thus hiding the lines.

The VB6 Add-In (still) has no support for hiding items in the controls grid.

In the Visual Studio .NET Add-In, I added support for hiding nodes to the controls grid, but I did not adopt the same mechanism. In this case, I figured that there would be too many of the additional nodes, mostly hiding only one or two properties.

(This was probably before I added an option to ignore empty strings. If you deselect this option, you will probably see many, many more properties which you would want to hide.)

As a result of this design decision, the mechanism for hiding items in the two grids was highly inconsistent. In addition, the mechanism for hiding and showing nodes was not really intuitive.

I have tidied this up in version 4.65. I have abandoned the idea of using additional nodes to hide items in the source code. Hidden items are handled in an identical manner in the two grids, simply by hiding the items.

The mask button on the toolbar is now a two state button.

When it is pressed, hidden items are hidden. When it is not pressed, all items are visible. When you initially hide an item, it remains visible until you toggle the state using the mask button.

The DataGridView actually supports hiding rows (i.e. setting Visible=False), so this seemed the obvious mechanism to use. There is a minor problem in the TreeGridView with the + icon to expand a node. It shows a + icon, even if all child items are actually hidden!