Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple Issues With UI::HtmlDialog (Qt) #885

Closed
DanRathbun opened this issue Mar 23, 2023 · 2 comments
Closed

Multiple Issues With UI::HtmlDialog (Qt) #885

DanRathbun opened this issue Mar 23, 2023 · 2 comments

Comments

@DanRathbun
Copy link

DanRathbun commented Mar 23, 2023

SketchUp Ruby API Issue

SketchUp Version: 2023

Prompted by forum discussion:
https://forums.sketchup.com/t/focus-error-when-calling-htmldialog-with-show-modal-on-mouse-click/224062

(1) Cannot Use Mouse for Modal UI::HtmlDialog

This includes clicking buttons, navigating to form controls, manipulating controls (drop lists, etc.) clicking any caption bar button or dragging the dialog to a new screen location.

User must navigate form controls using TAB key and there must be a HTML "Close" button in the dialog that hooks to a Ruby callback to call @dialog.close.

As noted in the linked discussion, things will work normally if the mouse is right-clicked which brings up the SketchUp context menu (even if it is the dialog that is context clicked,) and then this erroneous context menu is dismissed, which brings to light subissue 2 ...

(2) Right-click in modal dialog brings up SketchUp's context menu. Even when dialog is outside the modeling area.

Explained above.

(3) When a non-modal dialog is opened from a tool, the modeling area has focus but the dialog is still visible, and the user reselects the same tool from the menu, the onCancel callback does not fire sending a 1 as the reason.

This can lead to ...

(4) When a non-modal dialog is opened from a tool, and then the user reselects the same tool from the menu, a duplicate dialog is opened offset somewhat.

This partly has to do with (3). The fix is to define a deactivate() callback and put the same statement to close the dialog in deactivate as in the onCancel which would be executed had it been called with reason 1:

      def deactivate(view)
        @dialog.close if @dialog && @dialog.visible?
      end

To see behavior (4), comment out the deactivate() method and choose the non-modal command then do so again with the 1st dialog open.


I updated the test code a bit from what was posted in the forum.
To test, create a simple group, activate the tool via the menu items and click the group.

Notice the difference between modal and non-model behavior, with subissues 1 ... 4 as explained above.

module Issue885
  module ButtonClickUI

    class TestUi

      def initialize(modal = true)
        @ip = nil
        @dialog.close if @dialog
        @dialog = nil
        @modal = modal
      end

      def activate
        @ip = Sketchup::InputPoint.new
      end

      def deactivate(view)
        @dialog.close if @dialog && @dialog.visible?
      end

      def onCancel(reason, view)
        puts "onCancel called with reason: #{reason}"
        # Just close the dialog to prevent duplicates:
        @dialog.close if @dialog && @dialog.visible?
        # @dialog will be set nil by it's set_on_closed() proc.
      end

      def onMouseMove(flags, x, y, view)
        @ip.pick view, x, y
      end

      def onLButtonDown(flags, x, y, view)
        #
        return UI.beep if @dialog && @dialog.visible?
        #
        ph = view.pick_helper
        ph.do_pick(x, y)
        entity = ph.best_picked
        if entity.is_a?(Sketchup::Group) then
          html = getHtml()
          @dialog = UI::HtmlDialog.new({
            :dialog_title => "Dialog Example: #{@modal ? 'Modal' : 'Non-Modal'}",
            :preferences_key => "test.issue.885",
            :scrollable => true,
            :resizable => true,
            :width  => 600,
            :height => 400,
            :left => 200,
            :top  => 400,
            :min_width  => 50,
            :min_height => 50,
            :max_width  => 1000,
            :max_height => 1000,
            :style => UI::HtmlDialog::STYLE_DIALOG
          })
          @dialog.add_action_callback('close_dialog') { @dialog.close }
          @dialog.set_html(html)
          @dialog.set_can_close { true }
          @dialog.set_on_closed { @dialog = nil }
          #
          @modal ? @dialog.show_modal : @dialog.show
        end
      end

      def getHtml()
        %[
          <!DOCTYPE html>
          <html>
            <link href="vendor/modus/modus.min.css" rel="stylesheet">
            <body class="m-3 bg-panel-background">
              <form id="dlg-content-area">
                <div class="form-group">
                  <label for="scale">Scale</label>
                  <input type="text" autofocus class="form-control" id="scale" placeholder="1:100">
                </div>
                <div class="form-group">
                  <label for="dpi">DPI</label>
                  <input type="text" class="form-control" id="dpi" placeholder="300">
                </div>
                <div class="form-group">
                  <br/>
                  <input type="button" class="form-button" id="close" value="Close"
                    onclick="sketchup.close_dialog();">
                </div>
              </form>
            </body>
          </html>
        ]
      end

    end # class TestUi

    unless defined?(@loaded)
      tool_menu = UI.menu("Tools")
      tool_menu.add_item("HtmlUI ClickTest: Modal") {
        Sketchup.active_model.select_tool(TestUi.new(true))
      }
      tool_menu.add_item("HtmlUI ClickTest: Non-modal") {
        Sketchup.active_model.select_tool(TestUi.new(false))
      }
      @loaded = true
    end

  end
end
@sketchup
Copy link

sketchup bot commented Mar 24, 2023

Logged as: SKEXT-3668

@sketchup sketchup bot added the logged label Mar 24, 2023
@DanRathbun
Copy link
Author

DanRathbun commented Jul 2, 2023

Note: Opened a new specific issue for (3) where Tool#onCancel is not called for reason 1:

The separate issue is warranted because it is a bug with a different API class than UI::HtmlDialog.
(It is best to keep these issues separate so they can be tracked and fixed separately.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants