[VL] Manual Type settings via Configure does not work for imported Types

As you can see, the imports work for nodes both in and outside the region.
The type check in the output does not work.

A similar issue can be seen here:

hi Marco,

did you try to import the type “properly” (using the word as i am lacking a proper term).
There are several reasons for why you would want to do this. But let me first tell you how:

Ctrl-J for explorer, Select “Imports” in the drop down. Browse to the referenced dll and drag the type onto your document patch. You now can configure category info, name, immutability info or data flow specific help texts… Also you may want to drag drop the desired nodes onto that new patch and tweak them (pin naming, conversions).

This is our new layer for adjusting VL related meta info - which helps you separating your .NET dll from VL specific adjustments.

Now after “properly importing”: Is the the error still popping up?

Reasons for doing the explicit import:

  • Documents referencing this document see all the types and nodes that got dragged into VL.
  • No need to crawl dlls when searching for a node with the node browser.
  • Particularly useful for when this is not your dll:
  • you still can do renamings
  • decide upon which nodes and types should be visible to the end user
  • convert library specific data to VL default types (e.g. foreign Vector to VL Vector)
  • in general the ability to design the surface of the library. Nodes, Types, Pins. And by that the ability to offer a stable API surface for the end user. So when switching to a newer version of the foreign dll: get some support from VL (showing some red or orange pins…) visualizing the difference to the old node signatures… In the end there will be some small wizards that help you to decide how to deal with signature changes (forward to end user or not)… Conceptually this is possible by having the “language binding” (or “import instructions”) expressed in VL.

In the long rung run type annotations should come with a type browser that allows to reference foreign types of assemblies - just to be able to state that “proper”/explicit import is optional.

1 Like

this sounds huge. very glad to hear there is more to api import than what was mentioned at NODE17, even when currently in infancy.

unfortunately yes…

same result when placing the import in the root doc, if that should make a difference

forgot to mention, that the imported type now shows up in the type edit field.

just tested the other case in the opening post too, to rule out is has something to do with the delegate.
so there in fact things look less grim now (the pad accepts it happily), but the situation is still bad:

if you want the full patch I am happy to share

i would like to have a look at it

same sandbox patch as in the other thread

looks like the important bits are missing in the zip. Can you recheck?

its all there, it seems.
use a recent alpha, otherwise the vl plugin might not be valid.

hej marko,
you somehow had splicers in an if region. maybe you renamed a for-loop with that splicers to an if-region? anyway, such a thing shouldn’t happen and can be considered as bug, i guess.

We sorted this in a private chat that lead to some additional tests and issues. Thanks Marko.

ah, cool.
was there a solution at the end? or some other insights/issues?

Some of the issues were not reproducible when loading the patch fresh. so it is not completely conclusive, why the original issue appeared.

Yes, you heard it here first, if you are sure that some manual Typing should work, but import or casting errors appear anyway, don’t be afraid to restart vvvv and Retype. To my understanding, this forces a fresh build of your vl document.

Of course this should not happen, so more investigation will be necessary.
Mind you, this is an alpha issue, especially issued at NODE17. @gregsn tried to isolate the reproducible cases (with the delegate) after I could explain their mechanisms and made automated tests for that, to be sure that all future development is aware if it ever accidentally changes the expected behaviour.

So I close this thread for now, because a restart fixed the original issue

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.