You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
(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:
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.
moduleIssue885moduleButtonClickUIclassTestUidefinitialize(modal=true)@ip=nil@dialog.closeif@dialog@dialog=nil@modal=modalenddefactivate@ip=Sketchup::InputPoint.newenddefdeactivate(view)@dialog.closeif@dialog && @dialog.visible?enddefonCancel(reason,view)puts"onCancel called with reason: #{reason}"# Just close the dialog to prevent duplicates:@dialog.closeif@dialog && @dialog.visible?# @dialog will be set nil by it's set_on_closed() proc.enddefonMouseMove(flags,x,y,view)@ip.pickview,x,yenddefonLButtonDown(flags,x,y,view)#returnUI.beepif@dialog && @dialog.visible?#ph=view.pick_helperph.do_pick(x,y)entity=ph.best_pickedifentity.is_a?(Sketchup::Group)thenhtml=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.showendenddefgetHtml()%[ <!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> ]endend# class TestUiunlessdefined?(@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=trueendendend
The text was updated successfully, but these errors were encountered:
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.)
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 a1
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 indeactivate
as in theonCancel
which would be executed had it been called with reason1
: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.
The text was updated successfully, but these errors were encountered: