Vague problen with default button

Hi,

I've noticed an issue with losing the 'default' functionality of a button a
while back, and been trying to find out when it occurs. Today it happened
again and I think I've got a bit more of a lead.

First of all, it appears to only happen when I run the app in the
development environment, never in a deployed application.

When 'it' happens, the default button on the screen in focus still shows as
a default button, but when hitting the <enter> key, the system just bongs.
After 'it' happened, the shortcuts in the browsers and worksheets seem to be
a bit confused as well, for example ctrl-s doesn't work anymore, ctrl-d
doesn't evaluate but inserts a tab instead.

Like I said, today 'it' occurred again, and I'm quite convinced it started
after I got a debugger window, which I just closed and continued with the
app. The debugger window was not directly related with the screen that I was
working with, it was a message that a file could not be overwritten as it
was open.

Has anyone seen this problem before?

Thanks,

Ted

Ted Bracht wrote:
> I've noticed an issue with losing the 'default' functionality of a button a
> while back, and been trying to find out when it occurs.
> [...]
> Has anyone seen this problem before?

Yes. I do get the problem with <enter> not activating the default button
on dialogs. But I haven't noticed the confusion in shortcuts that you
report.

For me the problem arises (with good regularity) after working the
development image for some number of hours. It takes quite a while, so
I've never gotten a good handle on just how long it is. I have some
intuition that it might be related to how many (complex?) windows have
been opened and closed, but nothing concrete.

It appears to be some sort of issue with running out of, or exceeding
some limit, related to Windows resources. (I'm on Win2K). Since after
the problem appears, I can save the image, exit, and restart the image
to get the <enter> key working again.

I put together the following snippet that will exhibit the problem, once
it has occurred. I was hoping that running it would initiate the
problem, but haven't had any luck with that.

count := 0.
[   count := count + 1.
    Transcript space; show: count printString.
    Shell show exit.
        [View active postMessage: (Win32Constants at: 'WM_KEYDOWN')
wParam: 13 lParam: 16r1C0001.
        View active postMessage: (Win32Constants at: 'WM_KEYUP') wParam:
13 lParam: 16r1C0001.
        ] postToInputQueue.
    (Prompter prompt: 'test') notNil
] whileTrue.

I'd try to look into it further when it arises (because I know it will),
but I'm not too sure what to look for.

-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA