Hi all,
I see that R2 provides some new methods which UR4 doesn't have.
So, if we want to write add-ins for Revit 2015 in general, do we have to avoid to use these methods ?
Additionally, if we want to use these methods, do we have to evaluate whether installed Revit 2015 is either R2 or UR4 ?
I use product GUIDs to determine if Revit is installed before trying to install my add-ins:
http://thebuildingcoder.typepad.com/blog/2013/04/perpetual-guid-algorithm-and-revit-2014-product-gui...
But how to see which sort of Service Pack has been installed ?
If providing R2 addins, it would be necessary to know that because they may create errors when running in UR4.
I also disagree in tagging this forum posting as solved:
http://forums.autodesk.com/t5/revit-api/worksets/td-p/5360275
The solution is using an R2 method, so this isn't a solution in general.
Best regards,
Revitalizer
Hi all,
I see that R2 provides some new methods which UR4 doesn't have.
So, if we want to write add-ins for Revit 2015 in general, do we have to avoid to use these methods ?
Additionally, if we want to use these methods, do we have to evaluate whether installed Revit 2015 is either R2 or UR4 ?
I use product GUIDs to determine if Revit is installed before trying to install my add-ins:
http://thebuildingcoder.typepad.com/blog/2013/04/perpetual-guid-algorithm-and-revit-2014-product-gui...
But how to see which sort of Service Pack has been installed ?
If providing R2 addins, it would be necessary to know that because they may create errors when running in UR4.
I also disagree in tagging this forum posting as solved:
http://forums.autodesk.com/t5/revit-api/worksets/td-p/5360275
The solution is using an R2 method, so this isn't a solution in general.
Best regards,
Revitalizer
The R2 is a subscription benefit that include new features. The UR4 is an update with no changes on APIs.
If you need to use R2 features, then you must make sure your customer(s) will have access to it and you can check using the version number.
The R2 is a subscription benefit that include new features. The UR4 is an update with no changes on APIs.
If you need to use R2 features, then you must make sure your customer(s) will have access to it and you can check using the version number.
And the suggestion on the other post is because this new feature is available... indeed is specific, but address your issue. Am I missing anything?
And the suggestion on the other post is because this new feature is available... indeed is specific, but address your issue. Am I missing anything?
Dear Augusto Goncalves,
ah, yes, I see that there is no reason to check version at installation time since we can avoid invoking unsupported methods by checking VersionName Property before, at runtime.
I think you meant VersionBuild; its value is "20140606_1530(x64)" while VersionName just is "Autodesk Revit 2015", on my machine.
Finally, no need to know special registry keys to evaluate the ServicePack version.
Thank you,
Revitalizer
Dear Augusto Goncalves,
ah, yes, I see that there is no reason to check version at installation time since we can avoid invoking unsupported methods by checking VersionName Property before, at runtime.
I think you meant VersionBuild; its value is "20140606_1530(x64)" while VersionName just is "Autodesk Revit 2015", on my machine.
Finally, no need to know special registry keys to evaluate the ServicePack version.
Thank you,
Revitalizer
Dear Augusto,
thank you for pointing that out.
I agree that the mentioned topic is solved, anyway.
Some time ago, I have complained about tagging a thread as solved even if there has no solution been found at all:
To sum it up:
What about these tags for ending a thread:
Finished
Solved in part
Solved
Also, think of people who pick up old threads.
It could be that there is a Revit 2014 solution for a question asked for Revit 2011, so there would be a conflict because the original problem stays unsolved while newer Revit APIs can solve it by now.
That would be a candidate for "Solved in part", too.
Best regards,
Revitalizer
Dear Augusto,
thank you for pointing that out.
I agree that the mentioned topic is solved, anyway.
Some time ago, I have complained about tagging a thread as solved even if there has no solution been found at all:
To sum it up:
What about these tags for ending a thread:
Finished
Solved in part
Solved
Also, think of people who pick up old threads.
It could be that there is a Revit 2014 solution for a question asked for Revit 2011, so there would be a conflict because the original problem stays unsolved while newer Revit APIs can solve it by now.
That would be a candidate for "Solved in part", too.
Best regards,
Revitalizer
Interesting suggestions, I'll escalate them.
Interesting suggestions, I'll escalate them.
You may be interested in the Application.IsSubscriptionUpdate property.
I noticed this by chance the other day when looking at the auto-complete suggestions on the Application class.
This property isn't present in the 2015 API docs that I have, so presumably it was introduced in R2. Seeing as this property isn't present in the standard 2015 installation (unless it was introduced in UR4), you'll probably get a MissingPropertyException if you try to access it from a non-subscription installation of Revit. You could wrap the call in a try/catch block to determine whether the installation has R2 or not.
This isn't the best place to ask, but does anyone know if there are updated API docs for 2015 R2? I can't seem to find them anywhere
You may be interested in the Application.IsSubscriptionUpdate property.
I noticed this by chance the other day when looking at the auto-complete suggestions on the Application class.
This property isn't present in the 2015 API docs that I have, so presumably it was introduced in R2. Seeing as this property isn't present in the standard 2015 installation (unless it was introduced in UR4), you'll probably get a MissingPropertyException if you try to access it from a non-subscription installation of Revit. You could wrap the call in a try/catch block to determine whether the installation has R2 or not.
This isn't the best place to ask, but does anyone know if there are updated API docs for 2015 R2? I can't seem to find them anywhere
Dear cshha,
yes I see there is such a property in R2, so there is no need for comparing build numbers;
using the build number approach, I would need to know the exact list of those numbers to do so, additionally.
So, your suggestion is much clearer.
I think that it is not necessary to use the try/catch block since we can access the property by reflection, browsing the PropertyInfos of Application.
Nonetheless, thank you !
Revitalizer
Dear cshha,
yes I see there is such a property in R2, so there is no need for comparing build numbers;
using the build number approach, I would need to know the exact list of those numbers to do so, additionally.
So, your suggestion is much clearer.
I think that it is not necessary to use the try/catch block since we can access the property by reflection, browsing the PropertyInfos of Application.
Nonetheless, thank you !
Revitalizer
Hi, What is the best technique for trapping cases where a particular method/property is not available. For example, I do not wish to release two 2015 applications, 1 for R2, 1 for the rest. So if I develop for R2 in order to use the more advanced features and compile without error, what is the best way to flag the function as being unavailable if run in 2015 standard. Simply look for a particular exception? And of course, if you develop for the higher version, it will be impossible to keep track of what may or may not be in the lower version. Therefore it is not practical to wrap something in (if not R2 give message "sorry"). Will the R2 dll load and only error when that function is called, or will it error on load? Thanks for any suggestions.
Hi, What is the best technique for trapping cases where a particular method/property is not available. For example, I do not wish to release two 2015 applications, 1 for R2, 1 for the rest. So if I develop for R2 in order to use the more advanced features and compile without error, what is the best way to flag the function as being unavailable if run in 2015 standard. Simply look for a particular exception? And of course, if you develop for the higher version, it will be impossible to keep track of what may or may not be in the lower version. Therefore it is not practical to wrap something in (if not R2 give message "sorry"). Will the R2 dll load and only error when that function is called, or will it error on load? Thanks for any suggestions.
If you try to run a method that is not available, the .NET engine will throw a 'Method not found' exception. You can also check the Revit built number to inform the user before try to run the code.
If you try to run a method that is not available, the .NET engine will throw a 'Method not found' exception. You can also check the Revit built number to inform the user before try to run the code.
Can't find what you're looking for? Ask the community or share your knowledge.