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?
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?
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.
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.
Here are screen shots and code snippet
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
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
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.
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)
I think I solved it. Don’t specify height in the body html tag.
[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.
[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.
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.
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
@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
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:
@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
@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.
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.
2 Likes