Webdialog position not preserved across session on MAC

thomthom

oops - small typo in my sample there. I normally use a hash to create dialogs.

fredo6

Hi again,

Is this problem on Mac confirmed, even with the M1 of SU8?

Apparently, there is a thread running in parallel on Google Sketchup Developers forum (initiated by Jonathan Winterflood) about the same problem.
http://groups.google.com/group/sketchupruby/browse_thread/thread/acd135fbdff21068

From what I read, there does not seem to be a solution.

Fredo

jeff hammond

yeah, the same thing happens in the latest update.. the web dialogs won't remember their positions..

fwiw, here's the su .plist which shows a lot of the stuff that is remembered across session.. i doubt it will be of much help but it may lead to some sort of solution?
com.google.sketchuppro8.pdf

.

Dan Rathbun

@unknownuser said:

on MAC, it seems that the position of web dialog are not saved across SU sessions, whatever you put in the regkey parameter (the 3rd one in the new method).

Am I the only one to notice this?

No. Jonathan Winterflood posted a topic on GoogleGroups about this:
Webdialog position/size and pref_key on Mac OS X

Dan Rathbun

Hey there IS a weird thing I noticed with SU 8 ...

I involves the positions of both WebDailogs AND UI.messagebox (which I don't remember happening on v7.x)

Say I display a WebDialog at 0,0
Then I create a UI.messagebox, .. it displays over the top of the Webdialog (as if it's trying to center itself on the WD.)

If I repeat this but move the WD somewhere else, the messagebox seems to follow the WD.

But if you don't have a WD (or reverse the order of the calls,) the messagebox centers on the Sketchup window.

Is this behaviour new?

I can see a benefit to this, but the UI.messagebox method needs another argument " owner" that defaults to the Sketchup app window. Then if we want our webdialog to "own" a messagebox, we add the 3rd arg which is the WD instance.

And yes TIG, I know we can use alert and open to make JS dialogs, but the above is easier, as it's already on the Ruby side. IMHO

thomthom

That's interesting.
Do the webdialog have focus when UI.messagebox is called? In which case it would seem that it uses GetActiveWindow for its owner.
...in which case, if you used a timer to delay a messagebox and set focus to one of the tool windows it should focus on them...

Dan Rathbun

@thomthom said:

Do the webdialog have focus when UI.messagebox is called? In which case it would seem that it uses GetActiveWindow for its owner.

Yes the messagebox follows the active window. You can test it yourself by moving the Console (adjust it so it's small.)
When it has focus type: UI.messagebox("Test")
Close it, move the Console, press the up arrow, and ENTER.

@thomthom said:

...in which case, if you used a timer to delay a messagebox and set focus to one of the tool windows it should focus on them...

Unfortunately, WebDialogs are not created with JS open function, so window.owner is invalid for the Sketchup App window from within a WD.

Now close completely the Layers Window.
In the Console type (all one line.)
UI.show_inspector "Layers"; UI.messagebox("Test")

Weird huh?

driven

@dan rathbun said:

Unfortunately, WebDialogs are not created with JS open function, so window.owner is invalid for the Sketchup App window from within a WD.

hi Dan,

Does this mean that Mac WebDialogs arecreated with JS open function, this is what it say's on the can.

If so what advantage might that give?

and would this be part of the mac_only_use_nswindow?

John

Dan Rathbun

John .. I boo-booed. I meant to write window.opener for the DHTML/JS property. ("owner" is a system API term/property of window objects, at least on Win32.)

This opener property is read/write, but may be a MSIE only feature, viz:

@unknownuser said:

(http://msdn.microsoft.com/en-us/library/ms534309(v)":22mneg1n]Standards Information

There is no public standard that applies to this property.

It usually says this when it's something Microsoft has addded or "invented" that is not defined in the W3C standards. (Otherwise it gives a link to the actaully HTML or CSS standard or specification at the W3C website.)

The only way to know if Safari has "adopted" it, is to try it out on Safari and see if you get a scripting error. There is a JS script example on that opener Property reference page you could try.. and let us know if it works.

On the page for the [window.open](http://msdn.microsoft.com/en-us/library/ms536651(v) method, at the bottom in the page forum, one of the responders says that this method was "invented" by Netscape (which is now Mozilla.org's 'Mozilla Suite' and 'Firefox'.)

@driven said:

If so what advantage might that give?

If your webdialog instance could "know" what window opened it (it would be the Sketchup main application window,) and you could, after clicking a button, set the focus to the Sketchup app window.

@driven said:

Does this mean that Mac WebDialogs are created with JS open function, ...
Not likely.. they are created by the Sketchup application code calling a system API function or a DLL function, like on Win32 it may be a function exposed in a library file, such as: msie.dll (I remember reading about it, might have a link somewhere... but you should get the point.)

This is why I entered a Feature Request for a new Ruby API method UI.set_window_focus() (or some similar appropriate name.)

Now... some of us DO know how to write that kind of Ruby method but only for Win32. It would not be cross-platform.

To make it cross-platfrom, we would need collaboration with someone who knows Apple Objective-C and how to make either Carbon or Cocoa library calls. This may make it necessary to have a way for Sketchup Ruby to load the RubyCocoa framework.. which might require a special compiled copy of RubyCocoa (installed under Sketchup,) linked to the Sketchup's "private" Ruby framework,.. which is obsolete on Mac. PITA issues to deal with.

OricAtmos

@thomthom said:

Haven't checked it out, but on PC the position is stored between sessions, but not within sessions. If you make a webdialog, close it, then open it again it doesn't remember the last position - only the last position from last session.

Hi,

I know this is an old thread, but I think I found out what makes WebDialogs remember their position during one session on Windows. It seems the position is only ever saved when the WebDialog object is destroyed, not when the dialog is closed while the object still lives. That's it, I think.