Vista - Bug in WPF Commands ?

I have a very strange bug in one of my applications, and I really can't
figure it out.

The application has a menu, which contains standard commands, e.g. Open and
Close. I have some code for those, and they work flawlessly when the
application starts.

But if I do something - which is completely unrelated to commands or menus -
the menu items become inactive, i.e. grayed out, and one cannot click them
anymore. The funny thing is that the commands still work, and can get
executed using their gestures (e.g. Ctrl+O to open).

The "do something" involves the following elements:
- Use a Thumb control to drag some elements around the GUI (-> this implies
Mouse capture as I understand it).
- During the drag, custom RoutedEvent are raised.
- The drag has a feedback involving the AdornerLayer and a VisualBrush.
- The operation involves two ItemsControl, and at least one of them uses my
own custom VirtualizingPanel (hard to get right due to lack of documentation,
but seems to be working).
- The overall operation has a net effect of moving one object from one
collection to another one. I'm speaking of "plain" objects, the result is
visible in the GUI thanks to WPF Binding magic.

I cannot think of any of those elements having an influence on my menu
commands... Is this a bug in WPF ?

BTW, this operation seems to be leaking memory like crazy, but I couldn't
figure that out either. My code has hardly any place which is complicated
enough to create leaks, and I've taken out of the code every single possible
source (VirtualizingPanel, Adorner, ...). The result is that a lot less
memory gets leaked, but leaks nonetheless.

All this is above my understanding, and I can only guess that it may be WPF
bugs... Does anyone here see something I might have missed ?

Thanks for reading this rather long post!
jods

How are your commands deciding if they're enabled? By default, we look to
the element with focus, and see if it & its parents want the command to be
enabled. Perhaps in your application, focus is going to something that
doesn't know how to handle the Open & Close commands.

--
-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"jods" <jods@discussions.microsoft.com> wrote in message
news:B7604D3F-F199-4CE9-98C4-831923E69E68@microsoft.com...
>I have a very strange bug in one of my applications, and I really can't
> figure it out.
>
> The application has a menu, which contains standard commands, e.g. Open
> and
> Close. I have some code for those, and they work flawlessly when the
> application starts.
>
> But if I do something - which is completely unrelated to commands or
> menus -
> the menu items become inactive, i.e. grayed out, and one cannot click them
> anymore. The funny thing is that the commands still work, and can get
> executed using their gestures (e.g. Ctrl+O to open).
>
> The "do something" involves the following elements:
> - Use a Thumb control to drag some elements around the GUI (-> this
> implies
> Mouse capture as I understand it).
> - During the drag, custom RoutedEvent are raised.
> - The drag has a feedback involving the AdornerLayer and a VisualBrush.
> - The operation involves two ItemsControl, and at least one of them uses
> my
> own custom VirtualizingPanel (hard to get right due to lack of
> documentation,
> but seems to be working).
> - The overall operation has a net effect of moving one object from one
> collection to another one. I'm speaking of "plain" objects, the result is
> visible in the GUI thanks to WPF Binding magic.
>
> I cannot think of any of those elements having an influence on my menu
> commands... Is this a bug in WPF ?
>
> BTW, this operation seems to be leaking memory like crazy, but I couldn't
> figure that out either. My code has hardly any place which is complicated
> enough to create leaks, and I've taken out of the code every single
> possible
> source (VirtualizingPanel, Adorner, ...). The result is that a lot less
> memory gets leaked, but leaks nonetheless.
>
> All this is above my understanding, and I can only guess that it may be
> WPF
> bugs... Does anyone here see something I might have missed ?
>
> Thanks for reading this rather long post!
> jods

Thanks for the answer, I'm gonna check that.

I'm using the standard WPF "Open" and "Close" commands, and I haven't
written any special enabling logic... I wouldn't have expected that the
"Open" command gets inactive just because another control got the focus.

If your supposition is right, there's another point which I don't like. If
the commands were truely disabled, why would the Ctrl+O shortcut still works
? I thought that the whole idea about commands was to globally (de-)activate
functions.

Anyway, I'll post a follow-up here to tell you if it worked.
Thanks,
jods

"Nick Kramer [MSFT]" wrote:
> How are your commands deciding if they're enabled? By default, we look to
> the element with focus, and see if it & its parents want the command to be
> enabled. Perhaps in your application, focus is going to something that
> doesn't know how to handle the Open & Close commands.

Hi again.

After a bit of testing, I couldn't solve the problem.
To be sure that no control intercepts the command, I've created my own
custom commands. The top (main) window has handlers attached to them. So
somehow, the commands must bubble to the top...

Still, no luck. The following points are strange though:
1. The bug only appears the first time I do the manipulation. I can enable
the commands again simply by putting the focus into one text box of my
application (-> this would help me think that you were right about the focus
being the problem). Then, if I do the same manipulation again, the commands
stay enabled!
2. Although the menu is disabled, the command is still enabled and can be
accessed by its keyboard shortcut (-> so is it really disabled, or not ?)

Anyway, thanks for the suggestion.