SolidWorks add-in and WPF window

SOLIDWORKS SOLIDWORKS Add-ins
1

Hi,

I have a SolidWorks add-in written in C# that uses Windows Form, but we suffer from scaling issues on high DPI monitors.

Now I would like to move from Windows form to WPF in order to fix the issue. My understanding is that the best practice is to have a dedicated Visual Studio project for the user interface to keep it separate from the add-in class library.

Now the questions:

  • Have a separate project for the UI is correct in the case of a SolidWorks add-in? Which kind of .net framework project should it be: WPF App, WPF Custom Control Library or WPF User Control Library?

  • With a separate project, the UI project should have a reference to the class library or the other way around? In all the tutorial I saw online there is a WPF project as the starting application that reference the class library, but with an add-in the class library must be the starting project…

  • With WPF do you use a MVVM framework? Which one do you recommend?

I use SolidDNA in my add-in.

Thanks in advance.

2

It’s been a while since I’ve used this framework to develop a UI but my past projects had all of the WPF UI elements in the same project as the add-in.

The best practice IMO is to use MVVM to keep UI elements separated from application logic. If that means your UI assets are in a separate project then that’s fine as long as it works for you. I’ve done that before as well.

The project type is entirely up to how you use it, but it sounds like the description you’ve given would best fit a class library so that you can link your UI to your add-in. So, your add-in class library would have a reference to your WPF project so it can access its elements.

As far as MVVM framework, Microsoft has a community toolkit that takes care of a lot of boilerplate code but that comes with the need to familiarize yourself with it’s functionality (Introduction to the MVVM Toolkit - Community Toolkits for .NET | Microsoft Learn)

1 Like
3

Hi Alex,
thanks for the reply.

It’s been a while since I’ve used this framework to develop a UI but my past projects had all of the WPF UI elements in the same project as the add-in.

Now I’m curious, do you currently use another framework or no framework at all?

I will look into the MVVM toolkit, I didn’t consider it before because I understood it target only .NET and not .NET Framework, but carefully reading the link you posted it seems I was wrong. Did you use other MVVM frameworks in the past? Or did you implement MVVM from scratch?

Regarding the number of project in the solution: what stopped me in the past from having one project for the class library and one for the UI is the fact that the class library should have a reference to the UI in order to access it, but it’s true also the opposite: should the UI not be able to access the classes and methods of the library? :thinking: What do you think?

4

It’s just been a while since I’ve coded an entire add-in. The last one I used was SolidDNA but it’s been forked to CADBooster.SolidDNA since then and I haven’t had the opportunity to use it again. I still like that framework for add-ins, but there are other popular frameworks as well now too.

I haven’t really used MVVM frameworks much in the past but I just recently familiarized myself with MVVM so I coded it from scratch so I could understand how it all works. Now I see the elegance of the toolkits that are available.

It depends on how you implement this I suppose. The UI view (xaml) should only be have access to the viewmodel that manages the data it displays. The viewmodel does the work of organizing your existing information from your model classes for display in your view. The model classes don’t have any connection to a view and are very loosely connected to a viewmodel if at all. I’d say to keep it all in the same project to make things as easy as possible.

1 Like
5

Thank you again for the answer.

I’d say to keep it all in the same project to make things as easy as possible.

All things considered I think I might do just that :smile:

Lets see if other have other opinion on the matter.

6

You’re going to have a lot of issues with WPF.

My suggestions:

  • Separate WPF project. I’d use a custom WPF library. Why? Because it imports all the right references for you.
  • Because there is no WPF application in the current domain, you may need to create a new Application (System.Windows.Application). Make sure the Shutdown mode is explicit.
  • You need to load your resources manually. Make sure to check for them before you do.

Use Prism 6.3 with the bootstrapper class.

I should probably create a guide for this…

2 Likes
7

Hi!

Thanks for you reply. I made some tests in the past couple of days and I can definitely tell that WPF is hard.

At first I had only the class library project, that require me to use a Windows form with an ElementHost for a WPF User Control… too convoluted.

Then I created a WPF Custom Control Library as second project, so that I can have a WPF windows for my UI, its view model, and use ShowDialog from the add-in class library. With this approach I have no WPF application, and I applied the MVVM pattern using Fody.Weaver following this tutorial from AngelSix.

That been said I’m not a programmer and I don’t know if this is the best approach to the problem.

  • Because there is no WPF application in the current domain, you may need to create a new Application (System.Windows.Application). Make sure the Shutdown mode is explicit.
  • You need to load your resources manually. Make sure to check for them before you do.

I’m sorry but I’m not sure what you mean.

Use Prism 6.3 with the bootstrapper class.

I will look into that.

A guide would be much appreciated for sure!!

8

I’m not sure if it helps since I don’t know where you’re using your WPF control but here’s the snippet of code that I use in my add-in to add a WPF control to the soliworks taskpane with SolidDna.

This is within the class that implements SolidPlugin

public override void ConnectedToSolidWorks()
{
    // TaskPaneWindowHost is an empty winforms usercontrol class added to the project.
    // MyAddIn is the class that implements SolidAddIn
    var taskPane = new TaskpaneIntegration<TaskPaneWindowHost, MyAddIn>  
    {
        Icon = IconExtensions.LogoSmall,
        WpfControl = new TaskPaneUserControl(),  // TaskPaneUserControl is the .xaml wpf object that you want to host within the task pane
    };
    
    taskPane.AddToTaskpaneAsync();
}

// I believe the CADBooster.SolidDNA removes this from the takpane automatically when the add-in is unloaded so you shouldn't have to worry about that

Edit to add link to example: solidworks-api/Tutorials/02-WpfAddIn/SolidDna.WpfAddIn at master · CAD-Booster/solidworks-api · GitHub

1 Like
9

Hi!

Thanks for the snippet. What I’m trying to do is to display a pop-up windows, that’s why I tried with an ElementHost inside a Window form.

A separate WPF library project allows me to create a Window class and display it from the main add-in class library with window.ShowDialog()

xCAD.NET has a method to create a WPF window as popup but only from the add-in class…

1 Like