.get_element_value with radio button sets

Dan Rathbun

You likely would to put your HTML file within the specific plugin subdir, and give it a unique name (within that plugins names of dialog files, ie: "options.html"
So I changed the set_file argument to: File.join(File.dirname(__FILE__),'options.html')

Here is a Ruby-side example that should help debug things:

This assumes you set unique id for the radio buttons, as I suggested above.

module SDM

  module SomePlugin
  
    @@debug = true # set false when done debugging
  
    class << self # anonymous singleton proxy class
    
      def init_vars()
        @dialog = nil
        @align  = "top"
        @space  = "left"
      end
      
      #  checkstate( value )
      #
      def checkstate(value)
        if value == "true" || value == "checked"
          return true
        elsif value == "false" || value == "unchecked"
          return false
        end
        return nil # default
      end # checkstate()
      
      #  options_dialog()
      #
      def options_dialog()
        #
        unless @dialog # Create dialog instance ONCE (nil evals to false)
          #
          @dialog = UI;;WebDialog.new("Options")
          @dialog.set_file(File.join(File.dirname(__FILE__),'options.html')
          #
          @dialog.add_action_callback("sdm") {|dialog, params|
            #
            # user clicked "Enter" button
            #
            topX = dialog.get_element_value("Top-X")
            ctrX = dialog.get_element_value("Ctr-X")
            leftZ = dialog.get_element_value("Lft-Z")
            ctrZ = dialog.get_element_value("Ctr-Z")
            #
            if checkstate(topX)
              @align = "top"
            else
              @align = "center"
            end
            if checkstate(leftZ)
              @space = "left"
            else
              @space = "center"
            end
            @dialog.close() # close the dialog
            #
            # debugging
            if @@debug
              puts "Callback from options_dialog() returned;"
              puts "  User clicked the 'Enter' button."
              puts "  Returned params = '#{params}'"
              puts "  Element values after;"
              puts "    Top-X = #{topX.to_s}"
              puts "    Ctr-X = #{ctrX.to_s}"
              puts "    Lft-Z = #{leftZ.to_s}"
              puts "    Ctr-Z = #{ctrZ.to_s}"
              puts "  @var values after;"
              puts "    @align = #{@align}"
              puts "    @space = #{@space}"
              puts()
            end
            #
          } # end callback
          #
        end # dialog creation
        #
        # show the options dialog if needed
        if @dialog.visible?
          @dialog.bring_to_front()
        else
          RUBY_PLATFORM =~ /(darwin)/ ? @dialog.show_modal() ; @dialog.show()
        end
        #
        # debugging
        if @@debug
          puts "Method options_dialog() called;"
          puts "  Element values before;"
          puts "    Top-X = #{@dialog.get_element_value('Top-X').to_s}"
          puts "    Ctr-X = #{@dialog.get_element_value('Ctr-X').to_s}"
          puts "    Lft-Z = #{@dialog.get_element_value('Lft-Z').to_s}"
          puts "    Ctr-Z = #{@dialog.get_element_value('Ctr-Z').to_s}"
          puts "  @var values before;"
          puts "    @align = #{@align}"
          puts "    @space = #{@space}"
          puts()
        end
        #
      end # options_dialog()
    
    end # proxy class
    
    # define module methods here prefixed with self.
    
    # RUN ONCE CODE
    unless file_loaded?(File.basename(__FILE__))

      init_vars()
      
      # create menu item and/or toolbar command here
      # whose execution proc is; { options_dialog() }
      
      # register file as already loaded;
      file_loaded(File.basename(__FILE__))

    end
  
  end # module SomePlugin

end # module SDM

sdmitch

Sorry Mr. Fullmer, wrong Chris. It was an example by Chris Phillips.

Dan, thanks for the code. I believe the "verysimple" code is just what I needed but I'll keep yours just in case.

Dan Rathbun

@sdmitch said:

Sorry Mr. Fullmer, wrong Chris. It was an example by Chris Phillips.

Hey Chris you've got name recognition!

@sdmitch said:

Dan, thanks for the code. I believe the "verysimple" code is just what I needed but I'll keep yours just in case.

Found it http://sketchucation.com/forums/viewtopic.php?f=180&t=2606&p=12180&hilit=+very+simple+webdialog#p12180

That post is 5 years old. And it has some problems... the reference to the dialog is a local var of the method, and will go "out of scope" when the method returns. And the dialog will disappear (get garbage collected by Ruby.)

My example does much the same thing, but is written properly wrapped, using proper instance vars, and only creates ONE dialog instance, that is reused again.

The major difference is his immediately sends change notification back to the Ruby-side, without waiting for the user to confirm their changes by clicking "Enter".

What if they change their mind, and cancel the dialog instead, but after they have already changed a few controls ? They will expect that the changes should not take effect! .. and they really should not.

Anyway .. find some happy medium between the two. And enjoy!

Dan Rathbun

Reprise: Actually there are two kinds of WebDialogs that plugin authors create:

A standard options dialog that has an "OK" (sometimes named "Apply") button, along with a "Cancel" button.

This type does not apply the changes unless the user clicks the OK/Apply button.

A "toolwindow" style (aka "inspector",) dialog in which the control changes take immediate effect.

This type usually does not have buttons. The user closes the dialog when they are done by clicking the "X" button at the top-right of the window frame. Occasionally (if there is space,) a close button at the bottom of the dialog is provided. But most users would prefer such "toolwindows" to be as small as possible, as they will be floating open whilst they are working with the model.
The latter perhaps is what Chris Phillips actually wanted, which is why he wrote the Js function to immediately return the value changes to the Ruby-side.

So, Sam, you need to decide which of the two types you want for your plugin.

sdmitch

Dan, Since it turned out simple enough to "decode" the parameters string, I did away with the "verysimple" approach and went the conventional update on submit.

When starting the plugin, the webdialog created has focus. Is there a way of giving the focus back to the model without having to click the wheel button?

Dan Rathbun

@sdmitch said:

Is there a way of giving the focus back to the model without having to click the wheel button?

No current cross-platform method in the API. It has been requested, along with onFocus & onBlur observer callbacks.

Normally you could call in JS, %(#8000BF)[window.opener.focus()], but in the Microsoft WebBrowser Control interface, the %(#8000BF)[opener] window object is not exposed (presumably for security reasons?)

There is no API method that currently returns a handle to SketchUp's application window either, so you cannot have the html page tell the Ruby-side that the DOM loading is complete, and have the Ruby-side set focus back to the app. This has also been requested.

There are low-level solutions, on PC, using "Win32API.so", check the forum, ThomThom and I, and driven all discussed it. There's a topic labeled "Get Sketchup window handle" or similar.

sdmitch

Dan, Just as I expected but not a big deal.

Thanks.

driven

Sam,
T think you may want window_blur http://sketchucation.com/forums/viewtopic.php?f=180&t=49075&p=441642&hilit=.window_blur#p441398
but maybe not...
john

sdmitch

John, I tried the .show_modal and, just like the API said, nothing is allowed to happen as long as the WebDialog is displayed. I couldn't figure out how the hide it and then bring it back to make a change to the options selected.

driven

sorry sam, I'm on a laptop without access to all my test snippets so I pointed that one...

the show_modal is for my mac, works with show on PC's

these test are probably what I should have pointed to
http://sketchucation.com/forums/viewtopic.php?f=180&t=49075&p=441642&hilit=.window_blur#p441326
you can call focus or blur whenever you want, the dialog dosn't need to be focused to use them...
1ohn

Dan Rathbun

@Sam:

(1) It would help if you put your OS, and SketchUp Free vs Pro, into your profile, so it appears at the left of your posts.

That way people would not purposely point you towards a method that was specific to an OS that your not developing on / for.

(2) Have another look at the example I wrote for you. It does exactly what you just described. (And uses a platform conditional statement to call the correct show method.)

Keep in mind you need to hold the option refs as @vars on the Ruby side, and restore them to the dialog's controls after each show (because the HTML file is reloaded.)

Ie.. closing the dialog with close() does not destroy it. It is still a valid object, just as it was after you created it, but before it was shown for the first time.

jolran

Hi!

In John/driven's example he uses dlg8.set_html(html) with a Ruby "inline" HTML codestring. That works on Mac? I thought set_html() was to be avoided?

So doing like that and putting in an image for button like below would work on Mac?

In Ruby..
my_icon=File.join(File.dirname(FILE), "folder/myicon_pic.png")

( In the HTML wrapped something like html = %[html + js code etc...])

Have an image as a button:
<img src="#{my_icon}" width="24" height="24" onClick="jsfunction()">

Note, Im not using a separate Html file in this case.
I think Adam is doing something similar in Goldilocks, but uses URL if I remember it correct.

Hope I'm not hijacking the thread, thought it was relevant.

driven

@jolran said:

Hope I'm not hijacking the thread, thought it was relevant.

Hi jolran,
I agree, however there's a specific thread I started on the subject http://sketchucation.com/forums/viewtopic.php?f=180&t=49338#p443472
try those test files on your mac... I have others as well, that work for me.
john

thomthom

@jolran said:

So doing like that and putting in an image for button like below would work on Mac?

It used to work, then it didn't. Then it might be working for some. But not me.
I wouldn't rely on it.

jolran

Ahh, I see John. If I get it right the sethtml thing is working cause of updated Mountain Lion?

Thomthom, I have been searching through threads where you discuss just this issue, thats why I also asked this question. Being not confident in Webdialog, the platform issues are a bit confusing sometimes. But I take your word for it and try to fix it with set_file instead.
Thanks.