Toolbar Registry Hacks

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