User (Old forums)MemberApril 20, 2008 at 7:06 amPost count: 23064
I don’t understand why TextInputActivationGesture and KeyActivationGesture behave differently.
Using a TextInputActivationGesture as the ActivationGesture for a CellEditor, the first key pressed enters edit mode AND is taken as input for the cell.
Using a KeyActivationGesture as the ActivationGesture for a CellEditor, the defined key(s) only enter edit mode but are NOT directly taken as input for the cell.
So, using a KeyActivationGesture, I have to press the first key twice.
And is it possible to setup a KeyActivationGesture in such a way it enters edit mode AND forwards the key to the editor?
Imported from legacy forums. Posted by Michael (had 1039 views)Xceed SupportMemberApril 22, 2008 at 10:28 amPost count: 5658
Are you developing a XBAP application or a standard WPF client application ?
Imported from legacy forums. Posted by Marcus [Xceed] (had 348 views)User (Old forums)MemberApril 22, 2008 at 1:54 pmPost count: 23064
we can switch solution settings to either compile our application as XBAP or as a WPF client app.
Why is that important?
The behaviour I described occurs while running our application as a standard WPF client app.
I suppose, I have to wait for a KeyInputActivationGesture? [:)]
Imported from legacy forums. Posted by Michael (had 535 views)Xceed SupportMemberApril 22, 2008 at 3:40 pmPost count: 5658
I was asking because there is a undocumented weakness to XBAP application vs. KeyActivationGestures.
The fact that the said weakness was not documented will be corrected in the next version of the documentation.
The weakness is due to a limitation of the XBAP sandbox in which some features of the WPF input devices cannot be accessed directly. Finding no workaround for this limitation, we decided to display the editor when we detect a KeyActivationGesture, but it was impossible to re-forward the input events to the newly displayed editor. TextInputActivationGesture does not suffer from that limitation because it does not require access to the features restricted by the XBAP sandbox.
However, based on your description of the problem, this limitation shouldn’t be the issue since your are using a WPF client app.
Can you post your complete CellEditor code (template and gestures) as welll as any custom control code present in the editor so that we can analyze it and try to determine what is happening.
Imported from legacy forums. Posted by Marcus [Xceed] (had 500 views)User (Old forums)MemberApril 23, 2008 at 4:16 amPost count: 23064
thanks for the explanation.
I have written a small test app. Two columns, First column with my own decimal cell editor. Second column default editor.
It’s a VS2008 solution. Can I send you the ZIP file? It is about 600 KB in size.
Imported from legacy forums. Posted by Michael (had 854 views)Xceed SupportMemberApril 23, 2008 at 8:07 amPost count: 5658User (Old forums)MemberApril 25, 2008 at 11:37 amPost count: 23064
did you get my simple test application?
Could you reproduce the problem?
I wish you a pleasant weekend,
Imported from legacy forums. Posted by Michael (had 659 views)Xceed SupportMemberApril 25, 2008 at 1:48 pmPost count: 5658
I confirm I received the project but I don’t have time to check it at the moment.
Imported from legacy forums. Posted by Marcus [Xceed] (had 680 views)Xceed SupportMemberJuly 7, 2008 at 9:36 amPost count: 5658
I finally had some time to check on your issue and can report on my findings.
First and foremost, let me say that I understand your scenario, which is to try to activate the editor only when actual numeric input is done. Unfortunately, there are some limitations that are preventing the use of a “TextInput” enabled control such as the TextBox in conjunction with KeyActivationGestures in a seemless fashion. Effectively, when the key stroke is detected, the editor is not in the visual tree of the cell, so we have to create the visuals, “plug” them in the visual tree and the re-create the input events that were made.
Because of particularities of the input system, there is no flawless translations between a key down event and a TextInput (TextComposition). Because of these translations uncertainties (accentuation, IME, … ), we don’t feel it would be a valid approach to do guessworks with regards to TextInput events.
My suggestion would then be to revert to TextInputActivationGesture, which requires no translation to work efficiently with TextInput based controls. Used in conjunction with the NumericTextBox class (used as the TextBox for the editor), you can obtain a numeric only input for the columns, the side effect being that the numeric editor would get activated if non-numeric characters are type (but editor content would not change).
Imported from legacy forums. Posted by Marcus [Xceed] (had 1465 views)
- You must be logged in to reply to this topic.