Forum

UserControl

vvvv beta feature
#1

hello devvvvs,

the sdk offers a way to create a node with a window, that can be used with a right click (or with the infamous alt+1, 2, 3). This is done by inheriting System.Windows.Controls.UserControl (like here).

I presume, that vvvv checks internally, if a given node is inheriting this class, and treats it accordingly. However, because it is class-based inheritance, it basically forces devs to avoid inheritance in their packs (because custom base classes will not mix with UserControl, c# has no multiple inheritance).

So my question is this: would it be feasable to have an alternative interface (like IWindowPlugin) that gives the same functionality, but without restricting custom inheritance? Basically a gui’d-up-version of IPluginEvaluate?

#2

hei velcrome,

does this help? https://vvvv.org/forum/gui-window-problem?#comment-104285

#3

Oh @joreg, obscure win32 interfaces were not what i had in mind, don’t want to reinvent the wheel here.
but thanks for the context ;)

what I was asking for was basically what is available in the sdk right now: a ready-made vvvv window with all the bells (like alt+1,2,3) and whistles (like no top buttons), just not by the means of inheritance.

I don’t care much on how this is done, Interfaces were just an suggestion. For all I care, it could be an ImportAttribute like for the pluginhost or the logger.

Just not class inheritance.

#4

well, if you don’t care much how this is done, then why don’t you try the way i suggested? unless i missunderstand your goal, this should solve your problem.

#5

my goal is to ask devvvvs for more extensible access to a plugin window in vvvv-sdk, a boon of yours that provides ready-made integration into the vvvv framework.

with time and interest i maybe could maybe mimick it from the ground up, but tbh my soul pains at the thought of repeating someones work so dully.

is there something that stops you from refactoring? without knowing about intrinsic difficulties, i can only assume it is a minor refactoring to something that fits the general code injection theme of the sdk better.

on a related note, are you using this win32 stuff to provide the window?

#6

i am afraid i cannot follow…please answer the following questionair:

  • did you try the code i linked you to?
    ** if so
    *** does it solve your problem?
    ** else
    *** because you think it will not solve your problem?
    *** because it looks too complicated?

there was no mention of refactoring so far. i have no idea what you refer to.

quite vague question which i can only answer like so: yes we use some win32 stuff to provide windows.

#7

yesterday i wrote a lengthy response to this, but it seems i failed to commit it after happily approving the preview. so the answer, my friend, is blowing in the wind…

in it I described my use case in detail, and what actually made me regard this problem worthy of a thread.
maybe someone with admin rights can resurrect this post, if not, too bad.

to sum it up: i want to access the default vvvv provided window, but without messing up my own inheritance chain.
writing “my own” window as you suggested creates a whole new host of new problems, so it only serves as a theoretical solution to the problem outlined at thread start.

I mentioned that I am dispassionate about the actual design of this in the sdk, but that does not mean we should not be discussing that. it is certainly more on point than your focus on a solution, that require the users of your api (vvvv-sdk) to reinvent window handling.

#8

for reference. here is a demo implementation of the above-mentioned code-snipped. velcrome said this works for him.

customWindow.zip (14.1 kB)

© vvvv group