Reusing menus - what is going on?
-
I think toolbars behave similar, don't they?
When is the UI (submenus or toolbars) "locked up", when it's first displayed or earlier? -
@aerilius said:
I think toolbars behave similar, don't they?
When is the UI (submenus or toolbars) "locked up", when it's first displayed or earlier?Good questions - I thought it was when it was displayed. But I might be wrong...
-
Within the docs for the C++ SDK, is explained why the C++ references may not be persistent.
Basically at the beginning of every SDK call, the coder must get a handle to the SketchUp application.
From that reference, you go on to get handles to child objects of the app, such as the App's window object, menubar object, etc.
This application handle (reference) gets discarded at the end of the called function.I think it is a bit weird, as the application handle (and it's app window, main menubar, etc.) should not change during the session.. and constant references could be created for them. (And I have done so using C and Win32API.so.)
I would think it should also be possible also in C++, because the API does create constant references to some other things.
It is annoying each time you call
UI.menu("MenuName")a new and different reference is created on the Ruby-side.What I wish for.. is the
UI.menumethod to accept menu pathname (sometimes called an xpath,) .. for example:
UI.menu('/')# the root menubar ref
UI.menu('/Draw')# top level 'Draw' menu
UI.menu('/Draw/Guide')# the 'Guide' submenu of the 'Draw' topmenuSo let's say I want to create a toplevel "Ruby" menu (and I've wanted to for SO LONG!)
I would do something like this:
RUBY_MENU = UI.menu('/').add_submenu('Ruby') verb = RUBY_MENU.add_item('$VERBOSE') { $VERBOSE = !$VERBOSE } RUBY_MENU.add_validation_proc(verb) { $VERBOSE ? MF_CHECKED : MF_UNCHECKED }Of course we need persistent Ruby-side references to UI objects.
-
+1
-
I am also facing this problem in the situation where a plugin is freshly enabled
- either from the Preferences dialog box
- or via the installers (Add Extension, EWH, Plugin Store).
I put the menus of my scripts under Tools > Fredo6 Collection. I keep the handle of this top menu.
However, if the extension of a plugin is enabled, the handle to this menu is no longer 'valid' for methods such as
add_itemoradd_submenu. It does not really crash or even report an error, but nothing appear under the menu.Basically, this means that when a user will enable or install a plugin 'on the fly', I cannot make it load in the current SU Session. Instead, I'll have to display a message "will load next time you start Sketchup".
Note that the problem exists when you group your Plugins under a single menu entry, usually the author name, which is precisely the recommended practice.
Reading the present thread, I don't think there is anything to do to circumvent this problem.
Fredo
-
Yeah, no work arounds Fredo. The user will have to restart SU.
-
@chris fullmer said:
Yeah, no work arounds Fredo. The user will have to restart SU.
Chris,
Then we need to show a message stating this when the plugin is loaded / reloaded from SU extension manager, EWH or Plugin Store.
The toolbar works however, but the fact that the menu are missing may be misleading
Fredo
-
A message would be nice. That is something each developer will have to put into their own scripts for now.
-
Would it be possible to change the menu API to give persistent references to menus?
-
@thomthom said:
So it appear that it only work if it's all done within one action. Which is why my menu plugin works when SketchUp starts up, because the all the plugins are loaded within the same "loop" (??). ... This is awkward and annoying.
I can probably make it work, what I want to do, but it'll hard to debug as I need to actually restart SketchUp every time...
http://sketchucation.com/forums/viewtopic.php?f=180&t=52489&start=30
Yes its a great way to waste more time!
Its enough to make one take up quantum computing instead
Advertisement