Edit Text Field Not Working in OS9

[Steven Walker]

Hi Everyone,

I have spent a few hours on this problem and can't figure out how to
fix this.

I have a dialog box that gathers basic user registration information.
The dialog is invoked from within a shared library and runs a
ReceiveNextEvent() loop to temporarily block out the host. In OSX,
everything works fine. However, running in OS9 (or Classic) the edit
text fields no longer work. The dialog and controls display fine and
all the buttons work, but I can't click or type in any of the edit
fields.

Does anyone know why this is? I thought it may be related to using
ReceiveNextEvent, but my dialog handler function is being called.

Do I need to install event handlers for each edit text box? Or do I
need to propogate the events manually?

Thanks for any input! :)

Steven Walker
[email]steve@walkereffects.com[/email]

[Uli Kusterer]

In article <80ce5172.0308280748.7bb9de18@posting.google.com >,
[email]steve@walkereffects.com[/email] (Steven Walker) wrote:

> I still can't figure this out. I have tried everything I can think
> of... installing event handlers, removing event handlers, isolating
> the control, sending events. But nothing works, the text edit field
> just does not respond to user interaction.

Do you have any other objects overlapping (above *or* below) that item?
That's not really supported by the Control manager, and may thus cause a
few problems.

You might also want to check whether any of the fields is disabled,
whether it is embedded/auto-embedded in any other control that may be
disabled, things like that...

Have you tried whether it makes a difference to call WaitNextEvent()
instead of ReceiveNextEvent()? It may be that the EditText control still
uses classic events on 9... I don't think the implementation of TextEdit
in Carbon/9 is any different from the one in Toolbox/9.

Finally, are you sure it doesn't react, or do you just fail to see the
results? Are you messing with clipping rects/regions in any way? Is this
in a DialogRef or in a "straight" WindowRef?

Just a few thoughts.

-- Uli
[url]http://www.zathras.de[/url]

[James W. Walker]

In article <80ce5172.0308301342.5c7778ec@posting.google.com >, Steven
Walker <steve@walkereffects.com> wrote:

> As a test, I created a project from scratch using the C++ Toolbox
> Carbon stationary. I replaced the default code with my own to
> dynamically create a window with two controls: a button and a text
> edit field (there are no resources). I installed no event handlers
> (because the default behavior should work).
>
> Then I tried using both WaitNextEvent() and ReceiveNextEvent(), and
> they produce identical results: the window appears, the button works,
> but the text field does not in OS 9. In OSX everything works fine.
>
> In the chance that someone can see my blunder, the code is below

Just a wild guess, maybe you need to call CreateRootControl before the
other controls.

[Steven Walker]

Thank you James and Uli, it was the root control! After putting in
those two lines of code, it all works!!!

I did not know about the root and would have never thought to look for
it. Apparently, the root control is built-in to windows in OSX but not
in OS9.

Oddly, one of Apple's tech notes confirms that I was doing this right:
[url]http://developer.apple.com/qa/qa2001/qa1215.html[/url]
Excerpt from QA1215:
"If you create controls in your window with the CreateFooControl APIs
and pass a valid window parameter, then a root control will be
automatically created for you, as in the past, so you don't need to
call CreateRootControl yourself "
Though apparently this is wrong as my little experiment just showed.

> What are you trying to achieve with this code? Why don't you use
> RunAppModalLoopForWindow() or some other method intended for doing modal
> dialogs? And what does SendEventToEventTarget() return? Does it give you
> any errors?

For brevity of the example I removed all error handling. I could use
RunAppModalLoopForWindow(), but I most often create my own loops to
have more control. In this example it doesn't matter which is used.

Thanks again, this fix has made my day!

Steven J. Walker