Crazy problem with Right Click

EarthMover

I've been able to reproduce my right click issues with consistency. I've narrowed down the problem to exploding groups and it seems to occur when I use my keyboard shortcut specifically.

If someone could try and reproduce my results -

Open new sketchup
Make a Box
Use keyboard shortcut to make the box a group
Use keyboard shortcut to explode box
Repeat step 3 & 4 - 15 times
Check the right click menu during 5 more group & explodes

I've tested the above 5 times in new SU sessions and everytime I get the same results. Right click menu goes gray between 15-20 group & explodes via keyboard shortcut.

Interestingly I also tested doing 20 right click group and explodes and the menu didn't gray out, however after doing just one group and explode with the keyboard shortcut, my menu immediately went gray.

Test with Shortcuts - http://www.screencast.com/t/MTVkNDBi
Test with Right click Group & Explode - http://www.screencast.com/t/ZDFiMDRmM

Jim

@jhauswirth said:

The problem is Ruby scripts are calling-
UI::Command.new
and not attaching the new command to a menu item.

Correct, we are not typically attaching Commands to menus because Menu.add_item will accept a block of code as well as a Command. So unless a Toolbar is also being created, it is typical to just pass the name of a method to Menu.add_item:

def method_name
  # do sometrhing
end
menu = UI.menu.add_item("Menu Text") { method_name }

When a Toolbar is being used, we are required to create a Command becuase Toolbar.add_item only accepts a Command. So when there is a Toolbar already being used, it is easy to add the same Command to a menu since it is already created.

I think it is also not typical to create a new Command when adding a context menu. Are we sure SketchUp (Ruby) is not promoting code blocks into Commands? (Is that even possible? )

jhauswirth

@unknownuser said:

interesting turn of events..
i've read a lot of these right-click posts and thought they were something to do with windows because i've never experienced the problem or heard of another mac user with the problem.
sounds like it should affect mac users as well then.. maybe none of the mac users here have the trouble ruby installed?
must be one of those windows specific exporters or something?

[edit] hmm.. well, except for the fact that it's been reproducible without using plugins at all

There was another bug regarding recycling menu IDs. This was caused by the app not being able to execute OnIdle because the context menu was constantly being popped up. I didn't mention this issue because once OnIdle got a chance to do its business all the menu items came back to life. All the issues I've seen would be Windows only.

jhauswirth

I have a ton of Ruby scripts installed and the only one I see creating new command IDs is-
ZLoader__FredoScale.rb

ie- FredoScale

If anyone that is having menu troubles and has this script, can you try removing the script and see if it helps?

thomthom

@jhauswirth said:

I have a ton of Ruby scripts installed and the only one I see creating new command IDs is-
ZLoader__FredoScale.rb

ie- FredoScale

If anyone that is having menu troubles and has this script, can you try removing the script and see if it helps?

After I disable it from under Extensions and restart SU, then the UI::Command instance count stay fixed.

thomthom

That was when I right clicked on a component.

It occured to me to try different entities, as plugins add different items depending on what's right clicked.
When I right click components things are fine.
So are Faces.
But edges are showing an increase in one Command per right click.

thomthom

My Selection Toys plugin uses my TT_Lib library. It has a Menu and Toolbar manager which let the user turn on and off UI items. It uses UI::Command for all items.
However, it does not make the UI:Command instance count increase upon each right click.

I create a cached list of UI:Command object upon loading the script, and the context menus are being fed these every time it needs.
So do I understand this correct that creating UI::Commands within the context menu handler is bad?
But creating the UI::Command objects before and storing in a variable for reuse is ok?

UI::Command objects are never garbage collected?
And the limit is fixed exactly at 1000?
But this is something that occurs on Windows? Does it not occur on OSX because the UI::Command objects are released, or because it does not have this limit?

I also then would imagine that Tools with custom menu also works like this.

thomthom

And does this mean there is a upper limit to the amount of menus?
Say if we use only menus without the UI::Command object, will that trigger this bug?
Will a large amount of toolbar buttons cause this? Even if the toolbars are off?

