Sizing Webdialog


#1

I’m having trouble sizing web dialogs. I’m using Komposer which gives me the size of the dialog in pixels. And I size the dialog using dialog.set_size(width,height) but can never seem to get it right. They either end up with a lot of space on right and bottom or I end up with a scroll bar. I have to use trial and error, a lot of error. Any tips?


UI::WebDialog position and location methods (from DC extension.)
#2

I think there are platform differences here. Under Windows it’s the outer window frame, but on OSX I think it sets the client size if I recall…

Got any concrete code examples? Screenshots?


#3

I have not figured out a pattern to the sizing. Komposer tells me a size say 800x400. I try to set the size using Ruby API dialog.set_size(800,400). But the dialog is too small, scroll bars show up right and bottom. So I increase the set_size slightly say 810x410. Suddenly there is a lot of space on the right and bottom and no more scroll bars. Reduce it a little and I don’t see any change until suddenly it falls back to the scroll bar situation. Each of my dialogs are built the same way using Komposer but each one acts differently. Sometimes the right and bottom edges are set appropriately (to my taste). Sometimes I can never get it right.

I’m not sure how to prevent the sizing saved to Windows registry. Its not clear what “preference_key is not included” means. That may be part of the problem.


#4

Yea, if you want to ensure a fixed size you need to also call webdialog.set_size to make sure the dialog doesn’t restore some old value.

It would really help with a code snippet so we can be sure we’re seeing the same thing.


#5

Here are screen shots and code snippet

Kompozer screen shot

Sketchup screen shot

Code snippet:

class WizViews
attr_accessor :currentView    
def initialize
    begin
        @currentView = "3D Default View"
        @oDialog = UI::WebDialog.new("Views", false, "WizViews", 1, 1, 1,1, true)
        @oDialog.add_action_callback("getQuery") do |dDialog,actionName|
            puts actionName
            aValues = actionName.split('|')
            case aValues[0]
                when 'getViews'
                    js_command = "setViews('"+self.getViewsString+"')"
                when 'getView'
                    js_command = "setView('"+self.getViewString(aValues[1])+"')"
                when 'addView'
                    self.addViewStringArray(aValues)
                    js_command = 'success()'
                when 'currentView'
                    @currentView = aValues[1]
                    setView
                    js_command = 'success()'                    
                when 'cancel'
                    dDialog.close()
                    js_command = 'success()'
                else
                    js_command = 'success()'
            end
            puts js_command
            dDialog.execute_script(js_command)
        end
        htmlPath = Sketchup.find_support_file "WizViews.html" ,"Plugins\\WizApp\\Dialogs"
        @oDialog.set_file(htmlPath)
        iWidth = 840
        iHeight = 440
        @oDialog.set_size(iWidth,iHeight)
        suView = Sketchup.active_model.active_view
        @oDialog.set_position(Integer((suView.vpwidth-iWidth)/2), Integer((suView.vpheight-iHeight)/2))
    rescue Exception
        wizCaller
    end
end

def show
    begin
        @oDialog.show()
    rescue Exception
        wizCaller
    end
end

end


#6

ThomThom’s “WebDialogs: The Lost Manual”

Explains how to turn off the scrollbars in the MSIE WebBrowser control.
I also think the last argument sizeable should be false


#7

When there is only little overflow (1px), the browser concludes that scrollbars are needed, and they cover further >15px. That is why you noticed that it “jumps” depending on only little changes in width.

You can turn scrollbars off with the “scrollable” argument. If content overflows, it would just hide behind the right/bottom edges of the dialog.

I would not disable “resizable”, because when hard-sizing a webdialog but not hard-sizing the fonts (px), you get issues with dpi: relative font sizes (no size set, or pt or em sizes) will follow the user’s dpi and for whatever reason some people have awry dpi like 144/150%, 125%. In that case, the user could at least resize the dialog to read it completely.


#8

Actually if I turn scrollbars off I still get scroll bars.

