LoadFamilySymbol() returns false for certain users

[sroswurm4GJQU]

Morning All,

I'm interested to hear if anyone has some ideas about factors that might cause 

LoadFamilySymbol(String, String)

or

LoadFamilySymbol(String, String, FamilySymbol)

to return false only on a particular user's machine. 

This process is being performed on standardized out-of-box Revit family content (W-Wide Flange.rfa in this case).  The portion of the program that uses this method to load additional symbols from a family has been tested extensively on dev machines, test machines, and other end user machines and performs well in all prior cases.  The user experiencing the issue is said to be working with Revit-default unmodified family content.

Here are the precautionary steps already in place within the program:

1. Bypass load if the symbol is already found in the document.
2. Build the fully qualified name of the source family (.rfa) file using Application.GetLibraryPaths() in order to make sure we look by default where the user intended. 
3. Use File.Exists() to make sure the source family file is found prior to attempting the load.
4. Check if the family has an accompanying Type Catalog (.txt) file
5. Check if the required FamilySymbol name has a match found in Type Catalog (.txt) file

Since we pre-check that the symbol does not already exist in the document, I would expect that the IFamilyLoadOptions overload is not needed.  The LoadFamilySymbol() is only attempted if all of the above constraints are satisfied.  Otherwise, the appropriate warning message is displayed both to the user and to debug outputs.  This process has worked well in a variety of user environments, but at one particular user site the load method returns false and a new type is not loaded.

The LoadFamilySymbol() is wrapped inside a try / catch block, but does not return an exception.

I've requested that the user supply a copy of their Type Catalog file so that I can manually check it for problems, but have not received it yet.  I'm very curious to hear if other devs have experienced unexplained false returns from this method and what other causes I have not yet considered.

@jeremytammik 

[sroswurm4GJQU]

Morning All,

I'm interested to hear if anyone has some ideas about factors that might cause 

LoadFamilySymbol(String, String)

or

LoadFamilySymbol(String, String, FamilySymbol)

to return false only on a particular user's machine. 

This process is being performed on standardized out-of-box Revit family content (W-Wide Flange.rfa in this case).  The portion of the program that uses this method to load additional symbols from a family has been tested extensively on dev machines, test machines, and other end user machines and performs well in all prior cases.  The user experiencing the issue is said to be working with Revit-default unmodified family content.

Here are the precautionary steps already in place within the program:

1. Bypass load if the symbol is already found in the document.
2. Build the fully qualified name of the source family (.rfa) file using Application.GetLibraryPaths() in order to make sure we look by default where the user intended. 
3. Use File.Exists() to make sure the source family file is found prior to attempting the load.
4. Check if the family has an accompanying Type Catalog (.txt) file
5. Check if the required FamilySymbol name has a match found in Type Catalog (.txt) file

Since we pre-check that the symbol does not already exist in the document, I would expect that the IFamilyLoadOptions overload is not needed.  The LoadFamilySymbol() is only attempted if all of the above constraints are satisfied.  Otherwise, the appropriate warning message is displayed both to the user and to debug outputs.  This process has worked well in a variety of user environments, but at one particular user site the load method returns false and a new type is not loaded.

The LoadFamilySymbol() is wrapped inside a try / catch block, but does not return an exception.

I've requested that the user supply a copy of their Type Catalog file so that I can manually check it for problems, but have not received it yet.  I'm very curious to hear if other devs have experienced unexplained false returns from this method and what other causes I have not yet considered.

@jeremytammik 

[paul.t.macknight]

A couple questions for clarification:

1) These are being pulled form the C:\ Drive, and not a shared network folder, correct?

2) You have verified that the user has a recommended install, and not a custom install into a different directory? I don't suppose this would have any bearing considering the use of the Application.GetLibraryPaths() method, but it doesn't hurt to be sure.

3) You have verified the user has left the paths under Options > File Locations > Places... alone? Application.GetLibraryPaths(), as I'm sure you know, returns these file locations, and if they were changed for some reason by the user, some plugin or other script, or another IT admin from the default Revit install location, it would not necessarily find the desired family under "Revit-default unmodified family content." This may be what you meant to indicate by "Revit-default unmodified family content," but again I wanted to clarify, as "to make sure we look by default where the user intended" has some potential to backfire with people like me who prefer to modify Revit options but not necessarily default install or library content, and instead use a custom library in another location.

I'm sure these are already things that you have verified, and some of what you have said indicate these steps were taken, but I just want to make explicitly sure these have been looked at.

[paul.t.macknight]

A couple questions for clarification:

1) These are being pulled form the C:\ Drive, and not a shared network folder, correct?

2) You have verified that the user has a recommended install, and not a custom install into a different directory? I don't suppose this would have any bearing considering the use of the Application.GetLibraryPaths() method, but it doesn't hurt to be sure.

3) You have verified the user has left the paths under Options > File Locations > Places... alone? Application.GetLibraryPaths(), as I'm sure you know, returns these file locations, and if they were changed for some reason by the user, some plugin or other script, or another IT admin from the default Revit install location, it would not necessarily find the desired family under "Revit-default unmodified family content." This may be what you meant to indicate by "Revit-default unmodified family content," but again I wanted to clarify, as "to make sure we look by default where the user intended" has some potential to backfire with people like me who prefer to modify Revit options but not necessarily default install or library content, and instead use a custom library in another location.