thomthom

I just observed that the UI::Command instance count go down during a session:

@unknownuser said:

stats
150
stats
144

The first one when I started SU.
I checked again later after doing some work.

So there does appear to be cases when they are released.

TIG

A breakthrough at last !

If I disable just FredoScale then I can’t get the "gray-out" to occur, no matter how much I try...

Looking at the associated scripts uncovers a lot of complexity and convolution... for example
MYPLUGIN.declare_context_handler_long(scmd, menu, ttip, tc, nil, submenu) { FredoScale.launch code, ’T’ }
uses a Lib6Plugin ’declare_context_handler_long’ that perhaps makes new commands whenever the context is right - i.e. you have selected something that matches ?
It runs tpc = Traductor_Plugin_Command.new
This uses
Traductor_Plugin_Command = Struct.new "Traductor_Plugin_Command", :symb, :proc, :menutext, :icon, :ttip, :valproc, :test_cond, :separator, :submenu, :state, :cmd
etc etc

Perhaps we need to get Fredo directly involved in this as his tool certainly seems to be one of ’the culprits’ ?
It should be possible to recast how this tool works to avoid this problem...

PS: I have tried disabling his other tools with FredoScale active and that has no effect - so it is something about FredoScale and making cmds...

thomthom

TIG:


def stats
  c=[]
  ObjectSpace.each_object(UI;;Command) {|x| c << x }
  sprintf("UI;Command objects; %d of 1000 (%.2f%%)", c.length, (c.length / 1000.0) * 100)
end

Use this to query how many UI::Command objects exists. If you type stats during your modelling session you can see it change.

@tig said:

Perhaps we need to get Fredo directly involved in this as his tool certainly seems to be one of ’the culprits’ ?
It should be possible to recast how this tool works to avoid this problem...

I sent Fredo a PM last night. He had already been informed by Google then. So he's looking into it.

@tig said:

PS: I have tried disabling his other tools with FredoScale active and that has no effect - so it is something about FredoScale and making cmds...

Do you have ToolsOnSurface? I found that if I click an Edge it would add one UI::Command instance.
Plugins doesn't always show their menus unless the conditions are right. Like Generate Faces that appear only when selecting an Edge. So we won't know for sure which plugins are affected until all the situations are tested.

My current list is:

Fredoscale - 10 instances per right-click
ToolsOnSurface - 1 instance per right-click on Edge

v0.2

thomthom

And in case you missed it: this little hack let me get some more info to what creates the UI::Commands: http://forums.sketchucation.com/viewtopic.php?f=15&t=27941&start=15#p243608

EarthMover

@tig said:

A breakthrough at last !

If I disable just FredoScale then I can’t get the "gray-out" to occur, no matter how much I try...

Ah-hah! Same here. I disabled Fredoscale & Tools on Surface and am not able to reproduce the same right click issues as earlier. Only problem is, that those tools have become so indispensable that I don't know how to model without them!!!! At least hopefully we are on track to get this HUGE annoyance resolved! It also seems that the "Esc" key is working again.

thomthom

Esc key?

@earthmover said:

Only problem is, that those tools have become so indispensable that I don't know how to model without them!

This is true. But I'm sure there will be a solution for that as well. At least we know more specifically what causes it.
Though I would like to map out better the scenarios how how UI::Command should be used. And have it noted in the API docs.

fredo6

@jhauswirth said:

The problem is Ruby scripts are calling-
UI::Command.new
and not attaching the new command to a menu item.

If you want to verify this run-

for i in 0..1000 do
cmd = UI::Command.new("Tester") { UI.messagebox("Hello World") }
end

I can see Ruby scripts creating new commands on each right mouse click.
Every new command creates a unique command ID in SU and there are only 1000
command IDs available. Normally a command is attached to a menu and when
the menu goes away the IDs are recycled, but since these commands are not
attached to a menu, they don't get recycled.
I'm going to try and figure out how to dump the list of commands (they have
menu item text) so that people can see who's causing the problem.

