Windows: Moving Floating Toolbars
-
-
@jim said:
Just tried experimenting with moving Toolbars in Windows using Win32API library. It works when a Toolbar is floating, anyway. Tyere may be some interesting possibilities for positioning/organizing them, at least when they are floating.
Told ya' so.. told ya' so! ninny-nanny poo poo!
Ref:
@unknownuser said:, in Moving Toolbars responding in topic: Toolbar Registry Hacks":tcehfji3]
Moving Toolbars
In Win32 programming, everything on the screen, is a 'window'. Specifically all items are subclasses of class Window, and inherit base methods, etc. (So even a button is a window, that happens to have an image that makes it look like a button.)Floating: When toolbars are floated, they are basically re-styled as a non-modal dialog subclass; and re-adopted as a direct child of the application window (Sketchup's window.)
So, Jim, you should be able to move them around in the same way you did the Console window, using Win32 API calls.Docked: When docked, they are re-adopted as a child window of the Toolbar Container Window, and restyled so as not to have frames, no caption bar, and add grips. If the caption names are not changed, you may be able to use the same methods you use for moving floating bars, just compensate for the different origins. (Screen origin vs the origins of the individual toolbar containers.)
It only took ya' 8 months to try it.
-
Better late than never?
-
Just playing with a dialog that toggles toolbars on and off. I thought it might be cool if the toolbar was moved near the cursor when opened, and then depending on the tool selected, automatically closed.
-
That's interesting.
I was some time ago using the Win32API to get lists of toolbars in an effort to provide full access to all toolbars. Wanted to make an alternative API.
-
Seems reminiscent of the past Jim ... at least the basic idea ... I remember you felt SU menus could be improved in this way ... maybe more
-
-
@jim said:
Just playing with a dialog that toggles toolbars on and off. I thought it might be cool if the toolbar was moved near the cursor when opened, and then depending on the tool selected, automatically closed.
Localized Toolbar Captions
dc_toolbar_caption = $dc_strings.GetString("Dynamic Components") sb_toolbar_caption = $tStrings.GetString("Sandbox")I was trying to get the actual toolbar object handles for these guys. I can get an array, via:
tba = [] ObjectSpace.each_object(UI::Toolbar) {|o| tba << o }However there is not a .caption or .title getter method, nor apparently even an attribute (instance_variable,) nor local_variable that holds a toolbar title.
IF I make sure that the VERY first and second Ruby toolbars loaded are DC and Sandbox, respectively, then:$Toolbars = Hash.new $Toolbars['Dynamic Components']=tba[0] $Toolbars['Sandbox']=tba[1]Clunky.. but works. Now the Hash can be used to access the UI::Toolbar instance methods. (Later on the $Toolbars hash can be made to point to a @@hash inside class UI::Toolbar where it belongs. And we need a few more instance methods, as well as the constructor being updated to automatically push the objects into the hash.)
-
@chrisglasier said:
Seems reminiscent of the past Jim ... at least the basic idea ... I remember you felt SU menus could be improved in this way ... maybe more
Although we can recreate the menus and dialogs to some extent, there are enough settings which are missing from the API to make the effort frustrating - regardless of how the settings are presented to the user.
-
As do I.
-
@4dhans said:
Just have the DIALOG be the toolbar.
It's JUST not that simple. We know how to make WebDialogs. The workflow of making a webdialog takes alot longer than a toolbar.
We really need the native SU menu and toolbar classes updated.
But yes.. there are folks who like a "toolpanel" such as you demo in your post. But that is not what we are talking about, and is not a solution to missing methods and settings for native UI objects.
But thanks for sharing you nifty "toolpanel" example ... some users may like it.
EDIT: Yours is nice also, Jim.
-
-
Like Dan R. Said
@unknownuser said:Just have the DIALOG be the toolbar.
Scripts by various people. Here is an example below:
-
@dan rathbun said:
@4dhans said:
Just have the DIALOG be the toolbar.
It's JUST not that simple. We know how to make WebDialogs. The workflow of making a webdialog takes alot longer than a toolbar.
We really need the native SU menu and toolbar classes updated.
But yes.. there are folks who like a "toolpanel" such as you demo in your post. But that is not what we are talking about, and is not a solution to missing methods and settings for native UI objects.
But thanks for sharing you nifty "toolpanel" example ... some users may like it.
EDIT: Yours is nice also, Jim.
Oh. Just a little confused about the topic. «
» -
Looks like you might be able to send the Toolbar a message via win32api and make it borderless, get the position, and line them up.
-
There's some pretty neat things one can do with the Win32API. One can even dock windows to the SU window.
There was a guy here that posted images where he'd docked the tool windows to SU's viewport sides.But unfortunately he has not returned with any working samples.
I was thinking it'd be cool to dock webdialogs. Or make them into Toolwindows. -
@jim said:
Looks like you might be able to send the Toolbar a message via win32api and make it borderless, get the position, and line them up.
I want sum o dat...
-
Please, if you find out, that would be great!
Some floating dialogs randomly stick to the cursor and follow the cursor over the screen. If I could dock those dialogs to the viewport sides, maybe I could get rid of that behaviour. -
One problem is that some of the floating toolbars do not remember their shape after re-starting Sketchup. Using the new "Save Toolbar Positions" does not help, and I haven't figured how to resize them.
Advertisement