ttRESOURCESTRING can not be located as context

[Christian Budde]

The concept of context allows to locate sections very effectively. However the "resourcestring" sections seems to be left out so far. For example the following code does not return a context:

   UnitContext := CompiledProject.SourceContextMap.FindContext(1, 1, SourceUnitName);
   ImplementationContext := Context.FindContextByToken(ttIMPLEMENTATION);
   Context := ImplementationContext.FindContextByToken(ttRESOURCESTRING);

At least not for the units I have tested so far.

Or what other means are there to locate the resource strings?

[Eric Grange]

For localization, there are several approaches supported.

For resourcestrings, you have a ResourceStringList property in TdwsMainProgram that contains a list of all resource strings, that can be used to obtain a list of all resourcestrings.

The other approach is to enumerate the subexpressions, using RecursiveEnumerateSubExprs on the main program and source functions, and then collect as you go everything that needs localization (from TResourceStringExpr to TFuncExprBase that are calls to the '_' function, or any other specific functions that could require localization, such as the date time formats f.i.). This approach can also be used to build a list of all strings, which can be of use to figure out if there are strings in the source that are not going through localization.

Finally, for translation at runtime, all localization mechanims go through the execution object's LocalizeString/LocalizeSymbol methods, and by default program executions pipe that through their Localizer property (which is an IdwsLocalizer)

[Christian Budde]

Yes, I'm aware of all these and I am using all these already. However, I want to write a refactoring tool that converts the string under the cursor to a resource string (similar to CTRL + Shift + L in Delphi, but more sophisticated in terms of integration into the entire localisation concept). To do so, it must copy the string constant (under the cursor) and replace it with a resourcestring name, which then needs to be synthesized and added to the resourcestring section.

However, at the moment there are no simple ways to locate the existing 'resourcestring' section, which means that for every string a new resource string section is created.

Of course I can also locate the TResourceStringExpr to find the latest position where the strings are defined and than use that position as place where to add the string, but that's not very elegant.

[Eric Grange]

Added resourcestring blocks to context map + test (Fixed Issue #101)

→ <<cset cc408bc3bdcd>>