UI.openpanel and UI.savepanel interference on Mac?

Developers Ruby API
1

I’m working on an extension that uses UI.openpanel and UI.savepanel to let the user choose a file in which to save data. I also use the old jf_ruby_panel to select and load files while testing. It seems that that extension’s use of UI.openpanel conflicts with mine in that they each change the folder that actually gets opened, ignoring the one specified in the arguments to UI.openpanel or UI.savepanel. This is especially perplexing because the interaction is between completely separate extensions, as if either Ruby or macOS is saving state somewhere.

Before filing an issue in the github tracker, I am posting here to ask if this is a known or expected behavior on Mac (I know the filter strings don’t work on Mac) or perhaps something I am doing wrong.

1 Like
2

I am not sure if MacOS saves previous paths, but Windows does.

Windows saves what it calls MRU (Most Recently Used) paths for each filetype in the registry.
Because the Ruby API on Windows uses the common dialog library (comdlg32.dll) the file browse dialogs via UI will use the MRU paths if:

  • the 2nd arg is only a wildcard pattern and no 3rd path arg is included
  • the 2nd arg is only a wildcard pattern and the 3rd path arg is ""
  • the 2nd arg is "" and the 3rd arg is only a wildcard pattern

So for example, if I use:
UI.openpanel "Pick a file...", "*.rb"
it opens in my C: drive user "Documents" path. But then if I navigate to my D dive "Projects" folder and pick a rb file, then do the same command, the 2nd time it opens in the D: drive "Projects" folder.

So all these have the same effect, using the registry’s MRU value for the .rb file type:

UI.openpanel "Pick a file...", "*.rb"
UI.openpanel "Pick a file...", "*.rb", ""
UI.openpanel "Pick a file...", "", "*.rb"
UI.openpanel "Pick a file...", "", "Ruby files|*.rb;"
UI.openpanel "Pick a file...", "", "Ruby files|*.rb;||"

But this will only partially work:

UI.openpanel "Pick a file...", "D:/Documents/*.rb"
UI.openpanel "Pick a file...", "D:/Documents/*.rb", "*.rb"

… in that the correct path is opened, but the filetype filter acts as "*.*" and the old Windows bug reoccurs where "_.rb" appears in the File name: edit box.

The API docs do not inform coders of these quirks.
And I would not be surprised if there are also quirks on MacOS platform.

3

I cannot find that script anymore, but there is a thread for a newer extension that was Windows only.
[Plugin] Ruby Toolbar • sketchUcation • 1
The change log for this extension mentions that it needed to be rewrapped in it’s own namespace module. This implies that the older script was not and might cause conflicts.

Since Jim deleted his old Google Sites repository we cannot get that old script unless you know where it is posted at SCF ?

4

Actually I just found an edition named "rubytoolbar.rb" that has modifications by both Fredo and you Steve. The code is wrapped in a JF_RubyToolbar namespace.

It is supposed to have an icon files along with it but it was just an orphan file all by itself.

5

Here’s the relevant snippet from the rubytoolbar.rb version I have:


  #Load a script file - if <file> is nil, open the dialog panel to select the file
  def self.load_script(file=nil)
    file = UI.openpanel "Load Script", @last_dir unless file
    return unless file
    begin
      load file
      Sketchup.set_status_text "#{File.basename(file)} loaded (#{Time.now.strftime('%H:%M:%S')})"
      @last_file = file
      @last_dir = File.dirname(file) + '/'
      @last_dir.gsub!("/", "\\\\") unless @is_mac
      @cmd_reload.status_bar_text = @cmd_reload.tooltip = "Reload Script: " + File.basename(file)
    rescue
      UI.messagebox("Couldn't load #{File.basename(file)}: #{$!}")
    end
  end

Note that is enclosed in the JF_RubyToolbar module, whereas my usage is in JWM_Plugins module (actually a few levels nested below that). So aside from a Ruby API or macOS leak akin to the MRU you discussed, I don’t see how one could legitimately affect the other. But they do.

6

This (the omission of a filetype) is going to be an issue on Windows where the MRU path the system gives the openpanel dialog will come from the "*" entry in the registry. Which basically means any filetype without specific entry.
This means that the path could have come from some very old use of the dialog when it was last given a "*.*" type.

The file version I have has “Tuesday, ‎November ‎26, ‎2013, ‏‎10:16:53 AM” as a mod date and gives a file type:.

    file = UI.openpanel "Load Script", @last_dir, "*.rb*" unless file

This is a bit weird as later the method uses the global load method instead of Sketchup::load.
Trying to load a rbe for example would not work with Kernel#load.

I suggest that this line use the "*.rb" filetype filter.

A separate thing is that I think I remember Jim playing around with a double-click on one of the toolbar buttons to set a default path.

But this script is going to predate the addition of UI::select_directory (v 2015,) as it was updated during the v2014 beta that added the Sketchup::Console class.

I see that for Windows it is setting @last_dir to $:[0] + '/', which is:
C:/Program Files/SketchUp/SketchUp 202x/Tools/RubyStdLib/

This is likely now undesirable. As said above, if the last path is "" empty string, then Windows will use the last path for the filetype. So leverage the system and add the "*.rb" filetype.

Also Ruby 2.x+ wants all instance variables predeclared before use like class variables always needed. Failure to do so outputs warnings or errors to the console.

One example is @last_file which should be now predefined as nil at least.

So does the weirdness go away when JF’s "rubytoolbar.rb" is not loaded ?