Bug with Stride LoadProject Path in 2021.4.0-613

[tobyk]

I’m using 2021.4.0-613 (RC2) on Win10 64 with Stride 4.0.1.1428

Thanks @Azeno for the hint, this is to do with Path ioboxes.

In my patch I have a path iobox with an absolute path connected to the Stride LoadProject node.
I have converted my stride project to 4.0.1.1428 and this appears correctly in the .csproj file.

When I open the patch with gamma 0613 the LoadProject goes purple and gives an invalid path error. I also get a spam of new windows. If I hold f8 long enough the patch will stop, I can right click the path iobox and select again the .csproj file and it works.
If I now save the patch and open it again I get the same bug.

No bug with the same patch and path in gamma 0588 .(even keeping the stride project in version 1428)
I sadly can’t send the original patch or stride project.
And I cannot recreate this bug using the loadproject example patch with my project or the demo project.

I do have a workaround, saving the absolute path in a string iobox and then using a ToPath node to connect to the path iobox.

[tonfilm]

@tobyk

saving the absolute path in a string iobox and then using a ToPath node to connect to the path iobox.

Is the path on another drive than the vl document, or on the network? maybe something goes wrong when saving the relative path… could you tell us whether the saved path in the xml of the vl doc looks good to you?

[Elias]

Can you tell us the absolute path of

1. the VL document where the path IO box is
2. the path of the project it’s pointing to

And also what @tonfilm said, select the IO box with the path, press Ctrl+C and paste (Ctrl+V) the XML here.

Maybe we get some clue out of that information.

[tobyk]

Absolute path of the VL document :

C:\Dev54\Patches\54.VL

Absolute path of the Stride csproj :
In both the path iobox and tooltip over the path iobox this absolute path is correctly displayed.

C:\Dev54\StrideProject\AssetStaging\AssetStaging\AssetStaging.csproj

XML of the path iobox (captured while in error state) :

<?xml version="1.0" encoding="utf-16"?>
<Canvas xmlns:p="property" Id="DzoCKhEOePFOMUhGQe2PDe" MergeId="311865" CanvasType="Group">
  <Pad Id="HxRyorhEsMcQamv71u0VBn" Comment="Project Path" Bounds="692,374,515,15" ShowValueBox="true" isIOBox="true" Value="..\StrideProject\AssetStaging\AssetStaging\AssetStaging.csproj">
    <p:TypeAnnotation LastCategoryFullName="IO" LastSymbolSource="CoreLibBasics.vl">
      <Choice Kind="TypeFlag" Name="Path" />
    </p:TypeAnnotation>
  </Pad>
</Canvas>

The error message:
does indicate it is being treated as a relative path… to Elementa? also used in this project.

[tobyk]

Now tested with 0615

-I no longer get an error in the vvvv gamma editor, all looking good here
-However when I export the application and run it I get the same error as an exception pop up. Same error however this time with the correct absolute folder path.
-If I click continue the exception keeps coming back, can only quit

[tobyk]

Small update: The workaround of storing the path in a string and using ToPath also prevents the exception in the exported app.

[Elias]

Ah yes, the export will behave different now. It’s also relative to the executable now. Say you have foo/Doc.vl with foo/images and export to bar/Doc.exe the path will resolve to bar/images. Previously it would bake the absolute path into the executable, which was fine for the dev machine but failed for all other machines.

[Elias]

And yes, if you want to store the path as absolute, use a string. The path topic will get an update in future versions but for now that’s how it is. Thanks for testing!

[tobyk]

Ok, great. That’s all workable for me. Thanks for your support