Hello,

Please forgive me for lack of understanding about the reported problem. I'm not clear enough with your explanation on this part "the keyboard input is ruining my ability to draw via keyboard input". Do you want to use another keyboard input rather than the standard one?

I'm not sure we have this setting to disable keyboard input in UXListBox, but however, I will need to investigate further on this issue.

Hope this helps. Thank you.

 

Regards,
-Martin-

No, I want to disable keyboard input / navigation/selection within the UXListBox completely.  The UXListBox is contained within a window that remains visible on top of the drawing surface so that the user can select what layer they are drawing on, make the selected layer hidden or visible etc. 

Once they click on a layer (Templated UXListBoxItem Bound to a list of "Layer" items) to select that layer, and then go back to the canvas and try to draw on that layer, if they are using the arrow keys to move the cursor aka keyboard drawing, then the highlighted layer in the ListBox changes each time they press the arrow keys and if they hit 'space' it changes what layer they are on.

The UXListBox is receiving and processing keyboard input events, even while they are on another part of the page outside of the window that contains the UXListBox.  I want to completely disable keyboard input within the UXListBox (or perhaps the window that contains it?  I am not sure what is the most correct route to take with it, but I need the Layers panel (UXListBox currently contained within a UXWindow that sits on top of the rest of the applicaiton) to completely stop processing keyboard input events so that the user can control the drawing with the keyboard without messing up what layer they have selected.

To Illustrate I have included a couple of images: 

The first image shows the drawing on the canvas and the layers panel opened, in the layerspanel I have selected layer 1 and begun to draw with my mouse.

In the second image, I have tried to continue drawing the line with the keyboard by pressing the down arrow twice.  As you can see, while the line did continue to be drawn, the window containing my layers (or perhaps it is the listbox which still somehow retains focus) has also processed the keyboard input and now the layers panel is showing layer 3 highlighted rather then layer 1... it actually still has layer 1 selected, but if i hit the space bar then layer 3 would become selected.  One way or another I need to get this layers panel to completely stop processing keyboard input events.  Whether there is a way to disable keyboard input / navigation in the control, or to somehow force it to completley lose focus when you click back on the drawing surface...

 

Hi Taj,

Interesting application!

It looks like the problem you're facing is the focus issue. All ClientUI controls implement extended focus capability that conforms to usability standards. This means that the UXListBox will continue to receive input events when it still has the "logical" focus.

Addressing your issue should be straightforward. The first time when you create the element in the canvas, set the focus to the element immediately. Make sure the element is of Control type.

The other alternative is to switch the focus to somewhere else, i.e., the main page, the canvas container, or other container elements that support logical focus.

Both solutions should prevent the UXListBox from processing input events.

Let me know if that works for you.

Best,
Jimmy

Ok that seems to be working, since the app needs to run on desktop, tablet, and mobile devices we have to support multiple input methods but cannot rely on any one of them, and the drawing surface is actually another control that we built seperately so that it can be embedded into any UI and hooked in via commanding and binding.

We are using your clientui library to build our applications main UI but hte drawing surface itself needs to be able to be embedded into other apps.

Given our requirements for not relying on any certain control methods, and the drawing surface being a seperate component that wont neccessarily be used the same in various applicaitons, what I ended up doing was on the ListBox's GotFocus event, i just set the focus back tot he main page.  This seems to be working great.

One more question if I may.  Is there a way to get a UXWindow to be draggable and position itself correctly during the drag, without a UXDesktop being present?  

What I mean is this:

I am using the UXWindow item as I need a draggable, hidable container to hold my layers panel.  When you try to drag the window around without a UXDesktop component present, the window first resets its position to the center of the screen and then starts to follow your drag movements with a releative positioning.  The result of this is that if the window is not center screen when you start to move it (ie you have already drug it off to the side once) then it will jump back to the center when you try to move it again and though it follows your mouse movement the window is actually now positioned several inches away from your mouse pointer.  (the same behavior can be observed in a UXDialogBox).  Are these controls only designed to work with UXDesktop?  Or is there a way to just use the window / dialogbox controls on a new uxpage without a desktop and have the dragging / positioning work as expected?

To replicate the issue and see exactly what I'm referring to just create a new uxpage, and put a uxwindow in the layoutroot, run the project and drag the uxwindow to a new spot on the screen (all will work as expected at this point) and then grab the uxwindow a second time and attempt to move it again.  It will jump back to center screen before starting to follow your movements.

Thanks.

Hi Taj,

Yes, both UXWindow and UXDialogBox are designed to work in standalone mode.

The issues you were seeing are natural -- the occurred because you're implementing the UXWindow in a Panel that contains its own layout calculation and behaviors. For example, Grid attempts to locate and size an element based on the Margin and alignment-related properties. This contradicts with the behavior that UXWindow desires.

To use floating controls like UXWindow without UXDesktop, make sure you set the control's alignment properties correctly. I found the following definition to work perfectly (both moving & resizing).

	<Grid x:Name="LayoutRoot">              <Intersoft:UXWindow Header="Hello" IsActive="True" IsClientVisible="True" HorizontalAlignment="Left" VerticalAlignment="Top"/>
	</Grid>

Alternatively, you can use Canvas to host the UXWindow. That will be even better as UXWindow will work natively on canvas.

Hope this helps,
Jimmy