Feature Request: uVision
When I am writing an application I like to have the header files in a project group so that they are easily accessible. Right clicking a group, selecting "Add New Item to Group" and creating a .c file automatically adds it to that group and I think it would be convenient to have the same functionality for a .h file. In fact all the other file types are automatically added to the selected group its just .h files that are different.
I know that the .h file is accessible once it is included in a .c file by expanding the tree in the project view. I do not find it convenient however when I have to search through about 50 .h files associated to that .c file, the majority of which are part of some 3rd party library (e.g. RTOS and STM Hal libraries), to find the one I want.
Hello Stephen,
We can already add individual header files into a folder from the Project Window, just like a source file. Just search for existing header files, instead of existing C files in the Windows file search. When an already-included header file is added directly into the Project Window, it does not impact the build, at all. I think it's ignored, and only useful for the editor's convenience.
The trick is the tools don't know which header files are important, until after the first compile/link, when the include paths are searched and the header file dependencies are resolved. We'd still be looking at lots of header files with any automated process that's trying to be thorough and wants to display the dependencies.
Thanks, Zack
Hi Zack,
I'm sorry I don't think I made it clear what it is that I would like to see added to uVision.
It is possible to right click on a group and select "Add New Item to Group". Currently using this to create a .h file does not add that file to group. Instead you have to create the header file separately then add the existing file to the group.
I thought it would be more convenient to allow header files to be added to a group like every other file type available when clicking "Add New Item to Group". There is no need for the tools to decide if the file is important because the user is specifically asking that the file is automatically added to the group after creation.
I am assuming that header files are treated differently on purpose and not logging the difference as a bug.
I understand now, and have reproduced the issue.
I have created an online support case. Feel free to login at silver.arm.com/support using your email as username to view more information, and status updates.
I think this issue can be considered a defect. IDE offers header file as a selection in the dialog, but the IDE doesn't completely follow through. It creates the file, but fails to add it into the Project window. Workaround is that the user does an extra step, "Add Existing File..." to really add in the header file.
>>I am assuming that header files are treated differently on purpose and not logging the difference as a bug.
Yes, like there are Include Paths that define search order, where they pull from can be context sensitive, and there are a lot of circular references. There is a lot of history here, and jamming the .H files into the project tree is highly undesirable.
Keil provides dependency trees and most of us are satisfied with that, and try to avoid unmanageably awkward project structures.
>> try to avoid unmanageably awkward project structures.
Wanting easy access to header files is not indicative of awkward project structures. I have worked on other peoples projects in the past where I have had to edit .h files and to do so I had to first work out which c files included that header file, find something that was defined in that header file and use the "Go To Definition" functionality or open the file directly.
>> Keil provides dependency trees
This is fine for small projects but I am trailing an RTOS and the ST HAL Libraries. By default around 40 .h files are shown in the tree for main.c. Accessing custom header files this way is just not practical or convenient.
>> there are Include Paths that define search order, where they pull from can be context sensitive, and there are a lot of circular references
I am not expecting adding a file in to a project group to affect the include paths in any way, just like including c files to groups does not affect where they are stored locally. I just want convenient access to files I am working on.
Thanks for creating the case for me Zack.
This issue will be resolved in MDKv5.22 (uVision 5.21.1.55) or later, to allow newly-created header files to be viewed in the same source group, in the Project pane. This removes the need to view all of a source file's header file dependencies in order to see one file.
I think it's both awkward and efficient...
The main thing to remember is that adding a header file to a source group this way does not affect the build tool's ability to find the header file. The header file may still require its location: -location is next to a source file (default folder path in dialog often finds header file this way) -include path supplied to the compiler -source file's include line contains the path
MDKv5.22 should be released soon, and any later version of uVision will also contain this fix.
*(default folder path in dialog often ***allows*** header file to be found this way)