This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How are .h files treated in a uVision2 project?

Hello,

For me, it's still not clear why the include files (.h) are treated in such a cumbersome way in the uVision2 Project philosophy. When you have a project and you create a group -for instance- called 'Header files' then you have to specify that those files are Text documents to be able to add it to your project. The file types in the file open dialog box do not contain something separate for .h files, whereas this is the case for e.g. .c, .a* and .src files. Could someone explain me why is this?
Wouldn't it be more logic, user-friendly and convenient if the .h-files would be treated the same way as .c- or .a51-files?

Rgds,

Geert

Parents
  • I arrived at the same solution as Hans-Bernhard. While I can put access to my important header files only a click away in this manner, it forces me to work around a limitation in the tools. Let's face it, people edit their header files occasionally, to change things, so we don't have to touch the source code. The uVision solution of having to open the C file, scroll to the "#include" reference for the header you want to work on, and then click on it, is tedious.

    Instead of the interface working like I do, I have to work like it does. It's a computer, for goodness sake. Perhaps a read of Alan Cooper's "The Inmates Are Running The Asylum" is in order. The fact that the ".h" extension was left out of the "Add files" dialog is almost spiteful: "You don't need to add header files so we'll make it difficult for you." I can't imagine the need to be so rigid here.

    The code generated by the Keil tools is first rate. It's the development environment that has some rough edges.

Reply
  • I arrived at the same solution as Hans-Bernhard. While I can put access to my important header files only a click away in this manner, it forces me to work around a limitation in the tools. Let's face it, people edit their header files occasionally, to change things, so we don't have to touch the source code. The uVision solution of having to open the C file, scroll to the "#include" reference for the header you want to work on, and then click on it, is tedious.

    Instead of the interface working like I do, I have to work like it does. It's a computer, for goodness sake. Perhaps a read of Alan Cooper's "The Inmates Are Running The Asylum" is in order. The fact that the ".h" extension was left out of the "Add files" dialog is almost spiteful: "You don't need to add header files so we'll make it difficult for you." I can't imagine the need to be so rigid here.

    The code generated by the Keil tools is first rate. It's the development environment that has some rough edges.

Children

  • Note that all the headers used by a source file also appear in the project list, nested under that source file. Click the + box, and then double-click the .h file just as you'd double-click a .c file to open it.

    It's still not one global list of all headers, but you need not open up the .c file to open up a header file.

    My pet peeve in this area is that the uVision file add files dialog lets you choose "*.a" files, while the default extension for the A51 assembler is, well, .a51. uVision doesn't automatically recognize its own assember extension. C'est le code.

  • You'll like a new feature of the latest version, then. It has a list of all files #include'd by any compiled file as part of the project "Files" window. You click on the '+' to open up the sub-nodes, and select your include file from the list.

    OTOH, I can't quite follow you why the existing method is "tedious". It's a few more mouse clicks than to add a .h file to a project than a .c file --- so what?

  • ""*.a" files, while the default extension for the A51 assembler is, well, .a51. uVision doesn't automatically recognize its own assember extension."

    I thought the default was *.a* - which does recognise .a51??!!