Just to understand what exactly went wrong, can you clarified whether the issue is:
case 1) creating more than 1000 object UI::Command, regardless of any other consideration
case 2) or creating Command objects and not attaching them to menus

In my scripts, the faulty code which I modified was in the style:


UI.add_context_menu_handler do |menu|
   if some tests...
       cmd = UI;;Command.new(menutitle) { do_action}
       cmd.status_bar_text = tooltip
       menu.add_item(cmd)
   end	
end

So the issue seems to be the Creation of Command (case 1), not the attachment to menu (case 2). Possibly, since this happens in the contextual menu of the Selection tool, it may be that SU does not release the menu items.

Thanks to advise

Fredo

AlexMozg

I wrote a plugin completely fix this problem.
If you use my plugin is no need to adjust the already installed plugins that use the context menu.
Soon I'll post it for testing.

TIG

@alexmozg said:

I wrote a plugin completely fix this problem.
If you use my plugin is no need to adjust the already installed plugins that use the context menu.
Soon I'll post it for testing.

The earliest view of your fix would be greatly appreciated !

Dan Rathbun

@thomthom said:

Named "_0.rb" to make it load first. (or does underscore make it load last...?)

Yes '_' (underscore) loads AFTER '!' (exclamation) and alpha characters 'A'..'Z'

FYI: because both Windows and OSX are both case aware, but case preserving systems; the lower case 'a'..'z' are collated (in directory lists,) in the same positions as the uppercase letters, even though the lower case come after the underscore in the character set.

We must be careful when using special characters to control script load order, as the "allowable" filename characters may vary from system to system. It would be nice to have a list of characters that can be used on both OSX and WIN, and those to avoid (like those characters that are used in URIs ['#','?','&'.'='].

So far.. I am only comfortable using exclamation and underscore.

TIG

I believe that the ASCII characters disallowed in file-names are \/:*?"<>|
I have used a # to prefix my early loading rubies for some time, without any reported problems on both PC or Mac.
but then some apps don't even like a <space> in their file-names.
We know that 'accented' characters also cause problems in Ruby/Sketchup...

Dan Rathbun

@tig said:

I believe that the ASCII characters disallowed in file-names are \/:*?"<>|
This is list that is displayed in the standard Windows warning dialog when you try to use one of these characters when renaming a file.

Can anyone find a link for UNIX/Linux/BSD (and therefor OSX,) invalid filename characters ??

@tig said:

I have used a # to prefix my early loading rubies for some time, without any reported problems on both PC or Mac.
But I would have to vote for putting '#' on the list of DON'Ts because it is used to specify an anchor (html <A> target,) in a URI.
The same goes for '%' as it's used for character numeric codes in URIs.

@tig said:

but then some apps don't even like a <space> in their file-names.
Yes.. I would vote for always using an underscore in place of a space, within a script filename.

@tig said:

We know that 'accented' characters also cause problems in Ruby/Sketchup...
Yup... this is due to the differences in character sets, even though there are some accented characters in the UTF8 set, it's a pain getting Windows to recognize them (using the 1.8.x branch of Ruby.)

[**P.S.:**This may change in the future... if we can twist Google's arms into checking the Ruby version before they set the encoding (ie: KCODE) and calling the appropriate Ruby call per version. In the 1.8.x branch the call is rb_set_kcode; but in ver 1.9.x KCODE has been deprecated, and rb_set_kcode has been removed, in favor of one of the calls in encoding.c (perhaps rb_enc_set_index, see the encoding.h file.) Until this is done, Sketchup will not load Ruby ver 1.9.x, because we just get an error that the entry point for rb_set_kcode cannot be found (because it's not in the 1.9.x branch.)
Not only is 1.9.x faster, but it has much better support for character encoding.]

NOTE: Sorry this has gone off-topic, perhaps one of the moders can break these filename posts off into a new topic.

Crazy problem with Right Click

If you want to verify this run-

for i in 0..1000 do cmd = UI::Command.new("Tester") { UI.messagebox("Hello World") } end

for i in 0..1000 do
cmd = UI::Command.new("Tester") { UI.messagebox("Hello World") }
end