Still not fully fixed in .806! It still won't work in Pending Changes, only in Diff Changeset etc. PLEASE fix Pending Changes as well, since that is one of the most important places to have this!

Follow-up fixes for these issues were included in 5.4.16.806. Thanks!

Göran is right, some improvements are still needed and I think this thread should be unclosed. Please read our previous comments.

Thanks for your work done so far, though.

Ahem, not entirely fixed. Please read comments by me and Mariusz below!

@Göran Wallgren, I have similar observations. It's much better now, but the improvements you mentioned are still necessary.

Thanks, Plastic SCM team, for the improvements made so far! :)

In 5.4.16.707 the keys are added back, nice! However, there are problems still:
* They work in Diff Changeset and Explore Changesets, but NOT in Pending Changes!
* To be able to work with Ctr++ and Ctrl+M repeatedly one first has to focus the Diff panel (which is OK), but the Diff panel often loses focus when Ctrl++ is pressed, which means we still have to use the mouse to re-focus.

Please make these keys work in Pending Changes as well, and make Ctrl+N/M tab-global just like Ctrl+-/+. Then it will be perfect!

@Göran Wallgren The person that reviews code in our company has exactly the same list of complaints about the code review window behaviour as you mentioned in your last comment (missing shortcuts plus the fact that you have to click the diff panel to make its shortcuts work). Those issues made his work so inefficient that he decided to install an older Plastic SCM version. Pity, because this way he loses all improvements added to Plastic since that version, among others the new semantic diff feature, which is great, and which I percieve as a major improvement.

I happened to create a duplicate, more or less, of this uservoice over here:
https://plasticscm.uservoice.com/forums/15467-general/suggestions/10643718-forward-prev-next-diff-keys-to-inline-diff-from-pa

Some of the keyboard shortcuts mentioned in this blog post are no longer valid:
http://codicesoftware.blogspot.com/2014/02/new-release-plastic-scm-5044534-is-out.html

There should specific keyboard shortcuts to the prev/next item buttons (and possibly the first/last item buttons as well) in at least the following views that have an inline diff:
* Pending Changes
* Diff Changeset
* Explore changesets on this branch
* 2D History (for a single file)

It's very good that we have keyboard shortcuts Ctrl+N/M for prev/next Diff, but in the grander scope they are rendered sub-useful since these keys only work when one of the Diff panels has keyboard focus.

For example, in the Pending Changes view I like to review all changes before Checkin. To do this, I select the first item in the list. I can then use the arrow keys Up/Down to walk around between changed items and the inline Diff is updated accordingly.

However, when there are many diffs in a file, I want to review them all so I try the Ctrl+N/M shortcuts. That does not work without first mouse-clicking in one of the Diff panels. (Pressing Tab 4 times seems to work but that's kinda stupid...)

OK, then I want to move on to the next changed item, but that's not possible without first mouse-clicking in the list again. (Tab does not work at all here.)

For the "innermost loop" of reviewing changes it's very irritating to have to click with the mouse between every item when there are indeed keyboard shortcuts to do the required actions.

An alternative solution to this problem would be to have the parent tab/window forward the Ctrl+N/M keys (and Ctrl+Shift+N/M) to the inline diff. Other keys need not be forwarded, for example the arrow keys must work differently depending on keyboard focus.

We have moved completely from WinForms to WPF for the GUI in our products. It's actually nice when you get used to it. Being able to specify the layout in XAML is great, and the separation between model and view is much better than in WinForms. However, the learning curve is very steep. For small quick (in-house) GUI stuff it's better to stick with WinForms, but for production GUI it pays off to use WPF. Must keep an eye on performance though, as you say.

It is actually a WPF window hosting a WinForms control, although the main app is WinForms too.

Using a WinForms window to host the WPF control made the total memory usage grow up like crazy, which was unacceptable.

We were forced to go to WPF due to the new Text Editor control. Had they used a proper WinForms one we had never used any WPF thing.

MS loves reinventing the wheel again and again and again... Animations are ok, but everything else in WPF is avoidable at best :-O

I'm wondering if I could help you in any way. Is it a WPF project with WinForms or the other way round? We currently develop a WPF project that uses some WinForms windows. The problem was that these windows didn't accept any keyboard shortcuts when displayed by a WPF application. Even Tab didn't work there.

To solve this problem, forums suggested hosting individual WinForms windows in a WindowsFormsHost. This was a nightmare, however, and we didn't go that way at all. Somehow one of our colleagues noticed that it was enough to add such (empty) node as a child of the main Panel of the main application window. This solved problems with shortcuts handling in all WinForms windows of the application :-).

<WindowsFormsHost Width="1" Height="1" />

Thanks Mario,

The problem is that we moved the diff control to WPF, and we have some nasty interaction between WinForms and WPF, so we need to figure out what to do and how to get it fixed.