dwp090598
asked on
compile error
I am writing a code resource that needs to uses System 8.5 Icon Services, the code resource worked fine until I called a procedure declared in the the Icons.h file (which I included in my header file) I get a link error: function has no prototype, yet the procedure is declared in the file Icons.h, am I missing a file? I tried to add the IconServicesLib file but this is a PowerPc Lib and I am writing a 68k code resource. Any suggestions?
ASKER
Libraries: MacOS.lib
Procedure: IconSuiteToIconFamily()
and IconFamilyHandle
Worked fine before adding these calls and identifiers, I also added Icons.h which does declare these procedures. Added IconServicesLib and got an error.
Procedure: IconSuiteToIconFamily()
and IconFamilyHandle
Worked fine before adding these calls and identifiers, I also added Icons.h which does declare these procedures. Added IconServicesLib and got an error.
I use Code Warrior Pro 4 and looked in Icons.h and could not find your two routine prototypes. Where did you get your copy of Icons.h? If you got it from the web or oither than what c ame with CodeWarrior, are you sure it is being included and not the one in the CodeWarrior MacOS Support folder? To be sure, make a copy of the Icons.h file that has your two routines in it and give it a new name and include that. The full lib search tool in CodeWarrior does not show either of these two routines so I assume they are new to MacOS 8.5 and you must have a very, very new copy of icons.h?
ASKER
These new IconFamily routines are included in the Interfaces-Libraries.3.2.s
Do you use pre-compiled headers?
If so, it might be possible you pch uses the old Icons.h, in which case you'll have to re-create your PCH using Universal Headers 3.2...
Good luck
If so, it might be possible you pch uses the old Icons.h, in which case you'll have to re-create your PCH using Universal Headers 3.2...
Good luck
ASKER
I don't think that is the answer because my 68k application and PPC application that I created make calls to Icons.h, I am only having problems with the 68k code resource. But I am willing to try to re-create my pch, but I don't know how.
You can recompile pch by opening the project MacHeaders.mcp that lives in ...":MacOS Support:MacHeaders:" and building it. However, I don't think that is your problem. I suspect the 68K library doesn't yet exist for these routines.
ASKER
You can recompile pch by opening the project MacHeaders.mcp that lives in ...":MacOS Support:MacHeaders:" and building it. However, I don't think that is your problem. I suspect the 68K library doesn't yet exist for these routines.
ASKER
If that were true why would my 68k application compile and run fine while calling the same IconSuiteToIconFamily()? I am only having problems with the code resource - can I email you the project and files?
email me at:
webconnect@argo.net
email me at:
webconnect@argo.net
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In looking at dwp's code for the 68K app (which compiled) and the 68K INIT (which did not), the following facts were apparent:
- dwp's projects included both the default CWPro4 headers in the include path, as well as the Interfaces&Libraries3.2 headers
- the prefix file for the app was ansi_prefix.mac.h, while the prefix file for the INIT was MacHeaders.h.
Therefore, when compiling the app, the compiler did not find Icons.h in the prefix file, and went to Interfaces&Libraries3.2, found the declarations for the routines, and compiled correctly.
When compiling the INIT, the compiler found the old Icons.h in the prefix file, never found the definition for IconFamilyHandle, and failed. It wasn't a link error, it was a compile error.
Placing the new Icons.h file in the Metrowerks MacOS Support directory (and recompiling the precompiled headers, although dwp wasn't using them) fixed the problem.
- dwp's projects included both the default CWPro4 headers in the include path, as well as the Interfaces&Libraries3.2 headers
- the prefix file for the app was ansi_prefix.mac.h, while the prefix file for the INIT was MacHeaders.h.
Therefore, when compiling the app, the compiler did not find Icons.h in the prefix file, and went to Interfaces&Libraries3.2, found the declarations for the routines, and compiled correctly.
When compiling the INIT, the compiler found the old Icons.h in the prefix file, never found the definition for IconFamilyHandle, and failed. It wasn't a link error, it was a compile error.
Placing the new Icons.h file in the Metrowerks MacOS Support directory (and recompiling the precompiled headers, although dwp wasn't using them) fixed the problem.
ASKER
The ExpertsExchange system is incorrectly showing a comment from dwp as the proposed answer to this question. dwp and I exchanged files via private email, including his 68K project that worked and the INIT which did not. The correct answer should be as follows:
If you compare the preferences between the 68K app and the init, you can see why the former worked and the latter did not. The 68K app was using a prefix file of ansi_prefix.mac.h, while the init was using MacHeaders.h. Neither was actually using precompiled headers. For the init, MacHeaders.h includes <Icons.h> which in dwp's environment was the _old_ Icons.h. He did have the new Icons.h included in the path, but it found the old one first. For the app, ansi_prefix.mac.h does _not_ include <Icons.h>, so the new Icons.h was not masked.
By replacing Icons.h in the Metrowerks MacOS Support directory, the problem was corrected.
If you compare the preferences between the 68K app and the init, you can see why the former worked and the latter did not. The 68K app was using a prefix file of ansi_prefix.mac.h, while the init was using MacHeaders.h. Neither was actually using precompiled headers. For the init, MacHeaders.h includes <Icons.h> which in dwp's environment was the _old_ Icons.h. He did have the new Icons.h included in the path, but it found the old one first. For the app, ansi_prefix.mac.h does _not_ include <Icons.h>, so the new Icons.h was not masked.
By replacing Icons.h in the Metrowerks MacOS Support directory, the problem was corrected.
What libraries do you already have in your code resource?