Through the Interface: Finding out when a custom PaletteSet is closed in AutoCAD using .NET

Kean Walmsley

May 2015

Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


« Implementing an AutoCAD command to print graphics to the screen using .NET | Main | Creating a custom PaletteSet class exposing a close event inside AutoCAD using .NET »

December 21, 2011

Finding out when a custom PaletteSet is closed in AutoCAD using .NET

I’ve just come back from the last of the European DevDays in the UK. It was fun being back in my home country so close to Christmas, and the event itself seemed to go well. It was great to catch up with some developers I’ve known since my early years at Autodesk, some of whom stayed on for dinner and then the DevLab we held yesterday in the brand new office Autodesk Ltd. has just moved into in Farnborough.

A really interesting question came up during the DevLab, and it’s one that has been asked before: how do you respond to the “close” of a custom PaletteSet in your code? For example, it’s quite common for the closing of project-related palettes to update the current drawing, in some way (perhaps clearing graphics or performing some other action).

The StateChanged event tells you when a palette set is hidden or shown, but it reports that the dialog has been hidden even when closed (basically as we don’t really close the palette set when the user hits the “X”, we just hide it).

One common suggestion is not to display the standard close button – by not using the PaletteSetStyles.ShowCloseButton option when creating the palette set – but having a custom close button makes the user interface inconsistent.

I found one approach to address this: from the StateChanged event handler, send a command to the command-line that can check the visibility of the palette set, and take appropriate action when it has been hidden.

Here’s some C# code that demonstrates the technique. Note that the command we’re calling is not exposed for the user (we use the CommandFlags.NoHistory option when defining it) and doesn’t get echoed to the command-line when we fire it, which makes the approach less ugly.

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.Runtime;

using Autodesk.AutoCAD.Windows;


namespace PaletteTest


  public class Commands


    private static PaletteSet _ps = null;



    public static void CreatePaletteSet()


      if (_ps == null)


        _ps = new PaletteSet("PaletteSet to Close");

        _ps.Style =

          PaletteSetStyles.NameEditable |

          PaletteSetStyles.ShowPropertiesMenu |

          PaletteSetStyles.ShowAutoHideButton |



        _ps.MinimumSize = new System.Drawing.Size(300, 300);


        _ps.StateChanged +=

          (s, e) =>




                  "CHECKPALETTESETCLOSE ", true, true, false




      _ps.Visible = true;



    [CommandMethod("CHECKPALETTESETCLOSE", CommandFlags.NoHistory)]

    public static void CheckPaletteSetState()


      if (_ps != null && !_ps.Visible)



          WriteMessage("\n\"{0}\" closed!", _ps.Name);





When we run the PSTEST command, a custom (empty) palette gets displayed. When this gets closed by the user, a message should get printed to the command-line to indicate the palette set was closed (mentioning its name).

This approach is OK, but gets unwieldy if you want to use it to manage multiple palette set dialogs at the same time. In the next post, we’ll wrap the code into a custom class exposing an event that can be subscribed to, which should be much more usable for such situations.

blog comments powered by Disqus


10 Random Posts