2021-11-06 07:23 PM
In example projects created from within TouchGFX Designer and imported into a STM32CubeIDE workspace, the user gui folder only contains .cpp files. The example project itself (represented by the presence .project and .cproject files) is located in the STM32CubeIDE folder rather than the TouchGFX folder. And the gui folder, shown below, is an empty folder located in STMCubeIDE/Application/User, which is “populated�? by adding file links to the .project file pointing to the gui's .cpp files when code is generated in TouchGFX designer.
Access to associated .hpp files is possible by double clicking on their names in the editor, but they are excluded from Eclipse global searches since they do not explicitly appear in folders of the Eclipse project. For example, a new ScreenIDs.hpp file was created and added TouchGFX/gui/src/common folder.
As is the case with existing .hpp files, placement in this location enables the file to be accessed by .cpp files in the project without compilation errors. But again, the .hpp files are not directly accessible in the IDE, and are excluded from global file searches. For example, consider the term SCREEN_MAIN, defined in ScreenIds.hpp:
A global file search for the term SCREEN_MAIN
returns results only for the .cpp files linked in the gui folder, but not for ScreenIds.h:
This means that Eclipse's global search, one of the most powerful tools for browsing a project when one is not familiar with the project's organization (as one might do when studying the TouchGFX examples) is greatly reduced. Moreover, it means that global replacement of a specific string or term is made impossible, and must be done “by hand�? on individual .hpp files, once they are located by some means other than global search.
Noticing the mechanism whereby the .cpp file links were created, I thought to add a similar link folder to the user/gui folder and painstakingly placed links, one at a time, to the hpp files inside. Voila, this enabled the .hpp files to be found in global searches.
However, when the project's .touchgfx files is edited and code generated in TouchGFX Designer, and then the IDE is refreshed, the linked files disappear from the inc and src folders (though they are still present on the system).
So, finally, this brings me to my question: how, indeed, is one to enable searches for .hpp file contents within this rather convoluted setup? And is there some suggested means whereby one can add new .cpp and .hpp files to a project from within the IDE, rather than having to do so in the Windows Explorer (or whatever OS is in use)? I may be missing something obvious, but I've spent endless hours trying to find a way to solve this issue.
I apologize for this agonizingly long post, but agonizing is also a good description of my experience of trying to solve this issue.
2021-11-06 07:38 PM
There was a post about this a few days ago.
You can use Navigate -> Open Element... (Ctrl+Shift+T) in a similar fashion to File Search, except that it will search included files. It should catch usages of SCREEN_MAIN in your example.
2021-11-07 03:21 PM
Thanks, TDK, for the suggestion. Navigate -> Open Element does indeed find the .hpp file where SCREEN_MAIN is defined. But it does not locate any other files where the term is used or referenced. And, even if it did, there is no provision for replacing the term globally as is the case in Eclipse's file search.
So, one must use an external tool such as Notepad++ to search the project globally and find all usages. In my view, having to use an external tool to perform an action that Eclipse does better is not an acceptable substitute.
Locating all references to such objects is an essential requirement when, for example, one must complete the process of renaming a screen (an activity often necessary as requirements change).
In TouchGFX Designer 4.17.0, when a screen is renamed, the application simply generates a new, empty set of MVP files (.cpp, .hpp) and leaves the source files of the old ones in place as orphans. So one must copy the contents of the old MVP files to the new, making sure that every single reference to the old names (including file references) is modified to reference the new screen name. Then, in order to avoid build errors, one must ensure that all the old files are deleted from the project, again by hand in the OS because the STM32CubeIDE project does explicitly show them. In a complex project, accurate global searches are a must.
2021-11-07 03:50 PM
I've also discovered that, when .hpp folders and files are not explicitly shown in a project's IDE, as is the case in projects generated in TouchGFX Designer and targeted to specific hardware (a dev kit in my case), Eclipse's auto-completion and Go To Reference (F3) capabilities are sabotaged, and unable to locate items that are clearly present in associated .hpp files.
I tried to use the same strategy as TouchGFX, creating links to the .hpp files individually, only to find them removed when code is regenerated and compiled. Any suggestion as to how I might do so without removal of my efforts, however tedious it might be, would at least preserve and enable these standard Eclipse features.