isPassword and focus

Greetings,

I see some strange behaviour (D6, have not tried with D5) with the
following piece of code:

RuntimeSessionManager subclass: #MySM ... has a method
MySM>>main
    self login ifFalse: [ self exit: 0 ].
    ... application code ...

MySM>>login
    self promptForUsername showModal ifNil: [^false].
    ^(self promptForPassword showModal first: 6) = 'secret'

MySM>>promptForUsername
    ^(Prompter
        createOn: String new
        prompt: 'Who are you?'
        caption: 'Login')
    validationBlock: [:aString |
        self class validUsers includes: aString asLowercase];
    yourself

MySM>>promptForPassword
    | p r |
    p := Prompter
             createOn: String new
             prompt: 'Tell me the secret word!'
             caption: 'Login'.
    r := p presenterNamed: 'reply'.
    r view isPassword: true.
    r setFocus.
    ^p


MySM>>promptForPassword started quite similar to MySM>>promptForUsername.
After setting isPassword to true, however, the text field did not have
the keyboard focus. Hitting the TAB-key highlights the OK button, which
leaves me wondering, where the focus was and how it got there... and what
this has to do with using isPassword:.

If you want to try it out, just evaluate the promptFor... bodies in
a worksheet.

s.

"Stefan Schmiedl" <[hidden email]> wrote in message
news:[hidden email]...
...
>
> MySM>>promptForPassword started quite similar to MySM>>promptForUsername.
> After setting isPassword to true, however, the text field did not have
> the keyboard focus. Hitting the TAB-key highlights the OK button, which
> leaves me wondering, where the focus was and how it got there... and what
> this has to do with using isPassword:.
>
> If you want to try it out, just evaluate the promptFor... bodies in
> a worksheet.

I tried the code in a workspace in late beta D6 image and the password box
did have the focus.
You can try this code to see what field has the focus:
=========
   | p r |
    p := Prompter
             createOn: String new
             prompt: 'Tell me the secret word!'
             caption: 'Login'.
    r := p presenterNamed: 'reply'.
    r view isPassword: true.
    r setFocus.
 [(Delay forSeconds: 1 ) wait.
 View focus inspect ] fork.
    p showModal
=========

Chris

Hi Chris,

I played some more during lunch break ...

Without "r setFocus" , an inspector on the Prompter's ContainerView is
opened.
    | p r |
     p := Prompter
              createOn: String new
              prompt: 'Tell me the secret word!'
              caption: 'Login'.
     r := p presenterNamed: 'reply'.
  [(Delay forSeconds: 1 ) wait.
  View focus inspect ] fork.
     r view isPassword: true.
     p showModal

With the "r setFocus" included (as in your code above), the focus is set
properly and an inspector for "reply" shows.
However, I noticed that the blinking caret disappeared
after closing the "reply"-inspector, so I tried

    | p r |
     p := Prompter
              createOn: String new
              prompt: 'Tell me the secret word!'
              caption: 'Login'.
     r := p presenterNamed: 'reply'.
     r view isPassword: true.
        r setFocus.
  [(Delay forSeconds: 1 ) wait.
  View focus inspect.
(Delay forSeconds: 5 ) wait.
  View focus inspect  ] fork.
     p showModal

so ... dialog pops up ... 1 sec ... retry inspector pops up ...
I close it (either Alt+F4 or clicking on close button) during
the 5 sec interval ... Prompter is foreground window without
keyboard focus set to text field ... second inspector appears
telling me that retry has focus, even though it does not accept
keyboard input.

Next I tried this without isPassword

    | p r |
     p := Prompter
              createOn: String new
              prompt: 'Tell me the secret word!'
              caption: 'Login'.
     r := p presenterNamed: 'reply'.
  [(Delay forSeconds: 1 ) wait.
  View focus inspect.
(Delay forSeconds: 5 ) wait.
  View focus inspect  ] fork.
     p showModal


... and guess what:
  - Prompter appears with blinking caret
  - reply inspector appears
  - I close reply inspector
  - no caret in reply field
  - second reply inspector appears
  - I close reply inspector
  - I click into the reply text field and still don't see the caret.
  - I tab to the OK button, which is highlighted
  - Now I can Shift-Tab back to or click into the reply field and
    see the caret again.

ho hum ... now I'm removing the line "r setFocus" again:
aha ... without this line clicking into the reply field
does set the keyboard focus as expected.

Something is strange here ...

Any ideas?

s.

Stefan Schmiedl wrote:

> Something is strange here ...

Not so strange.  You are running on Windows.  Windows is buggy...

FWIW, on this system (D6b2 / WinXP pro emulated classic look) I see essentially
the same things as you.  One thing that may be different (not clear from your
explanation) is that although the password box doesn't display a flashing
caret, keyboard input does still work -- if I type then black spots appear as
normal.  You'll note (if your system is behaving like mine) that just changing
the focus explicitly to the password window works fine, the problems only
appear when implicitly changing it back by killing the intruding windows.   To
me that smells like a Windows problem.

    -- chris

On Sun, 11 Dec 2005 12:19:49 +0000, Chris Uppal wrote:

> Stefan Schmiedl wrote:
>
>> Something is strange here ...
>
> Not so strange.  You are running on Windows.  Windows is buggy...

heh. That's my last resort excuse ...

>
> FWIW, on this system (D6b2 / WinXP pro emulated classic look) I see
> essentially the same things as you.  One thing that may be different (not
> clear from your explanation) is that although the password box doesn't
> display a flashing caret, keyboard input does still work --

not on my box, that's why it is so annoying. Especially the version where
I have to explicitely de-focus the input field because not even a mouse
click does focus it.

> if I type then
> black spots appear as normal.  You'll note (if your system is behaving
> like mine) that just changing the focus explicitly to the password window
> works fine, the problems only appear when implicitly changing it back by
> killing the intruding windows.   To me that smells like a Windows problem.
>

That or a missing event handler in dolphin. It's a long time since I
looked into this lowlevel event loop stuff.

Maybe I'll be able to look some more into it later tonight.

s.