Here are some steps to see the issue:

1. Create a graph prototype with name containing a functional item macro.
2. Generate LLD graph.
3. Change graph prototype name by adding a different functional item macro.
4. Generate another graph. (Repeat steps 3 and 4 to produce more LLD graphs if necessary. It may also be required to have repeated or similar macro names)
5. Create a screen with element graph prototype and observe the 2 (or more) generated LLD graphs. It may look ok at first, but ... the order for generated items may not be alphabetical.

For graph name resolving and ordering we use graph.get method with option expandData. After API call we then get a number of graphs and try to sort them by expanded names alphabetically. The problem is that graph names are not resolved there, but yet they appear when graph is drawn.

Graph drawing iterates each graph and checks for functional item macros in graph name and the resolves them. But it cannot be done if we have a list of graphs.

The problem is inside resolveGraphsFunctionalItemMacros(). Previously we had only one graph, but now we have more graphs, thus we get more macros matches in that function. Actually macros match list contains all macro matches, but since before we only had one graph, we used array reset() on matched macros list. But in screen LLD graphs we have more.

And futher more resolving graph names in CGraphDraw::drawHeader() is another "to do".