I’ve been playing with the different options of dialog.new trying to figure out the right combination. If I set iHeight to 440 I get a lot of space both right and bottom. I reduce to 430 and get scroll bars right and bottom. It seems no matter what I do it doesn’t work.

        iWidth = 840
        iHeight = 430
        @oDialog = UI::WebDialog.new("Views", false, "WizViews", iWidth, iHeight, 0, 0, false)

#9

I think I solved it. Don’t specify height in the body html tag.


#10

[quote=“thewized, post:8, topic:2175, full:true”]
Actually if I turn scrollbars off I still get scroll bars.[/quote]
Someone did not read the Lost Manual, and see that the scrollbars argument, of UI::WebDialog::new() has never worked on the MS Windows edition of SketchUp.


#11

[quote=“thewized, post:9, topic:2175, full:true”]
I think I solved it. Don’t specify height in the body html tag.[/quote]

Actually do not specify any inline styles in html tags. They are deprecated, and perhaps even not allowed in strict standards mode.

Instead use an inline stylesheet (a <style> element,) in the <head>, with a body { } section. Or create a class, and assign that class to the <body> element.


#12

Remember when you specify width and height in CSS that padding and border width is added to the dimensions in the default box model. Margins can also affect things.

Using overflow: none; is a good way to protect against unwanted scrollbars.


#13

Be aware that indeed on windows the set size is the size with the border and the size of the borders isn’t a fixed size. The size is depended on user settings in windows. We use some javascript to find the correct bordersize.

An other problem on is when you change the size of a dialog the fixed position is on mac at the bottom of the dialog and on windows it’s the top. That why we use on mac javascript for resizing the dialog instead of the ruby function.

def set_size(w, h)
  border_height = @webdialog.execute_script("document.getElementById('RUBY_BRIDGE').value = window.outerHeight-window.innerHeight").to_i
  border_width = @webdialog.execute_script("document.getElementById('RUBY_BRIDGE').value = window.outerWidth-window.innerWidth").to_i

  if Skalp::OS == :WINDOWS
    @webdialog.min_height= h + border_height
    @webdialog.max_height= @webdialog.min_heigh
    @webdialog.min_width = w + border_width
    @webdialog.max_width = @webdialog.min_width
  else
    @webdialog.min_height= h
    @webdialog.max_height= h
    @webdialog.min_width = w
    @webdialog.min_width = w
  end

  x = w + border_width
  y = h + border_height

  Skalp::OS == :MAC ? @webdialog.execute_script("window.resizeTo(#{x},#{y})") : @webdialog.set_size(x,y)
end

#14

@Guy this is really old, but as you’ve responded and I have a current query from elsewhere…

how do you set position on a mac to correspond to the User moving the dialog?

I know it fine per session, but the ‘User’ wants it to work like on a PC and re-appear where he left it in a prior session…

john


#15

We ask the position with javascript and store it in the registry with
Sketchup::write_default read_default and reposition it on Startup.

Op vrijdag 6 februari 2015 heeft John Drivenupthewall no-reply@sketchup.com
het volgende geschreven:


#16

@Guy
cheers, it’s how I had responded, but was hoping for an even simpler solution…
if not using an onClick save position button, setTimeout watching for changes can be expensive…
john


#17

@john_drivenupthewall
I have set it on a onblur event in javascript. You need to get focus to change the position of a dialog so there will be a onblur event when you leave the dialog after dragging. This is less expensive as a timer and more better then a save button.


#18

Kinda an old optic but still relevant. Pity a get_size hasn’t been implemented in the new html dialogs. That would have made coding much simpler - even more if you need it to be cross platform.

For instance: if your html dialog has different modes and you want to (temporary) change its size, you still have to add lots of extra ruby-javascript routines just to find out the size of the current window (user could have resized it to custom preference), do a resize and afterwards size it back to the previous (custom) size.

Would be so much simpler if it could be just a wd.get_size and the start of the routine and wd.set_size at the end again.