.NET Final Project- Dynamic plugin with WPF GUI built in VS2017?

devvvv

#1

Hello, I am finishing a .NET course and my local tech college and I feel like being an overachiever on this one. I used to play around with vvvv quite a bit before I started going to school but mostly as an end user. Now that I know how to code in C# and we finally have an open-ended project, I would really love to show off vvvv to the class. Since it is only a 2-year program, I’ve barely even heard the word “animation” used in any of my classes, no one has heard of vvvv and only one of my professors even knows what data-flow programming is!

What I’d hoping to build would be almost identical to the node “Template (GUI Dynamic) [c#]”, except with a WPF GUI instead of Windows Forms, and with buttons for adding more controls to the page.

So far, I’ve familiarized myself with the basic idea of plugins and followed a tutorial on how to code one from within vvvv. The thing I’m struggling with is how to actually work with it in Visual Studio Community 2017. Everything we’ve done for this class has started with creating a new solution from VS, coding the program, then finally zipping the solution folder and submitting it the zip file to the instructor, which is also the required format for this project. She won’t grade it if she can’t open in it VS, and it can’t require her to install vvvv and all its dependencies. Because of this, I’m planning on bringing in my laptop for the presentation and having a class or GUI element that just spits out numbers so that she can confirm it works when I submit it.

So how do I go about building something with a Visual Studio __.sln file that works as a node in vvvv? Do I start it as a project in VS and add in the files from the plugin, or do I need to start with the plugin and somehow convert it into a VS solution? Are there things I need to import into the project? Will I run into issues when my instructor runs it on a computer without vvvv installed?

Any advice would be greatly appreciated, even if its a simple “not feasible for a beginner programmer to do in a week” :(


#2

Yo,

Usually the best way to start a new vvvv plugin is to first duplicate a template, then open it in Visual Studio. You will then have all dependency correct and just have to change the .NET version in your project properties.

Using WPF directly inside vvvv doesn’t offer any advantage, you would better code everything in Visual Studio. If you want to use WPF to create a UI for vvvv, just make it a standalone app and send OSC message (with SharpOSC) when an event like “button click” is triggered. It’s quite easy to do and works perfect with OSC nodes.

But if you must put a WPF usercontrol in a vvvv environment (which I really don’t recommend) then you have to instanciate your usercontrol with an old winform so vvvv can render it. Then you will have to get all usercontrol property value out of the plugin to output it (and end up with tons of pin)… so definitely not recommended.


#3

it’s pretty simple actually, create a .NET Framework class library project, add VVVV.Hosting, VVVV.Utils and VVVV.PluginInterfaces Nuget packages. If they don’t show up in the references you need to add them by hand though from the packages folder. Then create your node as you would in a dynamic plugin. Build it and either create a patch in your build destination folder or copy it in vvvv/packs/MyPack/nodes/plugins. To debug it simplest is to attach a debugger to vvvv.

Actually you CAN use wpf in vvvv on a different thread launched as a STAThread. Reference PresentationFramework and other WPF related assemblies from the GAC and then just instantiate your window which you’ve done in XAML in VS inside your STAThread. The only “disadvantage” is that it will act like its own window and won’t be managed by the beloved vvvv window management. You can even make bindings with ISpreads bridging with dependency properties and some manual change notifications coming from the main vvvv thread. ;) No need for OSC or interprocess stuff.
as for the teacher opening the stuff, they will need to install vvvv unfortunately, or you can just supply vvvv in your project zip I guess. but it will have a colossal size compared to just a pure little wpf app.

Here’s the snippet for creating the STAThread:

    public static Task<T> StartSTATask<T>(Func<T> func)
    {
        var tcs = new TaskCompletionSource<T>();
        Thread thread = new Thread(() =>
        {
            try
            {
                tcs.SetResult(func());
            }
            catch (Exception e)
            {
                tcs.SetException(e);
            }
        });
        thread.SetApartmentState(ApartmentState.STA);
        thread.Start();
        return tcs.Task;
    }

and you can just use it as you would Task.Run(…)


#4

I putted together a simple example with a standalone WPF app using MVVM pattern and used inside a vvvv plugin.

Basically you build your WPF app on one side, then within the vvvv plugin you access the different properties of the ViewModel.

With MVVM pattern you must use ICommand for stuff like Button and INotifyProperty interface for almost everything this way if you change the property (from vvvv for example) then the UI get notified and you see it changing accordingly.

MVVM pattern is a must when the UI start to get a little complex.

I don’t really know how to create a Bang as there is no such thing in WPF. So I just use a Change node on the vvvv side when button is clicked.

VVVVPF.zip (2.7 MB)

@microdee I understand the use of STAThread but apparently if WPF is within vvvv then FrameDrops are quite ok. I guess having it in a different thread is better anyway.

The problem I faced having a UI with like 50 different controls is for each of them you need an output pin. Some are spreads yes but some are not and in the end you get lots of connection to do manually.

The advantage I found using SharpOSC (I think @idwyr is using vvvv osc) is that from your UI app you send your message and inside your vvvv app you receive them without wiring. It acts like Send/Receive basically. In case of a few controls like my example then it’s probably not so relevant.

I would appreciate if you can elaborate on this “ISpreads bridging with dependency properties” things. Just curious.

Thx

P.S it would possible I believe (not sure if great) to have little WPF UI for stuff like TFX or shaders, a node could also contain its own UI.


#5

well to reduce pin count you can always introduce your own types and then use mp.pddn automatic node generators to split them in vvvv ;)
IMO in-process is always favorable solution over inter-process just because then you don’t need to think about communication channel between processes and serialization methods, both implying overheads in processing times. Furthermore, you can instantiate and manage multiple windows way easier if you are in the same app-domain, because otherwise you kinda shoot yourself in the foot because you need to develop the OSC API as well, whilst in the same app-domain you just directly call stuff.

@lecloneur In theory your node can inherit from DependencyObject and map a spread to a DependencyProperty and notify it with changes from the IDiffSpread.Changed. Set the DataContext of your WPF control to the node and in your bindings point to that dependency property. This would allow for example creating a DataTemplate for each entry in the spread to create nice view-models for them. For outputting values though you’d need to map the spread to an ObservableList and make a DependencyProperty out of that. Again in theory, I didn’t have the opportunity to test this yet. Read more on this here: https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/dependency-properties-overview


#6

Wow, thanks you guys! This is my first time posting on this forum and I was a little nervous considering a lot of the stuff I’ve read goes way over my head, but this is hands down best feedback I’ve received from asking a question on the internet, ever.

This is probably the best format for my current requirements, but from what the others have posted I wouldn’t say using WPF directly in VVVV doesn’t offer any advantage.

This is another reason I’m gonna go with OSC. I’ve got like a max 10 minutes to present and so having the patch as clean as possible will make it way easier to explain and give me more time to showcase the fun stuff in VVVV. Thanks for providing that example BTW, its really helping me make sense of how to communicate between different parts of your app, I’m definitely gonna come back and take a closer look at it once finals are done.

This is all sounding really similar to some of the concepts we learned in our Cross-platform class. Have you used Angular at all? If so, is a DependencyProperty similar to subscribing to Observable that you create in a service? I think they call is dependency injection in Angular.


#7

No I haven’t used Angular yet. On web/mobile I’m more on the React side. But anyway DependencyProperties in WPF indeed allow you to listen to changes coming from multiple places but it’s way more than that actually. It’s unfortunate that they are only usable on windows UI related objects.