CtrlppCheck: support #uses statement

[ghost]

Is your feature request related to a problem? Please describe. CTRL statement #uses "CtrlLibOrExtension" is not recognized. e.g. including a standard Ctrl library like

//--------------------------------------------------------------------------------
// used libraries (#uses)
#uses "CtrlADO"
...

results in:

Describe the solution you'd like

uses should be correctly resolved for all standard and project specific Ctrl libraries.

Additional context Also mind optional file extension and valid ctl-files consisting only of #uses declarations.

[mPokornyETM]

This will be tricky, but I have some idea. What about to crate for each dll an extra ctrl_.xml file. In that case it shall be easy to extend ctrlppcheck to rad this information on demand. Because the project, subprojects and winccoa directora are known (added via -I... option). In this case we shall somehov provide this files. I will check if it is possible to generate it automatically, because no body will create all of them manually.

[jcpinto54]

Hello there, Was there any development on this issue? I am interested in this feature. Cheers

[mPokornyETM]

Hello there, Was there any development on this issue? I am interested in this feature. Cheers

I try it for very long time. My first try was to adap the cpp code. Original code works with incluide (cpp style) and I got it to handle the parser also with #uses. But it is extrem slowly. In many cyses you will load libs like aes.ctl (with over then 20K lines). This is bi overload. Therefore I stop the development.

My last idea is very easy and I think it will be enough for most usage of ctrlppcheck. You can load every .ctl library and convert it into xml file. This contains many tags. My idea is to convert this xml file into .xml library. In that case you need to modify the cpp code, that it will load .xml library instead #uses. This kind of converter might be used also by ETM to provide all the .xml lib files. This will works also for .ctc file. The end user can not see the content of .ctc file. But the ctrlppcheck might read the .xml library to know, how to handle with the functions located in .ctc

So in Short. We will provide for every .ctl one .xml library file.

• faster solution
• performant (loading .xml is much faster, then parsing the .ctl files)
• you need space for all the .xml files
• you need to convert .ctl on every change

[jcpinto54]

Thanks for the answer. So, you are proposing that I do this conversion myself, or is this something you are planning to work on?

[mPokornyETM]

Thanks for the answer. So, you are proposing that I do this conversion myself, or is this something you are planning to work on?

or I use somethink like that in my private repo ;-) I did few modification in the vscode plugin, and I make the converting in the typescript. TThe question is, if we want do it in this way or modify the cpp code.

[jumoog]

Isn't it easier to use the real WinCC OA CTRL parser/interpreter as Language Server Protocol (LSP) Server for VS Code?

[mPokornyETM]

Isn't it easier to use the real WinCC OA CTRL parser/interpreter as Language Server Protocol (LSP) Server for VS Code?

no, stop, nope. (just kidding) but this is other one discussion. As I say, I did it in my private repo and that was the faster solution without modification in the product. But yes for longer time, it will be better to make some LSP to allow also debugging, testing ... . I know, there was few discussions, but I have no idea what is the current status qou.

[mPokornyETM]

but this tool hase also few extras. it can be used without WinCC OA, and you can provide static analysis on your build servers. Results are supported by CI / CD tools, also in the sonarqube. Ok let me drop my power cable and try to make the "conertor" in the ctrl code ;-)