One should ALWAYS derive custom PaletteSet from class. So, here is my solution to the question posted in the forum aforementioned.įirstly I created a custom PaletteSet. Obviously the latter approach would be desirable in most cases and and more compliant with AutoCAD conventions. The other approach is whenever PaletteSet's user interaction even is triggered, always cancel any active command first, just like we usually do with any menu/toolbar/ribbon item macro: prefixing it with "^C^C" to cancel possible active command before the macro is called. One way to handle this issue is always test if there is active command in PaletteSet' user interaction event handler first, and only goes ahead when there is no active command. In this case, the interaction with PaletteSet either results in AutoCAD command line showing error message or nothing happens at AutoCAD command line - the active command is still waiting to be either completed, or cancelled. This would cause issue when a command is active with AutoCAD (usually, it is in the middle of the command, waiting for user input) and user goes to the PaletteSet to trigger another command, as described in the question posted in the discussion forum, such as clicking a button to call a command to insert a block. PaletteSet is a modeless UI, floating on top of AutoCAD window and user can freely change the focus between AutoCAD window, or the PaletteSet window. letting AutoCAD do particular processing), it is common practice to use Document.SendStringToExecute() to call AutoCAD command, either built-in one, or custom-built one. When using PaletteSet as UI to allow user to interact with AutoCAD (i.e. So, I decided to post it here for better readability.
There could be different solutions to that question and I thought it would be better to put forth mine with actual code provided, which might be too long to post as reply in the discussion forum. This article is inspired by the question post in Autodesk's.