Announcement

Collapse
No announcement yet.

Wpf

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Wpf

    I’m looking into using WPF for Revit UIs and trying to find a solution to move forward with. I think WPF has great potential for use within Revit and could be implemented with a simple solution that is easy to maintain.

    Has anyone been able to implement WPF with any success?

    I’ve had a quick look at the REX SDK which seems nice and very powerful however it’s a bit complicated and restrictive for my needs.

    My requirements would be:

    1. Use of WPF and WinForms with-in the same project and the use of various dialogs ie no MainWindow
    This seems doable

    2. Implementation of MVVM pattern for wiring up WPF views
    Like http://galasoft.ch/mvvm/ or http://blog.vuscode.com/malovicn/arc...-approach.aspx

    3. Blendability and being able to launch dialogs by-passing Revit
    Seems possible with REX SDK

    4. Testability
    5. Template add-in & Snippet support

    I think this could allow rapid Revit development opening the door to some pretty cool apps.

    I’m doing some tests to see what’s possible and hope to end up with some form of framework but I am no expert on this.

    What about a collaborated open source project if there are enough willing experts?

    Interested in hearing others thoughts and opinions.
    Last edited by n8wex; September 4, 2011, 07:17 AM.

    #2
    Well, I'm no expert either but it would be interesting to participate!
    Martijn de Riet
    Professional Revit Consultant | Revit API Developer
    MdR Advies
    Planta1 Revit Online Consulting

    Comment


      #3
      I might be interested in participating (if I can find the time), but I'd suggest avoiding WPF with Revit unless you're prepared for some extra work.

      WPF implicitly uses 2 threads and I've found that Revit becomes unstable as soon as you get another thread involved...

      We started out running WPF under Revit with Xrev and lots of things worked initially but later we started hitting lots of weird issues that ultimately traced back to the simple fact that an extra thread was running. I'd already been through the documentation and all API calls were on the main thread (as indeed was all the logic, but WPF also had it's rendering thread running). I did some further testing without WPF but instead spawning worker threads that did nothing while some more complicated logic was executing on the main thread and this also resulted in weird intermittent issues.

      We just couldn't rely on this model for a commercial product and in the end we took the GUI out of the Revit process and now run it in a background 'companion' process. This does add some extra complexity but it allowed us to keep our WPF GUI and continue using WPF for future products, and it provides a little more freedom in other areas too.

      Comment


        #4
        Matt, thanks and great feedback there is nothing worse than getting so far down the line and finding out these sorts of issues...

        This was my main concern I want to implement WPF for apps where I work but only if it is productively feesable and it confidently works.

        Do you think this has something to do with Revit being the main app and there is no bootstrapper main xaml being used as the controlling window?

        I wonder if this issue exists using the REX SDK framework... or hosting WPF user controls in a WinForm dialog?

        Could we write some simple code to reproduce this issue and find a work around?

        Cheers,


        Nathan

        Originally posted by Matt Siebert View Post
        I might be interested in participating (if I can find the time), but I'd suggest avoiding WPF with Revit unless you're prepared for some extra work.

        WPF implicitly uses 2 threads and I've found that Revit becomes unstable as soon as you get another thread involved...

        We started out running WPF under Revit with Xrev and lots of things worked initially but later we started hitting lots of weird issues that ultimately traced back to the simple fact that an extra thread was running. I'd already been through the documentation and all API calls were on the main thread (as indeed was all the logic, but WPF also had it's rendering thread running). I did some further testing without WPF but instead spawning worker threads that did nothing while some more complicated logic was executing on the main thread and this also resulted in weird intermittent issues.

        We just couldn't rely on this model for a commercial product and in the end we took the GUI out of the Revit process and now run it in a background 'companion' process. This does add some extra complexity but it allowed us to keep our WPF GUI and continue using WPF for future products, and it provides a little more freedom in other areas too.

        Comment


          #5
          Originally posted by n8wex View Post
          Do you think this has something to do with Revit being the main app and there is no bootstrapper main xaml being used as the controlling window?
          No. You need to initialise the System.Windows.Application instance which is what happens with a regular WPF project. You can do this in your IExternalApplication's OnStartup method but you need to make sure it's ShutdownMode is set to OnExplicitShutdown and then cleanup in the OnShutdown method. Also, since Application is a singleton and all addins are run in the same AppDomain, you should be careful about initialising / cleaning up the Application instance when multiple WPF addins are running (assuming they're doing the right thing too).

          Originally posted by n8wex View Post
          I wonder if this issue exists using the REX SDK framework... or hosting WPF user controls in a WinForm dialog?
          I don't know about REX, but I assume so since the issue seems to be more related to Revit and the way it hosts the runtime.

          My understanding is that WPF controls on a WinForm dialog would still involve WPF's 2 thread model so I'd expect the issue would still exist.

          Actually, in Xrev, we're using a WinForm as a shell to host our GUI as a WPF user control. This is because assigning Revit's main window as the Form's owner works better than for WPF Windows. That is, clicking Revit's main window while our Form is open causes the Form's taskbar button to flash, and a few other things work better too but I can't remember them right now. I've since done some more digging and found how to achieve this with WPF Windows using a few interop calls. All this runs outside of Revit though, and I can't remember if we were using the WinForm before separating the GUI from Revit's process.

          Originally posted by n8wex View Post
          Could we write some simple code to reproduce this issue and find a work around?
          Maybe, but I personally wouldn't pin my hopes on it. The issues I saw were intermittent and seemed to depend on things like which API calls I was making on the main thread, the content in the document that was open, the alignment of the moon, etc. There were times when everything seemed to work well, but I'm just not sure I could trust it.

          Comment


            #6
            Ok thanks mate this is not giving me with much confidence using WPF within Revit which is a shame there is so much potential I was even dreaming up ways to embed silverlight controls to use pivotviewer which sounds like it would be a whole other can of worms...

            What about AutoCAD / WPF I assume these work together and I wonder if there is something AutoCAD does that could be implemented into Revit?

            I thought Xrev was WPF but had no idea you had to hack so much to make it work.

            Maybe we just have to wait and cross our fingers the next Revit and WPF releases mature enough to allow us to combine technologies without major issues...

            I will look into the REX API to see if there is a mention maybe worth running some tests within the framework to put it at it's paces. This maybe the only option... If you can let me know what to try and I'd be happy to have a go...

            Thanks.
            Last edited by n8wex; September 5, 2011, 06:51 AM.

            Comment


              #7
              Originally posted by n8wex View Post
              Ok thanks mate this is not giving me with much confidence using WPF within Revit which is a shame there is so much potential ...
              Yeah, WPF is great, but it's learning curve is pretty steep and it's full of gotchas that make you want to tear your hair out...

              Originally posted by n8wex View Post
              What about AutoCAD / WPF I assume these work together and I wonder if there is something AutoCAD does that could be implemented into Revit?
              I don't know about AutoCAD and WPF. I do wonder whether the problem would exist if Revit add-ins were isolated in their own AppDomains but I'm fairly certain it would. Still, it would be nice to see Revit using MAF, although this would be no small task.

              Originally posted by n8wex View Post
              I thought Xrev was WPF but had no idea you had to hack so much to make it work.
              We were too far down the WPF path when we discovered the issue. The extra work we had to do does open up some cool possibilities though.

              Originally posted by n8wex View Post
              If you can let me know what to try and I'd be happy to have a go...
              I can't remember the specifics of the tests (it was quite some time ago) but just try starting another thread and get it to do something trivial while you do something more complicated with the API on the main thread. I think the PrintManager is one thing that often triggered the exceptions for us. Sorry I can't provide more detail.

              Comment


                #8
                Matt, thanks for the detailed answers... You know it is worth trying to to see if the issue still exists. I was having issues with Extensible Storage saving to elements was slow then after SP1 install it worked a treat so just maybe it could be ok now...

                Will try put something together when I find some spare time...

                Been looking into patterns and wondering what would be the best to implement for not sure if MVVM is suited maybe some variation of MVP or MVC I really have no idea but will have a go I'm sure I will learn something do you have any recommendations?

                Comment


                  #9
                  I've had a go at MVVM based on http://blog.vuscode.com/malovicn/arc...-approach.aspx. So far so good but it doesn't do much and I'm not sure how to load the model into the VM from a command the object comes up null in the AutoWireUpViewModelBehavior... If you have time take a look and let me know what you think so far...



                  http://dl.dropbox.com/u/8875196/RMVVM.zip
                  Last edited by n8wex; September 6, 2011, 02:58 PM.

                  Comment


                    #10
                    I'm not particularly keen on that Naked MVVM approach - I dislike the VM having any dependency on the V.

                    I'm no MVVM expert though and thus far I've steered clear of the various MVVM frameworks. That said, there are some scenarios where MVVM in WPF is particularly difficult without some other functionality that these frameworks typically provide. For example, when the VM needs to invoke a message box or dialog of some sort there's no elegant built-in way to handle this. Two options I've borrowed from PRISM are Interaction Request Objects passed via events, and an Interaction Service. I've been using IROs so far but I think the Interaction Service would be better.

                    I've had a brief look at your code. Is the problem that the VM doesn't get resolved from the IoC container? Or does it get a UserVM without a User object? (ignoring the hard coded user for now which I assume you've added for testing)

                    With regards to the command loading the Model (User?) into the VM, this is the reason I dislike View-First construction - if the View is the trigger for resolving the VM, then the VM must contain logic to resolve the M. This could be handled by the IoC container injecting the M into into the VM when it is resolved but in most scenarios I deal with there are many model instances and it seems very hackish to register a model instance in the IoC container just to support this approach.

                    I'd rather construct the VM and give it the M and then have the V somehow resolved for the VM - i.e. via an Interaction Service of some kind. In this way, if the VM needs to invoke other dialogs, it could construct the VM with the relevant M(s) and then have the 'child' V resolved by the Interaction Service while still being completely decoupled from the V.

                    I believe there is some debate within the MVVM community about which approach is better (View-First or ViewModel-First), but I think like most things it depends on your specific requirements.

                    Comment

                    Related Topics

                    Collapse

                    • Best Apps/Add-ins for Revit?
                      Hi all,

                      I tried searching but couldn't find anything so I thought I would ask around:

                      What are your favorite apps/add-ins...
                      July 9, 2014, 02:20 PM
                    • New User topics
                      From the sounds of it over at AUGI there is little or no chance that the Forum history is coming back prior to 2013. And there is some small validity...
                      December 10, 2010, 06:11 PM
                    • Revit OpEd: Yeah But
                      Any reply that starts with "Yeah, but..." isn't likely to agree with what was just said. In my travels working as a consultant I've been part...
                      March 16, 2012, 06:15 AM
                    • VR and Revit
                      I have recently been messing around with an HTC Vive headset and Revit.

                      I just thought I would post my initial impressions for you all, maybe...
                      September 15, 2017, 09:09 AM
                    • Snag/Punch-lists
                      So snag lists, or for the US-contingent, "punch" lists (why so violent eh?)… a question:

                      But first, a full disclaimer:
                      ...
                      August 27, 2018, 04:54 PM
                    Working...
                    X