[code] Win32 Moving/Showing/Hiding Toolbars and Dialogs

thomthom

@jim said:

<body onMouseOut ="window.blur()">
On Windows, it sends the main SU window and everything else to the back.

How odd...

Dan Rathbun

@dan rathbun said:

mouse moves into toolbar webdialog setting window.event.ctrlKey=true (and possibly dialog focus via body onMouseOver.

Will the mouse event trigger when the webdialog haven't got focus?

it DOES on Win32 w/ IE 7

driven

hi Dan, Thom, Jim, all

I've been trying all sorts of things to 'avoid' giving the WebDialog 'focus' while still having it send actions.
this is what happens with SU native NSPanels (used for SU toolbars) and also for some of the NSWindows used for different preferences and the NS(WebView)Window used by Instructor, but not the NS(WebView)Window used by WebDialog.

holding down the "cmd"(apple) key, invokes this behavior (no focus, but active) on any window/panel inside

so far the best/simplest way I've come up with is add to an 'aid memoir', using background colours and text..... but I'll keep trying

john
for now??

Dan Rathbun

@thomthom said:

@jim said:

<body onMouseOut ="window.blur()">
On Windows, it sends the main SU window and everything else to the back.

How odd...

yea I tried with a modified test dialog John sent me (I added buttons and some key displays.)

SelectionInfo.zip

Dan Rathbun

Hey John ... you talk about NS windows made me think of the 9th arg to WebDialog.new
:mac_only_use_nswindow

You might need to use a settings Hash to use it. If you do, the key for the 3rd arg is :preferences_key not 'key'

You should also use Symbol keys not String keys, as the Hash argument is cranky.

thomthom

@dan rathbun said:

it DOES on Win32 w/ IE 7

Yea but windows doesn't have the click-through issue. I was thinking since click events would not register under OSX until the window had gotten focus, then maybe mouse events would not trigger either.

...I really need to find that box with my Mac... ...ugh, the hurdles of moving...

driven

an update,

holding the cmb key down is great for tool swaps and input button clicks, but locking it down means you can't use numerical input boxes...

I didn't realise that cmd 1,2,3,4,5,6,7,8,9,0 are all shortcut keys, so holding down the key manually is the best option....

john

Dan Rathbun

@thomthom said:

I've been searching for ways to manipulate windows under OSX like one can do under Windows with the Win32 API - but I never find anything.

RubyCocoa
it's included with OSX since v10.5 “Leopard” ??

EDIT: Here's the RubyCocoa SourceForge page.

I've seen Ruby scripts that had: require 'Cocoa' or similar at the top.

There is a potential pitfall looming for Sketchup cross-platform scripting, in that Apple intends to replace MRI Ruby, with MacRuby. It would not be bad if we had all the same UI classes in a "WinRuby" that MacRuby has.

thomthom

Ok - something to look into. I hope that allows you to modify existing windows, not sure create your own. (Though creating your own would be cool too.)

thomthom

@dan rathbun said:

There is a potential pitfall looming for Sketchup cross-platform scripting, in that Apple intends to replace MRI Ruby, with MacRuby. It would not be bad if we had all the same UI classes in a "WinRuby" that MacRuby has.

mhm - some wrapper to bridge it all.

Dan Rathbun

@thomthom said:

@dan rathbun said:

There is a potential pitfall looming for Sketchup cross-platform scripting, in that Apple intends to replace MRI Ruby, with MacRuby. It would not be bad if we had all the same UI classes in a "WinRuby" that MacRuby has.

mhm - some wrapper to bridge it all.

Yes the 'wrappings' would need to follow (as closely as possible,) those defined in HotCocoa for MacRuby.

Note that in the example on the HotCocoa introduction page, they are showing the use of a window() constructor method. What they don't actually show is that farther up at the beginning of the Ruby module block, is that there must be an include HotCocoa (or some other mixin module,) that brings that window() method into the current namespace. I usually don't like to do this, instead prefering to call the method using fullnamespace qualification. Less chance then of an accidental override of methods that are imported into your namespace. In this example, I would probably wish to have a window() method in my namespace that returns the instance handle to the window object (@win,) so I'd think most times it's not really that convenient to include entire complex libraries, into a custom namespace.

pcarret

Everything is fine under MS-Windows, but :

Is it possible to do hide minimize, maximize andclose buttonon Mac OS ?

I found NSMiniaturizableWindowMaskbut I don't know how to access system API under Mac OS

Remark under windows : WS_MINIMIZEBOX and WS_MAXIMIZEBOX can't work separately

simplified working code is (must have hwnd handle, constant and win32 method declaration) :

style = GetWindowLong.call(hwnd, GWL_STYLE)
style = style & ~WS_MINIMIZEBOX
style = style & ~WS_MAXIMIZEBOX
result = SetWindowLong.call(hwnd, GWL_STYLE,  style)

Thanks for any answer.

Philippe