Toolbar Registry Hacks

Dan Rathbun

@jim said:

Visibility:

Toolbar visibility is controlled by a "Visible" key in the Toolbar entry. If the "Visible" key does not exists, the Toolbar is visible. If it does exist and equals 0, the toolbar is not visible.

This Windows .bat file will turn all the toolbars on or off (including the Status bar! )

You can toggle the StatusBar on/off in Ruby (PC only?) via:
%(#BF0000)[Sketchup.send_action 59393]

I don't find a method to test it's visibility, tho. (Perhaps the %(#BF0000)[UI.toolbar_visible?] method needs to be updated in this respect, along with the other bugs this method needs fixed.)

UPDATE - %(#BF0000)[send_action]The following have no effect on my PC in ver 7.1.x:
%(#BF0000)[21019 hide Status bar and VCB 21020 show Status bar and VCB 21022 hide Status bar and VCB?]
..whereas the above id 59393 does work. (Also I have moved the VCB up to the 2nd line of the Top Toolbar Container, so it's not docked on the StatusBar.)
_

Dan Rathbun

@jim said:

Just messing around with the Toolbar entries in the registry to see if there might be a way to reset their positions.

Conclusion: Changing values in registry while SU is running has no effect. SU only reads from the registry on startup, and writes to it only on shutdown.
(1) This means the registry probably does not contain the current position of a toolbar if it's moved during a session.
(2) This means (on the up side,) that you can set up your toolbars the way you like (and they work,) then shutdown SU, and backup those registry keys for the toolbars to a .reg file. [You will likely have to export each key and then append all the files into one. Also possibly, you'd need to add a command at the top of the file to delete all 'ToolbarsUser-*' keys.] Once you have the .reg file, you can use it to restore the toolbars settings back to the optimum layout if they get messed up, etc. EDIT['con' changed to 'up']

@jim said:

... I have been opening and closing toolbars and sketchup all day, and can see no patterns. I was hoping to see some way to detect and set a toolbar's (x, y) position. The toolbar registry entries do have XPos and YPos values, but I can't find a clear connection between them and the toolbar's actual position.

XPos and MRUDockLeftPos are basically the Xorigin of the toolbar, with respect to the origin of it's Container when Docked. But.. XPos may be the 'last' setting, and MRU... the historical or previous setting. (Generally the MRU attributes are there to put a toolbar back where it was after it was turned off, and then turned on again.) I'm guessing a bit here.. however, I noticed that some toolbars update both values, other toolbars do not. So it may be as simple as, there have been several programmers, over the years working on this feature, and it may be the ol' righthand/lefthand scenario. (Bugs may have creeped in.)
YPos and MRUDockTopPos are basically the Yorigin of the toolbar, with respect to the origin of it's Container when Docked. (same notes apply as to the Docked X position values.)
MRUDockRightPos is the Righthand end of the toolbar, with respect to the origin of it's Container when Docked. (Left-Right should give the width of the toolbar.)
MRUDockBottomPos is the bottom edge of the toolbar, with respect to the origin of it's Container when Docked. (Top-Bottom should give the heigth of the toolbar.)

I note that in many cases, instead of using a value of 0, we get a value that is 1 less than the max integer value for a 32bit number.* ie: 0xFFFFFFFE (4294967294) = 0 - 1* This may be an error. (The C-type may be UINT [unsigned integer] and subtracting 1 makes it 'rollunder.')* It seems in most X/Y values, the position of the next toolbar, is set 1 less than the dimension of the previous toolbar, instead of 1 more than.

MRUFloatXPos should be the X position with respect to the Display Screen origin.
MRUFloatYPos should be the Y position with respect to the Display Screen origin.

However we see strange values, perhaps positioning codes, two examples:
0x80000000 (2147483648)* 0xF8DB0000 (4175101952)* Add to that the duplicate registry record that gets created when you pull a toolbar off a container, and float it.

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

Jim

Just another oddity - when my toolbars are un-docked, they do not open full size when starting SU.

They open like this:

when they should open like this:

thomthom

I see that as well.

Pout

I'm sometimes incredibly amazed by the knowledge and search capabilities of some developers here.
Great job!

Jim

@thomthom said:

I see that as well.

It looks as if the toolbars are defaulting to the size used if the small buttons were being used, regardless of the actual setting.

thomthom

Yea - I have small icons by default. But when testing large versions I've noticed this.
...wonder if it's reported as a bug...

thomthom

@jim said:

Just another oddity - when my toolbars are un-docked, they do not open full size when starting SU.

They open like this:

[attachment=1:3r8e11ta]232.png[/attachment:3r8e11ta]

when they should open like this:

[attachment=0:3r8e11ta]233.png[/attachment:3r8e11ta]

Noticed this comment in the Sandbox Tools's menu codes:

state = tb.get_last_state
if (state == TB_VISIBLE)
  tb.restore
  # Per bug 2902434, adding a timer call to restore the toolbar. This
  # fixes a toolbar resizing regression on PC as the restore() call
  # does not seem to work as the script is first loading.
  UI.start_timer(0.1, false) {
  tb.restore
}
end

Dan Rathbun

@thomthom said:

Noticed this comment in the Sandbox Tools's menu codes:

state = tb.get_last_state
> if (state == TB_VISIBLE)
>   tb.restore
>   # Per bug 2902434, adding a timer call to restore the toolbar. This
>   # fixes a toolbar resizing regression on PC as the restore() call
>   # does not seem to work as the script is first loading.
>   UI.start_timer(0.1, false) {
>   tb.restore
> }
> end

How soon they forget ...

... we discussed this in two other topics:

Re: Toolbar problem in SU 8 on Windows

by Dan Rathbun on Wed Sep 08, 2010 7:59 am
Re: How to use the toolbar.show method
by Jim on Wed Dec 01, 2010 8:54 am

We concluded:

That it was new for SU 8 (The SU 7 files did not have the patch.)1. they, once again, made changes to the files, without bumping up the version number(s).1. they did not make notes in the public API docs...

Somewhere I proposed if it might be better to just write the delay block INTO the UI::Toolbar.restore() method and thereby have the patch global without needing to edit a bunch of plugin code. (Can't find that specific post now.)

Dan Rathbun

Just a note that Thom's values are given in decimal, most are actually stored in hex. (The (4) is value type? )

Also, in the Windows world, MRU is an acronym for "MostRecentlyUsed".

@thomthom said:

If section has Bars, then it contains other toolbars
This is called a "container window".

@thomthom said:

17 is main toolbar
The container window Bars seem to start around 17 but the numbers change dynamically between sessions. DON'T Rely on the ending numbers of Keynames! Check instead the value of the BarID attribute:
59419 (0xe81b) = TopToolBarContainer
59420 (0xe81c) = LeftToolBarContainer
59421 (0xe81d) = RightToolBarContainer
59422 (0xe81e) = BottomToolBarContainer
59423 (0xe81f) = FloatingToolBarContainer (for ALL toolbars)

[I have multiple copies of the 59423 FloatingTBC, 3 at the moment, 4 before I put the Dynamic Components toolbar on the BottomTBC. The first copy of 59423 has little info (BarID, Floating, Horz, XPos, YPos) the two other copies are identical and are full records with num of Bars and Bar#=ID entries. So which one is SU using as the "true" record? Why the dups? Is SU just using the info as a "spacers" in the registry? tis.. strange!]
(2011-03-13) Each floating toolbar (class 'ToolbarWindow32') is wrapped by it's own container (class 'AfxControlBar80u') all of whom share the ControlID 59423, but each has it's own WindowHandle. Each individual floating toolbar container is wrapped by it's own Framed Window (class 'Afx:00400000:8:00010011:00000000:00000000' aka 'CMiniDockFrameWnd'.)
%(#408000)[The Toolbar Containers do not have their own names, but instead assume the window caption of the last toolbar that was docked in the container.

(Edit)]
59393 (0xe801) = StatusBar [only entries Visible, BarID ]
59402 (0xe80a) = SceneTabs [only entries Visible, BarID ]

%(#408000)[87528 (0x0155e8) = {placeholder}
[see my next post titled "BarIDs".]]

@thomthom said:

Bar#x refer to another entry with that ID
Often lots of 0 referendces.
Should only see 'Bar#n' in container window Bars.
Think of "Bar#n" as 'BarPositionNumber'.
The '0' references are apparently 'padding positions' that don't 'point' to another barID, (ie the ID is 0,) but allow another toolbar to dropped at that position. (If you are not using the rightside toolbar container, and put, say the Google toolbar on it all alone, you'll see in the registry that it gets padded with 2 positions that have BarID = 0.)

@thomthom said:

MRUDockID (4) : 0
means it is not docked - Floating
Hmmm... this value should be the ID of the bar's Most Recently Used container, when it was last docked. If the toolbar was never turned on or docked, then wouldn't it be 0 by default?
.

Dan Rathbun

Bump.. changes to my post on page 1 regarding Toolbar Container Control IDs.

Chris Fullmer

@dan rathbun said:

Somewhere I proposed if it might be better to just write the delay block INTO the UI::Toolbar.restore() method and thereby have the patch global without needing to edit a bunch of plugin code. (Can't find that specific post now.)

It was here, 2nd post

http://sketchucation.com/forums/viewtopic.php?f=180&t=32474&p=286452

Dan Rathbun

Thanks Chris.. but I actually later realized via testing, that it will not actually fix the issue totally.

ANY error that occurs in the startup cycle will cause a popup mutiline messagebox to appear, which is modal. IE, It blocks further startup processing until the user dismisses the messagebox. By the time the user closes the MB the timer has run already out. So using a timer only works if NO startup errors occur.

At least that's how it is in pre-2013 versions on Windows.

Hopefully we can soon address the main Ruby issues with plugin / extension loading, running and shutdown.

TIG

Obliquely...
Have you also noticed this [reported] bug in v2013 ?
Win7 - but others might get it too...
Open SketchUp v2013
Arrange some floating toolbars on screen - native, native-rb [like dcs] and plugin.
Minimize SketchUp.
Context-menu close it from the Task-Bar.

Reopen SketchUp v2013.
Native toolbars are where you left them.
All native-rb and plugin toolbars have been 'deactivated' !
Bummer...