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:
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:
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.
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.