Jan 21, 2010 at 6:53 AM
Edited Jan 21, 2010 at 6:54 AM
Heh, I didn't believe anyone would ever want text selection in a game and the fate of the text box would be to accept player name entries for highscore tables :)
Modifiers like Shift and Control should be reported like any other keys (I admit I haven't tested whether the "InputCapturer" actually does this), so the control would have to remember whether a modifier is being held down.
Then its just a matter of managing the selection (eg. by adding selectionStart and selectionCount fields) in the control and getting all the details right when coding the behavior.
To render the selection, the "FlatInputControlRenderer" needs to be modified to draw the selection: Calculate the pixel offsets the selection begins and ends at, then use the IFlatGuiGraphics.DrawElement() method to draw some highlight effect.
You could either reuse the list box selection frame element for that or modify the XML theme to add a special input selection frame element.
If you want to avoid having to reintegrate your changes when you upgrade to releases of Nuclex.UserInterface.dll, you could clone the InputControl and FlatInputControlRenderer. It's as simple as adding the cloned input control to the dialog and registering
its custom renderer by adding the assembly it is in via FlatGuiVisualizer.RendererRepository.AddAssembly(typeof(MyFlatInputControlRenderer).Assembly)). That means zero changes in Nuclex.UserInterface.dll.
I could also just add text selection support to my TODO list for the next release ;)