Example cmd sy partifymesh
Thank you very much for the tutorial! Jangell 13:59, 30 May 2012 (UTC)
I have some comments:
- The enable() method should call msg.SetCode(LXe_CMD_DISABLED) if the command is disabled (although I think that is done automatically by the wrapper if you return false), and it should set the message to something explaining why the command is disabled. I've added a message table to your config file and updated the enable() method to reflect this.
- For error reporting, you should use the ILxMessage interface built into your command (it's provided by the C++ wrapper). Just call basic_Message() to get the CLxUser_Message interface. Using a failure code (i.e.: basic_Message().SetCode(LXe_FAILED)) will indicate to the command system that the command itself has failed, will cause any undoable actions it performed will be undo, and the command will not appear in the undo list (since it wasn't completed). I've updated your example to do this, using the same messages defined for enable(). It should be that if enable() returns false then these conditions should never occur (since they're already tested for in enable()), but it's always good to check just in case.
- Note that LXe_WARNING is not considered a failure code; it's considered a kind of success code, implying that the operation completed but may have not done exactly what was expected.
- ILxLog should not be used for reporting command execution errors or progress. It can be used for debugging, but you should disable your logging in release/shipping builds, since for most users it's just noise that pollutes the log when used for other uses (like scripting results). Your "20\%%, %u polygons in %.6f seconds." messages, for example, seems like debug output that is only useful to you, and less useful to the end user. I added a note that the log is intended for debugging purposes.
- If you want to report progress, you can use an ILxMonitor (CLxUser_Monitor). This allows you to open a progress bar and update it as you go for longer operations.
- We tend to frown on using startup commands as part of a kit, since eventually we'll have an excessive number of them running at startup if everyone does it, and it's not really the best way to go about it. They're more meant for end user customizations than for kits. In any case, your subsystem should be enabled by default, and you only need the command to disable it. I need to add a feature so that you can use server tag to indicate that a log should be hidden, and that it is intended for debugging purposes. I've commented out your
I also removed this bullet from the config section:
- Finally, we tell modo to enable the log sub-system that this command plugin is registering itself under because by default the displaying of the majority of log sub-systems is disabled within the logging system.
I'm pretty sure that's not correct -- log subsystems are enabled by default, so this shouldn't be necessary. Are you saying that your log subsystem was disabled by default?
I didn't test my changes to your code, so let me know if they work. :)
Thanks again! Jangell 15:29, 30 May 2012 (UTC)
- Great stuff ! Thanks Joe, It's good to get some 'best practices' feedback. Regarding the log sub-system, you're right, ofcourse. I'll look at the monitor feedback as well. I had the basic_Message() feedback setup in another command, forgot to copy it over to this example. I was thinking about detailing a variation to the example using a Visitor as well, so as to highlight the two different approaches to iterating the polygons. Cheers, -- Sy (Synide) 01:21, 31 May 2012 (UTC)