Crazy problem with Right Click

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

lapx

Updating all plugins did not solve the grey out issue. I know there are suggestions of renaming and unloading plugins but this is a pain obviously. Is there a way to see or track visually the limit if there is such a thing? Is it really the number of programs that are casuing the problem? How many are too many? And which one's are the memory hogs?

ps. i'm getting duplicate information in my menus. What is the cause of this?
attached is a copy of my plugins folder (this may be dated by a few months).

Thanks!

Plugins.txt

hitechbob

Hi,
I have figured out what was causing the problem. When using Windows 11 and Chrome browser, the right-click rendered a truncated (worthless) menu. It seems MS has cleverly disabled right-clicking on any other browser EXCEPT for MS Edge. Imagine my surprise.

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