![]() 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. they did not make notes in the public API docs.they, once again, made changes to the files, without bumping up the version number(s).That it was new for SU 8 (The SU 7 files did not have the patch.).# does not seem to work as the script is first loading. # fixes a toolbar resizing regression on PC as the restore() call # Per bug 2902434, adding a timer call to restore the toolbar. Thomthom wrote: Noticed this comment in the Sandbox Tools's menu codes:Ĭode: Select all state = tb.get_last_state (Screen origin vs the origins of the individual toolbar containers.) 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. So, Jim, you should be able to move them around in the same way you did the Console window, using Win32 API calls.ĭocked: 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. (So even a button is a window, that happens to have an image that makes it look like a button.)įloating: 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.) Specifically all items are subclasses of class Window, and inherit base methods, etc. ![]() In Win32 programming, everything on the screen, is a 'window'. Add to that the duplicate registry record that gets created when you pull a toolbar off a container, and float it.However we see strange values, perhaps positioning codes, two examples:.MRUFloatYPos should be the Y position with respect to the Display Screen origin. MRUFloatXPos should be the X position with respect to the Display Screen origin. 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.(The C-type may be UINT and subtracting 1 makes it 'rollunder.') 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.(Top-Bottom should give the heigth of the toolbar.) MRUDockBottomPos is the bottom edge of the toolbar, with respect to the origin of it's Container when Docked. (Left-Right should give the width of the toolbar.) MRUDockRightPos is the Righthand end of the toolbar, with respect to the origin of it's Container when Docked. (same notes apply as to the Docked X position values.) YPos and MRUDockTopPos are basically the Yorigin of the toolbar, with respect to the origin of it's Container when Docked. 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. ![]() however, I noticed that some toolbars update both values, other toolbars do not. (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. XPos and MRUDockLeftPos are basically the Xorigin of the toolbar, with respect to the origin of it's Container when Docked. 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. I was hoping to see some way to detect and set a toolbar's (x, y) position. I have been opening and closing toolbars and sketchup all day, and can see no patterns. Each individual floating toolbar container is wrapped by it's own Framed Window (class 'Afx:00400000:8:00010011:00000000:00000000' aka 'CMiniDockFrameWnd'.) 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.ĥ9393 (0xe801) = StatusBar ĥ9402 (0xe80a) = SceneTabs () 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. DON'T Rely on the ending numbers of Keynames! Check instead the value of the BarID attribute:ĥ9423 (0xe81f) = FloatingToolBarContainer (for ALL toolbars) Thomthom wrote:17 is main toolbarThe container window Bars seem to start around 17 but the numbers change dynamically between sessions. If section has Bars, then it contains other toolbarsīar#x refer to another entry with that ID
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |