We are having Autodesk Forge App which takes Revit file as input and converts it to our custom format.
To give an idea about the App, see below
So far the App is working fine and we are supporting the Revit File versions till 2022. With the upgrade of Revit 2023 which introduced many changes and removed some of the methods, we are facing a challenge. Basically we want to have the backward compatibility as well i.e. to support the file formats before Revit 2023 as well along with 2023.
Having given this background, my question is - As the backend uses Revit API, do we need to use two sets of backend codes which will internally use 2 separate DLLs ( Revit API 22 and 23) as shown below or is there any better alternative?
You have two options: implement a Revit add-in that supports both versions of the Revit API. That can be achieved using the .NET Reflection library and is a bit tricky. One example of doing so for the Revit API is provided by Magson Leone in the article on Compatibilizar entre versões – API Compatibility Helper. The other, and probably simpler option is to implement separate add-ins for different versions of the Revit API and specify which version of the Revit engine to run in your Design Automation app.
Related
Has anyone done test automation for Revit? What tools did you use?
WinappDriver is able to open revit window but is not able to recognise the elements inside it
Your Revit add-in can only run inside a running Revit.exe session, and the Revit API is completely event-driven, and only Revit.exe can raise the corresponding events, so it is a bit tricky to drive it by a unit testing framework. There are several ways to work around this, though. A few of them are discussed by The Building Coder in the topic group on Unit Testing.
Please, is there a way to access the currently javascript API available independently of which Excel version I have??? At the moment only E3 or E5 licenses have this access and the ScriptLab still works with an older API. Thanks in advance!
According to Microsoft: "The async model can only be used with scripts created before the implementation of the current API model. Scripts are permanently locked to the API model they have upon creation. This also means that if you want to convert an old script to the new model, you must create a brand new script. We recommend you update your old scripts to the new model when making changes, since the current model is easier to use. The Converting async scripts to the current model section has advice on how to make this transition."
Script Lab and Office Scripts might feel the same, but they are certainly different. You can't run any code in both Office Scripts and Script Lab. They require different parameters. Support older Office Scripts that use the async APIs
I am trying out WinJS & would like to know if its possible to create a web application using WinJS.
Something that you would typically create using HTML5 + Bootstrap + JS framework (like AngularJS).
I need to create a Line of business that would be hosted on a server & can be accessed through any browser from any device.
I am thinking of considering WinJS because
- My primary audience would be on Microsoft devices & so in future if I need to create a Cordova wrapper I can easily create one.
- I would benefit from Microsoft support.
Absolutely. As of April 2014, WinJS became an open source, cross-platform framework, no longer exclusive to Windows. It's fully licensed for use on the web, and work has been done to make it compatible with other frameworks. You can find info now on try.buildwinjs.com, specifically http://try.buildwinjs.com/#get that tells you the different ways to acquire libraries for your needs. This includes doing a custom build of a subset of functionality, which takes you to https://github.com/winjs/winjs-modules where the source actually lives.
You can find some details on the Sept 2014 release of WinJS 3.0 at http://blogs.windows.com/buildingapps/2014/09/17/winjs-everywhere/.
A client wants us to develop a Picture Library system for them. The requirements are pretty typical - need to add pictures, tag them with metadata, store different sized versions and so on.
The client is keen on it being developed as a component which plugs into their existing SharePoint system. However, my feeling is that we would be better served building a standalone app - that way we don't have to shoehorn it into a SharePoint page and muck about integrating with SharePoint's APIs.
I am trying to look at this objectively and would welcome any arguments either way that people have.
Using an existing framework like Sharepoint imposes a lot of constraints on the design which makes the software architecture more uniform.
It does require some work on the part of the developer, because the developer does have to understand the API architecture and API's, etc.
However, developing a standalone application is the way that business's software architecture becomes a mix of 200 applications, using 20 different languages/architectures/platforms, half of which were developed by people no longer there - in short, a mess.
Sharepoint is documented, and will be supported probably long after you leave the company. Can you guarantee support for the application that you develop for as long as Microsoft will support Sharepoint?
You should do a cost/benefit analysis of integrating with SharePoint. You have listed some cons for integrating with SharePoint. Here are some pros.
Widely adopted platform.
Existing functionality to store/retreive/update images to data store.
Existing functionality to tag images.
Existing functionality to group several images together and treat as one virtual document (if using SharePoint 2010).
Keep in mind that you can integrate any custom ASP.NET page/application in Sharepoint so you can approach development like a standalone app. Your client wishes might include synchronization with Sharepoint's own picture library functionality and in that case you'll have to work with it's API.
It seems with SharePoint you are already done because it can more or less do what you describe already. What requirements do you have that cannot be met by OOB SharePoint?
I've used picture libraries for something similar before. While they have their quirks you do get a lot 'for free' like a UI, bulk uploading, metadata and 2 alternate sizes rendered.. My biggest gripe is they don't support the datagrid view so I cannot edit list metadata en masse like you can with other list types.
MS introduced JavaScript API for Excel. Based on the doc it seems like it supports desktop version of Excel too.
For c# VSTO addin the way to communicate with Excel is through Marshaling (COM object). Chaos happens if too many COM objects are acquired without proper clean up.
So the question is, does the js addin has those pitfalls? More specifically does js API use COM at all? If it does, is there any difference between Windows and Mac version? I thin Mac does not have the concept of COM (correct me if im wrong)
The Office.js APIs don't share any of the COM legacy with the current VBA/VSTO/COM add-in model. It's brand new code, written specifically for cross-platform needs. Where possible (e.g., Excel), the vast majority of this new code is actually shared between Desktop and Online and iOS and Mac. For other host applications, the code itself might not be shared, but we do everything we can to ensure consistency -- and for the new host-specific APIs (Word, Excel, and OneNote namespaces), have been favoring implementing APIs where support can be uniform across all the hosts. That is, if an API says that it's part of ExcelApi 1.3, you can be guaranteed that any of the Excel platforms (Desktop, iOS, etc.) that support 1.3 (Office.context.requirements.isSetSupported('ExcelApi', 1.3) === true) will have all of the APIs that are part of that set.