|
|
|
|
|
|
|
Integration Woes: Similarly named files
|
|
|
Location: Blogs Foxfire! Development |
 |
| Posted by: Andrew MacNeill |
1/22/2008 8:48 AM |
Most Foxfire! programs classes start with FF so the chances of your application using the same name is unlikely - but it can happen. Here's a scenario of where it happened and how it was resolved.
We recently had a customer who was integrating Foxfire! with their custom application. Foxfire! worked perfectly on its own but when they ran it within their application, Foxfire! wouldn't start, giving an error of "FFREGISTRY is not found".
Whenever Foxfire! 8+ encounters an error, it puts the memory and environment information into a file named FFERROR.LOG. After taking a look at this file, we could see that the UTILITY.VCX file was not being loaded properly. But why?
Most Foxfire! programs classes start with FF so the chances of your application using the same name is unlikely - but it can happen. In this case, the UTILITY.VCX is used by Foxfire! and doesn't start with FF. In looking at the application file, I could see that a class library named SYSUTILITY.VCX was also being loaded in from the application itself.
When Foxfire! attempts to load in UTILITY.VCX or any class library, it looks to see if the class library is already loaded. If it is, it will simply return so it doesn't overload itself or return a "class already in use" error. In this case, it mistook SYSUTILITY for UTILITY.VCX. As a result, it never loaded the correct item.
One solution would be to unload SYSUTILITY.VCX before running Foxfire! with a single RELEASE CLASSLIB ALIAS SYSUTILITY. Then Foxfire! will run properly.
Of course, having seen this specific problem, we have updated the code and this will be corrected in the next release.
If you are having other integration issues, please email us at support@foxfirereporting.com or let us know in the comments!
|
|
| Permalink |
Trackback |
|
|
|
|
|
|
| |
|
|