Separating UI and Logic for FORGE DA - What's the best method?

Separating UI and Logic for FORGE DA - What's the best method?

tomerFUNPJ
Enthusiast Enthusiast
372 Views
3 Replies
Message 1 of 4

Separating UI and Logic for FORGE DA - What's the best method?

tomerFUNPJ
Enthusiast
Enthusiast

Hello!

 

I have a few different tools in my Revit addin SLN, and one shared project that has util methods which are used throughout the tools.

I want to start using Forge DA for some of my tools.

As you know, it's not possible to reference a project with UI in it.

Of course, I never want to copy code, so I won't copy the logic of my project to the DA project.

So, I'm looking for the best way to use my tools both with UI and with Forge DA.

as I see it, there are 2 main options:

1. Using #define statements to only compile logic when compiling my Forge DA project.

2. Separating each tool to 2 projects, UI and Logic.

 

It sounds like the first option will be much clearer.

Do you know better options? How are you dealing with this limitation?

 

Thanks in advance! 🙂

0 Likes
373 Views
3 Replies
Replies (3)
Message 2 of 4

RPTHOMAS108
Mentor
Mentor

Not an expert on Forge.

 

Would have thought that you can reference the UI assembly in the project as long as the code path for the IExternalDBApplication never encounters any object from it, that may simplify your changes.

 

Isn't it just a case of changing the entry point and ensuring you are not using any UI aspects? I say this because outside of Forge in the past I've referenced things that had conflicts but they only came to light when a function called upon such i.e. even when the using/imports statement existed the external assembly wasn't referred to until called upon.  The problem with taking out the reference is in having to also take out the redundant code because otherwise you get design time errors.

 

If you find the above assumption to be wrong then you need to add additional configuration for Forge to the project (similar to multi version targeting add-ins). In such a configuration you can take out the UI assembly and exclude parts of code with conditional code statements.

 

It gets to the point where the permutations of Forge and Revit version may mean it's easier to just create new project. 

0 Likes
Message 3 of 4

jeremy_tammik
Alumni
Alumni

Thank you for such a salient question!

 

Personally, I prefer the second option you suggest.

 

I would implement separate pure DB and mixed DB + UI classes in separate DLLs.

 

Then you know for sure that all your DB-only classes can be used safely in DA4R.

 

I performed a couple of such separations myself:

 

https://thebuildingcoder.typepad.com/blog/about-the-author.html#5.55

 
The team also prepared the FamilyCreation/WindowWizard SDK sample for DA4R:

 

https://forge.autodesk.com/blog/design-automation-revit-window-family-creation-sample

 

That involves both DB and UI components.

  

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 4 of 4

tomerFUNPJ
Enthusiast
Enthusiast
Hmm. Yep. From what I checked, seems like it's totally possible to reference a dll that has RevitUI / WPF code in it as long as I'm not using it. So it is way simpler than I thought!
0 Likes