Keyword Option/OSNAP (Point) C
Anybody ever use the DIMTEDIT command? I just ran into a conflict with Center and CENter, and was just wondering what the workarounds are.I was creating a multi-edit for the DIMTEDIT command.It says it has a “Center” option, but now that I’ve investigated a bit more, it looks like functionally it only has a “Ce” option.If you input anymore than that, it jumps to looking for a center point.It seems like I’ve run into this sort of problem before, a very long time ago, but I can’t remember in what context, that is, regarding what command. Perhaps it had to do with some sort of text justification, where MID could be a problem as well.Anyway, it looks like the simple solution is to just truncate the input to one or two letters.BTW, while searching for help, I noticed that the online AutoCAD 2013 Help fails to mention that this command also works for Arc Dimensions. Oops, I meant Angular Dims. I have encountered this same problem, but I also can't remember the command context - not important. To avoid activating the osnap overrides, you have to stick with single letter. When this issue comes up, the best thing is to test it with dynamic input (or just hold the right-click down until the choice menu pops up). Using the dynamic input option, you can select the option, rather than typing in the keyword. From there, you can see what it returns, and for dimtedit + center, it will only return "C". alanjt, thanks very much for your input. Very helpful.I tested your idea (didn't think I would, did ya'?) and noticed that it only returned the first letter of all of them, that is, H for Home, R for Right, etc.My guess is that it only returns what it needs to distinguish, that is, if it needed two characters, then it would return those.I just now looked at the -LAYER command, because it has such options, and, yes, it returned all the capitals, and only the capitals.So, to avoid conflicts with the OSNAPS, it would seem that a max of two letters should be observed for options.This makes sense anyway, sense having more required characters would be very cumbersome for keyboard aficionados.I've long known that they forced the OSNAPS to be three characters long minimum, and I suppose this sort of conflict is why. Thanks again.
Glad you got it sorted.
FYI: endp, appint, perp, near...
Now, regardless of how autocad returns, if you are writing your own getkword prompt, try and keep every thing the same. It drives me crazy to see:
(initget 0 "Y N")
(getkword "\nSomething? : ")
Selecting with dynamic prompt will work, but if the user, for some reason, and I have seen these types of users, decides to type "yes", it will not accept it, since the initget is only set to accept "Y" or "N".
eg.
Something? : yesInvalid option keyword. Thanks! And I always appreciate further information, so thanks for that as well.
Yes, I'm afraid all sorts of stuff, including stuff like that, drives me at least as crazy.I'd be OK if they reversed it, that is, had the prompt shorter and the keywords longer, but I prefer both to be fleshed out evenly--makes it clearer quicker.The only time there should be a problem is when it is really just unavoidable, because of something inherent, as in the OP.And most people won't try to type in Center.But the program should 'offer' it, just as in AutoCAD, then process it so that it's not a problem further on.I thought about using ".../Ce(nter)/..." in the prompt, but decided against it.I don't even know if that would work, as I didn't try it.I just kinda don't like the appearance.
:huh:I must say you lost me here.I don't think you meant that END, APP, PER, and NEA don't work.Did you mean that these prevent something bad from happening?Maybe they help prevent problems with certain command options? Or is this some sort of code I can't decipher?You don't have to answer this, unless it turns out to be very important.Thanks, again.
页:
[1]