The Ruby console reports an error when the Material Export button is clicked

[wu1234a]

Sorry, I'm new to Ruby and not sure how to make changes, so I can only ask questions.

[bbeaulant]

Hmm, I'm not sur to know why the "" before the M is a problem when the same "" before the S is not 🤔
(Fucking Windows path notation ...)

[mauriciobellon]

Hi @wu1234a

I am trying to reproduce the error that you encounter so we can work out a solution.

I have tried to OpenCutList 6.2, 6.3-dev and 7.0-dev on my Windows 11 system with Sketchup 23 and 24, I also spun up a VM with Windows 10 and tested as my main system.

So far, no error, can you provide more details of your system?

Looking at the error, it seems to me that for some reason in your system, last_dir is receiving a string as path with a single backslash, that makes ruby escapes the string and error.

Ruby should work fine with forward slash in all systems.

I supposed that a helper method that sanitizes the path would do the trick in this case.

Create a method in plugin.rb:

def self.sanitize_path(path)
  return path unless path.is_a?(String)
  path.gsub('\\', '/')
end

Use it in the export worker when getting the last_dir:

last_dir = Plugin::sanitize_path(Plugin.instance.read_default(Plugin::SETTINGS_KEY_MATERIALS_LAST_DIR, nil))

Also after selecting the path via save panel saves a sanitized version of the path for future use:

if path
  selected_dir = File.dirname(path)
  sanitized_dir = Plugin::sanitize_path(selected_dir)
  Plugin.instance.write_default(Plugin::SETTINGS_KEY_MATERIALS_LAST_DIR, sanitized_dir)

@bbeaulant please could you confirm if that is the right approach?

[bbeaulant]

Hi,

The first thing to do is to check what is really stored in the SketchUp user preferences file. This file is named privatePreferences.json. I don't remember its location on Windows. Maybe Somewhere in AppData.
In this file you should find a section named "ladb_opencutlist" that looks like :

The key to check is settings.materials_last_dir.

[bbeaulant]

Please note that the privatePreferences.json file is only saved when SketchUp is closed.

[mauriciobellon]

@bbeaulant, thanks for the context here.

I take that you think the error occurs when settings.materials_last_dir tries to load the path from the JSON. In that case, my sanitization approach wouldn't even have the chance to correct the path before it errors. Can we capture the escape error and just nil the path when that occurs?

BTW in all tests so far, PrivatePreferences has already received a forward slash path, as it should.

The PrivatePreferences is stored in:

%userprofile%\AppData\Local\SketchUp\SketchUp 2023\SketchUp\PrivatePreferences.json

(respecting the Sketchup version)

@ wu1234a, please could you provide your PrivatePreferences.json here so we can verify how that path was created.

[bbeaulant]

@mauriciobellon , thank you for your investigations.

I prefer catching the error when reading instead of altering path value.
SketchUp is responsible of escaping string when it stores values in this file.

lairdubois-opencutlist-sketchup-extension/src/ladb_opencutlist/ruby/plugin.rb

Line 348 in 115df64

Sketchup.read_default(section, key, default_value)

The strange thing here is that if the settings.materials_last_dir value is not correctly escaped that means that the value is not a valid string and so the entier privatePreferences.json file is an invalide json file.
And in this case SketchUp reset it totally on startup. So in theory this shouldn't happen.

[mauriciobellon]

The strange thing here is that if the settings.materials_last_dir value is not correctly escaped that means that the value is not a valid string and so the entier privatePreferences.json file is an invalide json file. And in this case SketchUp reset it totally on startup. So in theory this shouldn't appear.

Hadn't seen that you are already treating for errors in read_default definition. :)

And in this case SketchUp reset it totally on startup. So in theory this shouldn't appear.

Didn't know that, you are right it should never happen.

I will make some more tests to try to reproduce the error and see if we can identify where it goes wrong.

[bbeaulant]

Hadn't seen that you are already treating for errors in read_default definition. :)

I did it one hour ago after reading your message :)

[mauriciobellon]

And that could explain why I didn't see it. :))) Should've looked at your commit reference.