I tried that and it made no difference... so I guess it has to be somehow 'local' to the dialog.

However it applies to ALL my dialogs so it's something I'm doing as a standard.
The one possibly unusual thing I am doing is placing an UltraGroupBox onto the form to fill the client area and act as a 'backgroupd panel' for applying appearance settings.  I even removed that ... and it made no difference. 

I think I'll just have to accept that something odd is going on and use my workaround.

Hi Mike,

That is a puzzle.

The only other thing I can think of to try would be to show the form on it's own, and not as a child of the parent form. Just show it using the Show method without passing in an owning window and see if that has any effect. If that works, then something on the parent form is eating the key stroke.

You are correct. It is not the UltraFormManager.

I removed the FormManager and the one key handler I had on one of the dialogs and I still get the beep when pressing Ctrl+A.
The dialog does not have a context menu or any inbox controls, and I don't use KeyPreview.
The only context menus are the ones built into your controls. [and for the text editor that includes a working 'Select All' menu.]

Since I only care about Select All for the text boxes and those only exist on 2 dialogs I will simply add KeyDown handlers to those 3 text boxes. That solves the issue even if I can't track down the root cause. 

mikedempsey said:

Does UltraFormManager intercept Ctrl+A?

I can't think of any reason why it would do so.

You said that other controls on the same form don't respond to Ctrl+A, either. Is that right? Is it just Infragistics controls or does the same thing happen with a TextBox control?

Assuming it's all controls, then there must be something on that form eating the keystroke before it gets to them. Seems unlikely that it's the FormManager. but again, this should be very easy to test - just take it off and see if the problem goes away.

Other things that could be eating the keystroke are a ContextMenu, inbox ToolStrip/MenuStrip, or the KeyPreview event of the form. I suppose you could also try disabling or removing the toolbar on the main form just to further rule it out.

You are correct.

I verified that it is not the Toolbar that is intercepting Ctrl+A.
I also commented out the 2 'Key' handlers I had added and the problem remains.

The only thing left that might be intercepting Ctrl+A is the UltraFormManager.
I dont have an events attached to that - I use it only to apply a style - but maybe it has some intrinsic handling of Ctrl+A. Aparently that tells it to do something that is not valid - that would explain the 'beep' when I press Ctrl+A.

I don't see anything about shortcuts in the documentation ... but then there is virtuslly no info on this class except for the list of properties and methods.

Does UltraFormManager intercept Ctrl+A? and if so how do I prevent it from doing so?