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

thomthom

I do have an experimental hack to catch all menus, commands and toolbar items that's created. I hope to tind time soon to put together a basic version of a plugin that let you quickly search and filter out available commands.

Dan Rathbun

@thomthom said:

@honoluludesktop said:

but will the result permit toolbars to unfold perpendicular to the edge of a sketchup window like the menus do?

You mean toolbars where you click on a button and it displays a dropdown list of more buttons?

These are called "Flyout Toolbars" and have been a part of the AutoCAD GUI since at least R13 (circa 1994) and perhaps even R12 in Win16 mode.

This is one of the things on my to do list for Win32 Sketchup.

thomthom

@thomthom said:

Just came across a nice API call that will be useful for creating webdialog toolbars:
http://social.msdn.microsoft.com/forums/en/csharpgeneral/thread/e7fef568-2c0b-41eb-9785-304f84d03819/#bf79c87e-ef49-456f-a485-aa767d841d20

One can use WS_EX_NOACTIVATE to prevent a window from catching focus - but from what I understand it'll still allow interaction events. I'll try it out as soon as I get home.

Just had a go at this. I could not get a webdialog to not get any focus when I set WS_EX_NOACTIVATE - but I could make a Notepad window to change. I don't understand why.
When I check the EX_STYLES of the webdialog the WS_EX_NOACTIVATE bits appear to be set.

Dan Rathbun

WebDialogs are child windows of the SU app window.

The Notepad window is a toplevel window.

thomthom

Does that matter?
Floating toolbars are also child of the SU window...

thomthom

Sidenote: Win32 - Get SketchUp Window Handle

Dan Rathbun

@thomthom said:

Does that matter?

Well.. you you didnt understand why...
I propose the flag acts differently for child windows versus toplevel windows.

.. it's the only difference I can see at first glance.

thomthom

Yea, I was looking at that myself, but when comparing to the floating toolbars I could not see any significant difference. But I'm not that familiar with Win32 API.

driven

@thomthom said:

One can use WS_EX_NOACTIVATE to prevent a window from catching focus - but from what I understand it'll still allow interaction events. I'll try it out as soon as I get home.

hi Thomas,

been trying to make a 'nice' Mac toolbar in a WebDialog, and discovered that if you hold down the cmd key (i.e. before clicking the tool icon) you don't move focus and the tool (and cursor image) is there immediately on mouse-out.
This is one click LESS than on a standard mac SU toolbar icons as I don't have to click back into the model space to activate the cursor.... (command clicking SU toolbar icons does the same thing, as well)
so, question is, do you have a snippet that will send a cmd_key_down on mouse-over of the WD?

john

thomthom

@driven said:

been trying to make a 'nice' Mac toolbar in a WebDialog, and discovered that if you hold down the cmd key (i.e. before clicking the tool icon) you don't move focus and the tool (and cursor image) is there immediately on mouse-out.
This is one click LESS than on a standard mac SU toolbar icons as I don't have to click back into the model space to activate the cursor....

Are you saying that clicking a native toolbar button in SU steals focus from the main window? (I need to unpack my Mac from my moving-boxes to have a look at this.)

@driven said:

so, question is, do you have a snippet that will send a cmd_key_down on mouse-over of the WD?

I've never developed for OSX - so this is unknown territory for me. But will you even be able to receive mouse events if the window haven't got focus?

driven

@thomthom said:

@driven said:

Are you saying that clicking a native toolbar button in SU steals focus from the main window? (I need to unpack my Mac from my moving-boxes to have a look at this.)

NO, sorry, I just rechecked, I've got 'standard' icons in WebDialogs that I'm doing tests with, they behave the same as 'ruby' icons in the same WD...

standard toolbars DO NOT highlight the box or such, and DO an instant tool-change,

unlike

the standard WD which requires
1st click on dialog to highlight/focus box
2nd click on icon to select manipulation tools or send action direct (undo, redo, etc...)
3rd click on drawing space to reveal cursor (and select first point) if manipulation tool

unless
you hold down the cmd key before clicking....

the WebDialog then behalves the same as 'standard' toolbar, and you can also change tabs, access drop-down menus, select tools etc... all without drawing focus away from drawing window... but you have to hold the cmd key the whole time...

if the web dialog sent a function call to hold the cmd key down on mouse-over, then you'd have a useful tool window...

hope that clarifies what I'm asking/saying/thinking.....

clear as mud

john

thomthom

Understood.

This OSX behaviour of dealing with windows is causing my little greys to twitch in pain - my BezierSurface plugin was suppose to use WebDialog toolbars and windows extensively. Now I need to find a way to handle this or scrap the UI (which I've written a great part of the framework of already and find a new solution.)

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.

driven

@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.

Thom,

I just did a scan of the different windows used in SU, what features do you want enabled/disabled in your WebDialogs?

I'm having a look at UI.Browser.app to see if I can use that to tweak SU windows...

john
UI reports

thomthom

@driven said:

I just did a scan of the different windows used in SU, what features do you want enabled/disabled in your WebDialogs?

What I would like to be able to do is:

Change the window frame style to toolwindow
Allow the user to only click once to activate the UI elements in the webdialog (as oppose to click to give focus, click again to activate UI element)
Be able to activate by click the UI elements in the webdialog without taking focus from the SU window.

thomthom

@driven said:

[attachment=0:4644llpu]reports_Mac_SU_UI-Elements.zip[/attachment:4644llpu]

I get errors when I try to unzip that file. Both Windows and WinRar reports errors.

driven

@thomthom said:

1 Change the window frame style to toolwindow]

you can see in the reports that there's more than one version of 'toolwindow'

@thomthom said:

2 Allow the user to only click once to activate the UI elements in the webdialog (as oppose to click to give focus, click again to activate UI element)

some of the native toolwindows require this, sometimes??? model info for example

@thomthom said:

3 Be able to activate by click the UI elements in the webdialog without taking focus from the SU window.

Can be achieved on all by holding down cmd key, so I'm looking for adding an applescript to do that on hover/mouseover

try this zip...stuffit or I'll pm a link

john

thomthom

I still get errors.

thomthom

I think the files extracted after all, despite the errors.

driven

@thomthom said:

I think the files extracted after all, despite the errors.

so you have them? do they make sense...

I did some more and now I'm trying to work out if I can make changes...

I've got apple script launching things from inside SU so now I need to see if it can modify window element attributes or something...

thomthom

I'm not entirely sure I know what I'm looking at. Where does this data come from?