Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Strange crash and debug alert
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange crash and debug alert



I haven't been following this very closely, but to do what I think you're
wanting to do, I'd suggest handling the focus setting at a level higher than
the actual edit control, if that's what you're doing; this could be done at the
window level or in a view that encompasses your edit control and static text
control, but after that's done and you know either the window has focus or the
next text-capable view has focus, then hide the edit control and show the
static text control. Let the static text control respond to its drawing event
by grabbing the text from the edit control, and setting the text and then
drawing it. I'm not sure of the actual sequence, but you might be better off
not creating the static text control until you hide the edit control, thereby
giving you the chance of creating it at the full/clipped size of what the edit
control would've drawn it. Once the static text control has full control of
its faculties, it can then dispose of the edit control. And, when the static
text control gets double-clicked, it would hide itself (or the enclosing view
would handle these events, which might be better or even required), create/show
the edit control, and pass on to the next handler. When the edit control gets
shown/created, it would ask the static text for the needed text and delete the
static text control. There's a bit more work to get this scenario working, but
I think it'll be better than your current design; imagine this exampled where
Indiana Jones (window/enclosing view) has to trade a bag of dirt (static text)
with the gold idol (edit control) without getting killed by falling boulders
and poisonous darts (stack overrun/heap collisions/app crash).


Of course, depending on your UI and other factors inherent with the edit control
depending on OS-level, you may prefer just to make the edit control read-only
when focus is relinquished and read-write when it gets focus. Again, this kind
of change should probably be handled by the window/enclosing view.


Quoting Carlos Eduardo Mello <email@hidden>:

Why do you need to remove a view in response to losing focus?

Larry

Because this edit Unicode text is a temporary input view covering the static control which displays the final edited text. So I need to close and store the text when the user presses Return and when the view looses focus. You were the one who suggested it, remember?



On Apr 3, 2007, at 10:41PM, Laurence Harris wrote:

1. What would be the recommended way of providing this kind of editing functionality. My first idea was to cover the control with a text view of the same size, install the necessary handlers, get the text on return and then copy the text to the control underneath. Anything wrong with this approach?


No problems come to mind, except that you'll need to accept the text
any time the text control loses focus, not just when the user types
return. And there may be other events that should trigger the end of
an editing session as well.




_______________________________________________
Do not post admin requests to the list. They will be ignored. Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Strange crash and debug alert (From: Scott Ribe <email@hidden>)
 >Re: Strange crash and debug alert (From: Carlos Eduardo Mello <email@hidden>)
 >Re: Strange crash and debug alert (From: Laurence Harris <email@hidden>)
 >Re: Strange crash and debug alert (From: Carlos Eduardo Mello <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.