Handle del-Key

May 8, 2013 at 1:31 PM
Hi,

in my project i want to costum delete my shapes. In some situations the shapes should not be deleted even if i press the del-Key button.

I handled this basically like in the following codesnippet :
void displayMain_KeyDown(object sender, KeyEventArgs e)
 {
        if (e.KeyCode == Keys.Delete)
        {
               e.Handled = true;
               if(......)
              {
                  //some code here.....
                  conditionForDelete == true;
              }
              else if(.....)
              {
                  //some code here.....
                  conditionForDelete == false;
              }

               //Shapes should be deleted
               if(conditionForDelete == true )
                  deleteSelectedShapes();
               //Shapes should not be deleted
               else 
                    return;
         }
}
I've set e.Handled = true so normally the basic delete action should not be performed. But the selected shapes are still deleted even when the "conditionForDelete"-property is false (when hitting the delKey).

Is it possible to prevent the basic delet action when hitting the del-key ?

Greetz Rastman
May 8, 2013 at 2:06 PM
k i solved the problem by overwritting ProcessCmdKey and raising my normal deleteEvent there.
        protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
        {
            if((keyData == Keys.Delete))
            {
              //raise deleteButton_Click-Event
               toolStripButtonDelete_Click(this, null);
               return true;
            }

            return base.ProcessCmdKey(ref msg, keyData);

        }
if theres a better way pls tell me ;)
May 13, 2013 at 11:26 AM
Hi,
I think it's better to create a custom Selection Tool and subscribe to its ToolKeyEvent event. Return true from the event handler to suppress.
However, NShape Team's opinion is more important.
Coordinator
May 13, 2013 at 4:21 PM
With the next maintenance release (NShape 2.0.4), e.Handled will be processed correctly for Display.KeyDown, Display.KeyUp and Display.KeyPress.
Until this version is released, your workaround is ok.