in a recent thread i tried to combine different commands into one sequence, getting help from a windows user @clement and all worked well till i encountered this problem.
_-Layer _Color “Hatch” 255,0,0 _Enter
the expected behaviour would be that the layer called Hatch becomes simply red without further questions. on Windows that seems to work, but on Mac this pops up a window with a list of options. if i omit _Enter at the end it surpasses this window but it hooks up in the color picking pop up which seems not to know what RGB values are, entering HEX or RGB is simply ignored forcing me to pick a color manually.
@pascal can you have a look? also if @Helvetosaur wants to check here again pls be invited.
Will try later, but as Mac color picking is different than windows, this may not be hooked up correctly (yet). Something like this (command macro) that works in Win Rhino should also be made to work on the Mac side as well.
Just to say, the Color Picker app is an OS application. Rhino chooses to use the Apple Colour Picker. It is not like WinRhino where the color picker is part of the application. Some apps, like Office, use there own color picker. I believe Adobe apps allow you to choose the Adobe or the Apple color picker. So programming or macros using the color picker will not behave the same on MacOS as they do on Windows.
Yeah, unfortunately, none of this is really working well, far from the Windows equivalent. Looks like @RichardZ the only way to add a layer with a specific color currently will be with a script, like:
import rhinoscriptsyntax as rs
def AddLayerWColor(name):
if not rs.IsLayer(name): rs.AddLayer(name, rs.coercecolor([255,0,0]))
AddLayerWColor("Hatch")
Also @dan - ran across the following macro glitches in my brief testing:
! _-Layer _New "Test" _Enter adds a layer named “Test” (quotes included) ! _-Layer _New "Test Test" _Enter adds a layer named "Test (stops at space) ! _-Layer _New Test Test _Enter adds a layer named Test (stops at space - normal behavior)
Would also be nice if one could delete selected layers with the Delete key…
i figured that the quotation symbols sometimes change maybe because i am using another language, as soon as i edit something in the command they change to the european ones instead of the americans it initially had, they just change by itself so i have to double tripple check them before i send any command. if not, it happens that names are being placed in quotes additionally or even that lines dont work i have figured. maybe that was also the cause in your glitches?
i made a sequence which creates new named layers with appropriate names and kicks all dims or hatches into separate layers it also works even when the layers already exist so can be applied with one short cut to clean up the scenery each time i start a new file.
i just had to change the syntax to _enter on the new layer part, on windows that would be without it seems as clement gave me the windows appropriate syntax
the only thing which is still missing would be to color the layers which i didnt get to work since it ignores any kind of values, so you think making a script is the only way to make that whole sequence work?
Dunno, I have a US English OS, keyboard and Rhino… Quotes are supposed to be ignored in command-line strings, as they are the only way to specify names or paths with spaces in them - as without quotes, a space in a command string is considered like Enter (spacebar). So there is something definitely wrong there. The WIP behaves the same. Hard to imagine that this hasn’t been discovered previously.
Yeah, looks like that currently. Aside from the Mac-side macro “limitations” the main reason after years of resistance that I finally bit the bullet and learned some scripting was the fact that macros, while extremely handy in setting up command options, are pretty limited. Once you start trying to string together sequences of commands, they get tricky if not impossible to use.
Now, I haven’t tested on the Mac side - no time this weekend, too many things to install at the house - but on the Windows side at least, it is possible to store a script under an alias and call the alias in a macro. So a script could be made that would change a given layer color (you’d probably have to make it current first) and that color-change script could be aliased and the alias called in your macro… But in the end, probably just easier to learn some basic scripting and bypass complex macros entirely.
If it is a script i might call at least once in a Rhino session, then I just call that script with a keyboard shortcut or icon, “-RunPythonScript LayersStartup.py”
maybe it make a difference if one uses " or ” i just found out that if i switch off the typographic quotation which is set by standard in the keyboard preferences of mac os i seem to always get the us standard quotation. so maybe this still can be the cause in case it has not been noted that different ones are being produced even if having US as a standard.
hr hr… i just got enthusiastic about making macros yesterday for the first time, was kinda astonished that i actually can make sequences to that extent without using script. if one follows the rules of how windows pop up and how to suppress them you can get actually pretty far, but for sure do i have to encounter that mac has problems with rgb values in that tiny box… what “values” does it swallow anyway? i tried even names it seems it does not want to talk… and @pascal seems to be afraid showing up here maybe its a known fact and they want to hide it as long as possible because its too much work getting this one done just kidding, but come on guys give us a little attention here pls… or do you want to make a python snake curler out of every mac user before they even get the chance to learn macros properly.
anyway @Helvetosaur good luck on your house. is the staircase you talked about already built in?
OK, I’ll try that, but in any case, Rhino itself should not put in fancy quotes in the command line or macros when one types the " key… I could see this for text blocks or text objects, but not for commands or macros.
i totally agree, also it should recognise a “,” as a “.” in any value box this is freaking me out a lot because i like to use the numpad for quick number value input and the comma there “,” does not work because rhino only wants “.” making the numpad on european layouts actually completely obsolete. i never got to making this as a topic but that should be changed for sure its incredible actually that this bug has never been resolved…
also here on mcneel discourse or just generally? have you got a link maybe? but generally i would not know why not, its a language issue and also only a couple of countries actually still use “.” as a comma and the real comma just as a big number separator. but regardless of the local ussage of it, this should at least be switchable that i can use my keyboard regular and not having to saw the right part of if off. rhino is the only software i know of which does not understand “,” as a comma.
hey @wim thanks i could not find anything but also didnt look very hard i thought its a minor issue and would have brought it up sooner or later myself since its still important enough. so i replied there, but i am not sure if anything is going to happen, was that tracked at all?
Well, the “fancy quotes” thing does need to be fixed (if that’s what the bug really is) - if you are typing quotes on the Mac keyboard and they don’t work in macros or command line input correctly, this is a Rhino problem. One shouldn’t have to change system-wide preferences (that it seems many people don’t even know exist…)
The period/comma thing is harder to deal with, as simply inverting comma and period in the command line interpreter may possibly cause some cascading failures elsewhere, as the core programming may not all be designed to deal with that. Also, I think it might invalidate some current scripts using command-line strings involving coordinate entry, depending on how they are programmed…
thats absolutely not acceptable. @pascal also confirmed now in the link you posted that this is not going to change.. hmm?
there are more then 740 Million possible counts (2015) for a european keyboard. thats even when you deduct the UK more than double the amount compared to the US possibilities.
those may be randoms statistics and and say nothing about how many rhino users are from where and using which layout, but seeing those numbers i believe its safe to say that with a high probability there are more people using keyboards with the European layout. i have no idea what people use in Southern America, but if they have Spanish and Portoguese layouts then the US layout looks pretty skinny on the field.
and this is supposed to be not worth rethinking how this can be solved? i simply cant and dont want to believe that. and just because every rhino user who has this problem does not come running, registering here and trying to solve this it most obviously has nothing to say about how many people actually really suffer on that issue.
i can understand that, but rhino is the only software i know of which has this implemented like that. i can understand that the usage of coordinates may make this a problem but i am not thinking about changing the whole system but to change at least that one specific button which can be addressed very precise as NUM PAD comma i believe and then maybe automatically masks the point and writes it internally as period. so please guys can you rethink that again? @dan
back to the color and the syntax problem. i have accidentally found out after imputing random stuff, that the value field of the color box actually swallows aliases, i guess thats plugged together wrong? maybe somebody can have a look?
Not sure the Num Pad comma key is treated any differently than the regular comma key - might be sending the same signal - but I’m not a hardware guy… --Mitch
But in the end, probably just easier to learn some basic scripting and bypass complex macros entirely.
maybe its a known fact and they want to hide it as long as possible because its too much work getting this one done 
just kidding, but come on guys give us a little attention here pls… or do you want to make a python snake curler out of every mac user before they even get the chance to learn macros properly.