Crazy problem with Right Click

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.

TIG

Here is a list of Unix file-name character exceptions
http://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words
Seems that ' %' is disliked, but otherwise it's pretty much as the Windows restricted set, isn't it ?
Also see http://support.grouplogic.com/?p=1607 too...
Interestingly that says a Mac can accept any character in a file-name except a ' :' [the folder separator], or starting with a ' .' - reserved for special files [hidden?]; the length limit is 256 for OS-10 [or 31 for OS-9].
Windows:- a file-name can't end with a <space> or a '.', be named as one of the 'protected names' - e.g. com1 [no extension], be longer than 255/256/260 characters depending on FAT/NTFS/extension, or additionally contain a ' ^' on 'FAT' systems only.

thomthom

Doesn't . at the beginning on UNIX system mean hidden files/folders?

thomthom

@lapx said:

Has anyone found a fix to this problem of the right click menu. I cant access any many of the commands

Yes - update your Fredo plugins.

lapx

Thanks Tom! Ill do. Wow there's so many...fredo scale n tools on surface.

lapx

Has anyone found a fix to this problem of the right click menu. I cant access many of the commands

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