Crazy problem with Right Click

thomthom

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.

ObjectSpace.each_object(UI::Command) {|x| p x }
Gives you access to each UI::Command object. But the class has only setter methods defined. And instance_variables on an instance of UI::Command returns empty.

thomthom

@jhauswirth said:

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.

What is the command is used in both menus and toolbars? or just toolbars?
I often create an instance of a Command when both a menu and a toolbar is executing the same command.

jpalm32

[quote="thomthom":287u3y55]
@jhauswirth said:

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.

ObjectSpace.each_object(UI::Command) {|x| p x }
Gives you access to each UI::Command object. But the class has only setter methods defined. And instance_variables on an instance of UI::Command

Yeh! What ThomThom said.
Really! You guys scare me sometimes.

jeff hammond

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

thomthom

@unknownuser said:

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

By right clicking repeatedly on geometry without cancelling the menu. But the menus then usually returns ones you cancel it.

jeff hammond

@thomthom said:

@unknownuser said:

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

By right clicking repeatedly on geometry without cancelling the menu. But the menus then usually returns ones you cancel it.

i shit you not, i just tried rightclicking on a square at least 800 times .. no glitches

thomthom

@unknownuser said:

i shit you not, i just tried rightclicking on a square at least 800 times .. no glitches

Did you right click
and then while the menu was still open right click again?
(on the same entity)

thomthom

Here's a little hack I made. It intercepts all the setter methods and prints the arguments to the console. Named "_0.rb" to make it load first. (or does underscore make it load last...?)

For some reason it is not overriding the initialize method.

But I do intercept the setter methods. On my home machine I get some output every time I right click:
tooltip: Scaling with orientation of scaling box tooltip: Tapering with orientation of scaling box tooltip: Planar Shearing with orientation of scaling box tooltip: Planar Shearing by selection of plane and angle tooltip: Stretching with orientation of scaling box tooltip: Twisting with orientation of scaling box tooltip: Rotation with orientation of scaling box tooltip: Rotation by selection of plane and angle tooltip: Radial Bending by selection of plane and angle tooltip: Make Groups and Components Unique

And when I do this line for every right click:
c=[]; ObjectSpace.each_object(UI::Command) {|x| c << x }
the count goes up by 10 - one for each tooptip.

So in my case, even though I'm not catching the new method, it does appear that I've accounted for every leak. There might be other plugins that does not set any other methods when it creates a new Command object, so I'm not sure how to catch that since I can't hook into initialize.

As for the tooltips, they are from FredoScale, right?

_0.rb

jeff hammond

yes..

drew a rectangle then started right-clicking repeatedly on its face.. (didn't do anything else other than those two steps.. no left-clicking,selecting, or moving the mouse pointer etc.)

thomthom

@unknownuser said:

yes..

drew a rectangle then started right-clicking repeatedly on its face.. (didn't do anything else other than those two steps.. no left-clicking,selecting, or moving the mouse pointer)

You must be charmed.

jeff hammond

@thomthom said:

You must be charmed.

ha..
but like i said earlier, i've never seen a mac user state this problem.. maybe this is one area where windows and osx are different with SU?

thomthom

Ah, you're on an apple. So you said. And so it says in your profile.
It's late. G'night!

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?