Header file paths not showing

[sth]

When I attempt to add a Framework to my project, a wizard pops up to ask for a list of header files to go with this framework for parsing the functions. Here are two suggestions and a bug.

This list should already be prepopulated with the headers from that framework, which is the obvious starting point.

The system should also know to search /usr/include for missing header files with is also obvious.

But the real bug, is that when I manually add a path using the [...] browsing button (why is this icon different than the std LV path icon?) The file path does not show up in the list. When I ask for a second new path then the path for the first file shows up. When I set the path for the second header file it stays blank until the third path is added. The path should be populated as soon as the "choose" button is pushed on the path browsing dialog.

LV 8.5
Mac OS X 10.4.10, PPC

[superjing]

This is a known UI bug. You can click away from the path dialog (somewhere else on the window) and the path appears.
As for header files included in the input header file, the tool cannot list these paths because in most cases they are relative paths. The tool can automatically search and parse those header files according to the input paths.

[sth]

---

@superjing wrote:
This is a known UI bug.

---

Do you have a CAR for that? Also it is not true that clicking anwhere will get the path to appear. There is only a small area above the window list that will do it.

Well first of all the system should easily be able to parse a relative path.

Second, the header files are in a fixed relationship to the Framwork. It is XXX.framework/Headers and this should auto populate. Also /usr/include and /usr/include/sys should always be included as well.

[superjing]

There is a CAR for the UI problem.
XXX.framework/Headers only works on Mac. It is a good suggestion that it should list some default included path.
Thank you for the feedback.

[sth]

Please include the CAR # so that it will get tracked and checked. I think it is usually in a standard form so issues can be tracked when they are mentioned. Actually JLV already tagged this thread in the monthly bug list, I was waiting a bit for the CAR number but he is quick!

Since I am talking about Frameworks it is a Mac OS X concept and however the windows folks do it is a different problem.

-Scott

[superjing]

The CAR for the UI bug is CAR 4CJ8MM5M.
And I created a CAR 4DD108GI for searching in XXX.framework/Headers.

[sth]

Excellent, thanks

[Chris_Cilino]

For our internal purposes...

This was reported to R&D (# 4CJ8MM5M) for further investigation.

This was reported to R&D (# 4DD108GI) for further investigation.

Chris C