I'm sure these are already things that you have verified, and some of what you have said indicate these steps were taken, but I just want to make explicitly sure these have been looked at.

[sroswurm4GJQU]

Paul,

Thanks for your response and for raising some issues for consideration.  Please see below:

1.)  The site where users are experiencing this issue has people work from the family content installed on their local drives.  They are not attempting to point Revit to a network folder to get loadable content.

2.)  The user has indicated that they are using default Revit install locations.  In addition, our application has both debug outputs and pop-up windows that allow us to verify the fully qualified name of the family being targeted for symbol loading.  The family is in fact being found right where we expect it to be.  We simply cannot successfully load symbols from it.  

3.)  I have looped the user group's BIM administrator into the conversation and he has not chimed in to indicate that they actively modify either the Options settings or the file location where content is stored.  When the user saw the pop-up warning and reviewed the directory where the app is searching, he indicated that is the exact place they load from when manually updating section sizes.

The error handling in our application uses a "tiered" warning system that allows us to narrow down to exactly which step in the process has failed.  As a result, we know that the app is not failing to find the family .rfa file.  But any attempt to LoadFamilySymbol() from that family returns false, with no exception caught.  I'm still waiting to get my hands on a copy of the Type Catalog file to see if there is an easy fix due to something they've changed in there.

[sroswurm4GJQU]

Paul,

Thanks for your response and for raising some issues for consideration.  Please see below:

1.)  The site where users are experiencing this issue has people work from the family content installed on their local drives.  They are not attempting to point Revit to a network folder to get loadable content.

2.)  The user has indicated that they are using default Revit install locations.  In addition, our application has both debug outputs and pop-up windows that allow us to verify the fully qualified name of the family being targeted for symbol loading.  The family is in fact being found right where we expect it to be.  We simply cannot successfully load symbols from it.  

3.)  I have looped the user group's BIM administrator into the conversation and he has not chimed in to indicate that they actively modify either the Options settings or the file location where content is stored.  When the user saw the pop-up warning and reviewed the directory where the app is searching, he indicated that is the exact place they load from when manually updating section sizes.

The error handling in our application uses a "tiered" warning system that allows us to narrow down to exactly which step in the process has failed.  As a result, we know that the app is not failing to find the family .rfa file.  But any attempt to LoadFamilySymbol() from that family returns false, with no exception caught.  I'm still waiting to get my hands on a copy of the Type Catalog file to see if there is an easy fix due to something they've changed in there.

[sroswurm4GJQU]

After some further testing, I was able to determine that the LoadFamilySymbol() failure may be related more to the Revit file itself rather than the user environment.  When testing the user's Revit file in my own test environment I observed the same LoadFamilySymbol() failure as the user was seeing.  I tried loading a new section size manually in the UI and found that on my machine Revit is attempting to automatically reload the entire family when you request to load a single new type:

This being the case, it is definitely necessary to go ahead and implement the IFamilyLoadOptions overload so that the interface's methods can handle the family reload.  I tried incorporating IFamilyLoadOptions and it seems to resolve the failure in my test environment.  

This brings back an old question I've occasionally encountered in the past:  Why does Revit sometimes automatically trigger reload of an entire family when the user is only attempting to load a single new type from the existing family? 

Clearly, this was one problem, but I don't yet know if it's "THE" problem.  I'll need to try the update on the user's computer to know for sure.

[sroswurm4GJQU]

After some further testing, I was able to determine that the LoadFamilySymbol() failure may be related more to the Revit file itself rather than the user environment.  When testing the user's Revit file in my own test environment I observed the same LoadFamilySymbol() failure as the user was seeing.  I tried loading a new section size manually in the UI and found that on my machine Revit is attempting to automatically reload the entire family when you request to load a single new type:

This being the case, it is definitely necessary to go ahead and implement the IFamilyLoadOptions overload so that the interface's methods can handle the family reload.  I tried incorporating IFamilyLoadOptions and it seems to resolve the failure in my test environment.  

This brings back an old question I've occasionally encountered in the past:  Why does Revit sometimes automatically trigger reload of an entire family when the user is only attempting to load a single new type from the existing family? 

Clearly, this was one problem, but I don't yet know if it's "THE" problem.  I'll need to try the update on the user's computer to know for sure.

[sroswurm4GJQU · Accepted solution]

Final update on this issue.  After testing and deploying back to the affected user's machine with IFamilyLoadOptions implemented, this problem is now resolved.  For anyone else experiencing an unexplained failure of LoadFamilySymbol(), I highly recommend trying the overload that uses IFamilyLoadOptions.  You may be running into a situation where Revit attempts to reload the entire family even though you did not expect it to.  If this is the case, the load method will not succeed without the overload to handle the family reload options.

[sroswurm4GJQU · Accepted solution]

Final update on this issue.  After testing and deploying back to the affected user's machine with IFamilyLoadOptions implemented, this problem is now resolved.  For anyone else experiencing an unexplained failure of LoadFamilySymbol(), I highly recommend trying the overload that uses IFamilyLoadOptions.  You may be running into a situation where Revit attempts to reload the entire family even though you did not expect it to.  If this is the case, the load method will not succeed without the overload to handle the family reload options.