On May 19, 2012, at 22:10 , mlist0...@gmail.com wrote:
> If I whip the mouse into the window's content area, my cursorUpdate method is
> called and I see the correct cursor. If I slowly sneak the mouse into my
> window's content area, I see the window resize cursor for a moment as I cross
> int
Hmmm. Running on 10.6 gives me a SIGABRT at launch.
I can reboot under Lion and look at this in the morn if you still need another
set of eyeballs.
Cheers.
On May 20, 2012, at 1:10 AM, mlist0...@gmail.com wrote:
> I have a view for which I am adding a tracking area so that I can update the
>
I have a view for which I am adding a tracking area so that I can update the
cursor. The view entirely fills my window and is the only view in the window's
content view.
The tracking area is being registered thusly:
- (void) awakeFromNib
{
NSTrackingArea* trackingArea = [[NSTrackingArea all
On 19 May 2012, at 2:29 PM, Jason Teagle wrote:
> I realise now that NSView is fairly analogous to JPanel in Java, and thus is
> not likely to be a top-level window within an app.
Conceptual note: The Xerox Star, Apple Lisa, and Apple Macintosh had windows:
Independent, top-level containers tha
On May 19, 2012, at 10:04 AM, NUExchange wrote:
> I have a core data app that opens two windows when it starts up. One of the
> two has a NSSearchField. The cursor is in search field and I can enter and
> delete text, but any other operation on either of the windows causes the
> screen to flas
Just tried that. Unfortunately, no joy...
Joseph
On May 19, 2012, at 3:23 PM, Stephen J. Butler wrote:
> On Sat, May 19, 2012 at 12:04 PM, NUExchange wrote:
>> I have a core data app that opens two windows when it starts up. One of the
>> two has a NSSearchField. The cursor is in search field
A view is always clipped to its parent, so such a view would have to be
a direct child of the window's contentView, and would have to be ordered
in front of its siblings. There might or might not be issues with the
sibling views redrawing correctly.
Having learned a bit more about how the visual
On Sat, May 19, 2012 at 12:04 PM, NUExchange wrote:
> I have a core data app that opens two windows when it starts up. One of the
> two has a NSSearchField. The cursor is in search field and I can enter and
> delete text, but any other operation on either of the windows causes the
> screen to f
On May 18, 2012, at 4:10 AM, Jason Teagle wrote:
> Out of interest, do NSView or any other class that would be considered
> 'visual' support any kind of stay-on-top semantics (or slightly less
> specifically, stay-in-front-of-another-view semantics) without actually being
> a subview? Docking
I have a core data app that opens two windows when it starts up. One of the two
has a NSSearchField. The cursor is in search field and I can enter and delete
text, but any other operation on either of the windows causes the screen to
flash and the system beeps. This even happens when I hit Comma
Roland said:
If you can use IB, use it. If you can't use it, try one last time to use it,
>then do it another way. That's what I think at least.
Ken said:
>I would say that you should use IB until you hit a case where you
>can't achieve what you want, or at least can't achieve it
>"comfortabl
On May 19, 2012, at 7:23 AM, Jason Teagle wrote:
> Thank you for this patient and in-depth reply.
You're welcome.
> As a general rule of thumb, then, would you say a developer *should* use IB
> to design the interface, or is manually building a UI with careful
> consideration for size (due, fo
>>
>
> As a general rule of thumb, then, would you say a developer *should* use IB
> to design the interface, or is manually building a UI with careful
> consideration for size (due, for example, to localization in another
> language) an acceptable practice? I realise there are times when manu
It was not minimized. Apps can't be minimized, only windows can.
Thank you for this patient and in-depth reply.
>Your app was simply running with no windows open.
Understood. A little freaky, coming from a PC perspective, but it is
something I will get used to.
When you click on the Dock
On May 19, 2012, at 4:46 AM, Jason Teagle wrote:
>> Closing the last window of an application doesn't automatically quit it
> ...
>> The app is still running and current. Its menu is shown in the menu bar and
>> you can still use it.
> This seems to be a problem though - clicking on it won't br
Hiding an app is a specific operation that's not related to quitting
> it or closing its last window. There's a Hide menu item
>in the application menu (the one named after the application).
>
*That* is when -applicationDidHide: would be called.
Ah... so there is. My bad. All part of the lea
On May 19, 2012, at 3:48 AM, Jason Teagle wrote:
> Everything went fine (after I fixed an incorrect alloc), but it's what
> happens at the end of the app's (apparent) lifetime that has got me slightly
> bemused. I'm running this under the debugger, if that makes a difference.
>
> If I Command-Q
Apologies for a newbie question.
I've just tried my first normal Mac application in Xcode (so far I had
only created an iOS app and a Mac screensaver).
Everything went fine (after I fixed an incorrect alloc), but it's what
happens at the end of the app's (apparent) lifetime that has got me
s
18 matches
Mail list logo
