Using the Beta version 1.0.5 and would like to suggest two possible changes be made to the QuestionUser function. 

1.  When the Window opens for user input, the focus should be in the Text field, not on the Cancel button.  Current status means leaving the keyboard to go to mouse, or getting in habit of using Tab or SH-Tab to get to the field for data entry.

2.  It would be good to be able to define the coordinates of the QuestionUser window to control its placement.  This ability should really be allowed for any pop up windows, similar to the new PopUpSelectPosition function.  Example, add this feature also to the WriteLn function along with the new Open/Close Slate commands.

Quote:

No choice seems right for everyone. SInce it was introduced, we have entertained suggestions for each of the three possibilities - the "Accept" button being the "vote" winner. Should we force it to the text widget - then the user would still have to navigate to the Cancel or Accept buttons using Tab / Shift-Tab. Currently, we do not force focus at all, but simply let it default. My personal preference is that it land in the text widget if there is no default value and land on the Accept button if there is a default value. While, that sounds ideal, I am afraid the inconsistency might be confusing - especially since the indication of focus is small in regard to buttons and smaller in an empty text field.

Quote:


The coordinates of popups with true window frames is determined by windowing system preferences set in the desktop. To interfere with the user's settings is to be a poor windowing citizen indeed. We do not determine, control, or interfere with any such settings. Doing so runs counter to the specifications in MSWindows and the specs for all of the many X11 desktops. This is done so that users do not have guess with each of their applications where such windows will appear, and so that the end user can customize the behavior of all of their desktop applications without worrying about renegades. In most circumstances, windows with full frames (those that allow the user to move the window by dragging the frame), do not accept coordinates for position on creation. They can be moved after creation via the APIs, but that is even more disconcerting to the desktop user.

  Thanks for listening

But you know me ,
I will always be asking for more.