+1 Do it carefully.
On 20 Oct, 2013, at 11:40 AM, Alok Gandhi <[email protected]> wrote: > In my opinion, overriding the commands is not advisable. You are effectively > removing the native funtionality of the app, which might be needed in certain > cases, if not now, then in future. > > Yes you can do it by hooking into the command events but note that the > command is still going to finish doing what it is supposed to. You can only > do some pre/post stuff. In your case, for example, you can nullify the > extrude in a post procedure and proceed to your custom extrude. You also call > undo but not all commands support it. > > I would still consider overriding commands as a bad practice. Maybe in some > extreme scenario you can, if the situation absolutely warrants it. In such > case you have to remember which commands you have overridden and how, so that > you can restore the original behaviour when need be. You have to baby-sit it > basically. > >> On Oct 19, 2013, at 9:24 PM, Mathias N <[email protected]> wrote: >> >> Is it at all possible to intercept and override commands made by the user? >> >> For instance, in my case I need to make a number of other changes every time >> the user extrudes something. >> At the moment I have implemented my own separate extrude command, but I >> imagine the user would often end >> up using the normal extrude tool purely out of habit. >> >> It would be nice to be able to prevent them from doing so, or better yet >> redirect it to my own custom command. >
