i thought its a good exercise to import a c# project i’m working on, based on wpf. This project already runs
as standalone WPF
as library run by a console app
as library in a vvvv beta plugin
ok, now vvvv gamma.
i reference the dll via the gamma menu and find the stuff in the node editor. but whats missing is the showdialog() method which should be inherited. well at least thats how it works in VS.
not here
i tried faking it with the public showwindow method, which does show up in vvvv gamma.
but still no luck, there is this error message about missing additional dependencies (CalcBinding.dll), which is weird, because the dll’s are there. not sure how to make them present to vvvv gamma. they are in the same folder as the main dll and the vvvv gamma project file.
not so straight forward to get something like this up and running. or i’m thinking in the wrong way. it was a lot easier to get it working in vvvv beta or console
edit: is there something planed to have DLL’s behave more like blackboxes, you just add them and don’t have to dance the “create pad, show dialog” thing again in vvvv gamma. just drop the dll and let it do its work and have access to the public variables of the dll ? a bit like plugins in vvvv beta work.
currently we don’t show inherited members of a specific class. this is on our list since a while. we think about showing them in light gray or italic as an addition to the list.
for single dlls you have to reference them as well to register it to the system. there are only a few standard search paths like .NET framework and nuget folders where dlls get picked up automatically. this is important to not end up in a dll hell and load wrong versions. but we could think about a standard search path besides a .vl document, something like \lib or \bin. however this could also slow down the system quite a lot.
not really, this would require specific contracts that a dll have to fulfill in order to work as a ‘plugin’- we don’t want that in dlls. there is a pattern to create process nodes for vl in c#, but that is not really necessary and it’s more easy to patch.
so the workflow is as follows: for your plain .NET dll add one .vl document and add a process node that manages an instance of your class/window/whatever you like to make available for vvvv gamma users. then design the node in a useful way (visually and in real-time!) to that others just need to reference the .vl file and have nice high level nodes to use.
cheers for the info. there is a pattern for process nodes ? i would be interested in that. i‘d prefer making the wrapper in my c# project than in vl. unity has this kind of contract system as well and its a no brainer to use. would be nice to have the choice, especially if the dependencies don‘t work as expected in vvvv gamma.
ok, i think it was my misunderstanding. VS behaves the same when importing a DLL, it does not provide referenced stuff. Since i had everything in one project in VS,(console wrap, vvvv wrap etc.) it was just relying on the project reference of the presentation foundation. since vvvv gamma is a new project, i have to do it again.
anyway, since i understood this (stupid me) , i find it even more interesting to open up vvvv gamma to c# coder, to “prepare” plugins for instant use in vvvv gamma, without the extra step of “re-creating” the VS project in terms of references and instantiating the class object in vvvv gamma. it is absolutely cool you can wrap in vvvv gamma but please provide a doc for an alternative c#-centric way. cheers.
but whyyyyyyy??? 😭😭😭
why wouldn’t you do that? why would you hide them? Inherited members are equally important part of a class, I hate when the Object Browser default hides them too, but at least they have an option to turn it on inside the view menu afair.
@u7angel we started like this but then de-prioritized as we found it more important to be able to use any c# code as is, rather than asking c# coders to again add vvvv-proprietary plugin wrapper code. all the plugins made for beta, are written in c# but still rather beta centric due to the need for adhering to the plugininterface. by not focusing on such a wrapper in c#, the interface is much clearer and it will be much more appealing for .NET coders out there to contribute because anything vvvv specific (process node…) is not interfering with their code.
this is not to say that we couldn’t bring back such functionality but i hope you see that priority-wise we made a considered choice. and think about it: maintaining the process-wrapper is much easier in vvvv than in c#: need to change a pins name, add some functionality? just modify the wrapper, instead of stopping the program, recompiling c#…see?
@microdee it is not to argue about why/not. it is just the current status and will be addressed at some point.
as joreg said, totally on our list. it’s just that sometimes you inherit dozens of methods from different super classes or interfaces and we don’t yet have the UI to manage that. it should be somehow sorted by super type and also by distance of inheritance.
think of Spread, it would at least double the list of nodes which is long already. so it has to be some kind of checkbox, like advanced or experimental. and also the created node would need to know that it is from the super type but should output the specific inherited one which means it needs to store that information somewhere in the model. we just didn’t have time to address this yet.
i also want to emphasize that, you are way faster doing that at runtime with real-time compilation and immediate feedback. just try the workflow, get used to it a little and you won’t look back to the edit-compile-run cycle.
