Failed to resolve file at path

[jacovandermolen]

Subject

Failed to resolve file at path []

Environment

LPub3D_x86_64-2.4.3.49.2836_20210609

Configuration

Local distrubution

Screenshots

Steps to reproduce

In my model I have a Cover Image where the PNG is somewhere on my computer. I get the error, but the image is displayed though.

[trevorsandy]

Hi Jaco, thank you for reporting this behaviour. Just so you know, at the moment, the MS DevOps builds are a bit unstable as I am transitioning the build environment from VC2015 to VC2019.

Can you share a mock-up meta command (using place holders for example) and context that show where the image is relative to the model file and the format of the meta command showing exactly the syntax of the file path (again using place holders is fine). Thanks.

Cheers,

[jacovandermolen]

OK, I see. Model file is in C:\MJ\LEGO\Models\mymodel.ldr Image is in C:\Users\mj\Google Drive\LEGO\Models\mymodel.png

LDraw code: 0 !LPUB PAGE DOCUMENT_COVER_IMAGE FILE GLOBAL "C:/Users/mj/Google Drive/LEGO/Models/mymodel.png"

[trevorsandy]

Hi Jaco,

I've taken a look at this behaviour and can report the Qt routine that checks the path is consistently failing when checking a google drive absolute path when that path is also mapped - for example when the drive is mapped to <drive letter>:\My Drive where <drive letter> is whatever drive letter you have set in your Google Drive preferences.

So in this case, if your mapped dirve is, let's say G:/, then replacing the path C:/Users/mj/Google Drive/LEGO/Models/mymodel.png with G:/My Drive/LEGO/Models/mymodel.png will produce the expected behaviour. From my understanding, the My Drive mapped folder name cannot be changed so this path should be present on your system.

If you navigate to C:/Users/mj/Google Drive from Windows Explorer, the view should be like this.

I've added a message to inform the user when ...Google Drive is detected in the path.

Cheers,

[trevorsandy]

This behaviour has been corrected.

Cheers,

[jacovandermolen]

This did work, but now in 2.4.5.111.3319 it does not.

[trevorsandy]

This did work, but now in 2.4.5.111.3319 it does not

Interesting. Are you using a google drive ? Can you describe your configuration that produces this behaviour ? Can the behaviour be reproduced with the models you have sent me already ?

I've added a new working folder for BOM images, separating them from PLI images #659. Perhaps this update has caused a regression.

I'll take a look.

Cheers,

[jacovandermolen]

OK, somehow, I now cannot reproduce this either again. Very strange.

However, this error is still there:

The header.ldr is in the same folder as the model file and occurs with or without quotes:

0 !LPUB INCLUDE header.ldr 0 !LPUB INCLUDE "header.ldr"

LPub does read and use the settings in the file though. The error dialog only comes one time. Leaving LPub open and opening another file that uses the same file does not give the error.

Only adding the full path, ie "C:\LEGO\Models\MyMoldel\header.ldr" fixes it.

[trevorsandy]

The header.ldr is in the same folder as the model file and occurs with or without quotes...

Ok - I'm not able to reproduce this behaviour with the models you shared with me. Those models use the relative path as you show in the command examples above.

Anyhow, looking at the code, the only way this message will present as it does (when a file with a relative path is indeed present) is if some sequence of interaction has changed the current working path (the folder of the model file) before the call to get the file path is triggered.

I imagine on a straightforward sequence like re/opening a file, this behaviour does not present ? So if you can retrace your interaction sequence to consistently reproduce this behaviour it would be good.

Cheers,

[jacovandermolen]

I have a few models in the same folder, so I can use the same header.ldr with settings I use for all those models. The error comes only once if you fresh start LPub and open one of the model files in that folder. Closing the working model and opening another does not produce the error. Closing LPub and restarting and opening a model again gives the error.

Could this have someting to do with the creation of the LPub3D folder where subfolders assem, bom, parts, submodels and tmp are?

Since the settings are read and applied, you can put fixing this bug on low priority.

[trevorsandy]

if some sequence of interaction has changed the current working path (the folder of the model file) before the call to get the file path is triggered.

Thanks for the sequence detail. I am able to reproduce and I've found the source of this behaviour. In fact, relative to the quote above, the current working path was not yet set when I perform the first check for the include file (during file load). I didn't see this before because for my tests, I load the model file as an input parameter when calling LPub3D.exe. In this scenario, the working path is always set before the open file call.

I've corrected this behaviour by setting the working path before the open file call in all instances of opening a model file.

Cheers,