Kyle:
> The main menu nib is kind of funny. It's loaded differently (or at
> least at a different time) than the other nibs. It's much more
> sensitive to timing issues like this.
>
> Who provides the MOC for the controller (another object in the nib?),
> and how is it provided (bindings, -setMan
Interesting idea, probably a little beyond me. :) I was hoping there might be a
direct way of having the UIBarButtonItem respond immediately to a user's touch,
instead of waiting until the user's finger is lifted.
On Nov 12, 2010, at 8:53 PM, Dave DeLong wrote:
> Random idea (untested, just spo
On Nov 15, 2010, at 5:32 AM, Vincent Habchi wrote:
>
> Yes, the MOC is provided through a binding to the AppController, itself part
> of the NIB. But the MOC iVar is set to nil until the user successfully opens
> a persistent store file. So I imagine the init code for the NSArrayController
>
Kyle:
> If your app is simple enough, your app delegate could initialize the MOC and
> act as the nib's File's Owner. In more complicated applications, I would
> instead recommend the app delegate still be in charge of creating the MOC,
> but also creating an NSWindowController that loaded the
Environment: OS X (10.6.5) & iOS4+...
Scenario:
I have a static object (myNumber) that I use to accumulate a value through
multiple iterations from concurrent blocks.
Here's what I have learned:
1) Best way to 'share' variables is via heap vs stack.
Hence, I've created a static object 'myN
On Mon, Nov 15, 2010 at 12:00 PM, vincent habchi wrote:
> My app is neither very simple, nor very complex. Your first solution should
> be more than adequate.
>
> Thanks a lot, have a great day!
No problem. Just keep in mind that by avoiding NSWindowController, you
lose its automatic breaking of
On Nov 15, 2010, at 1:06 PM, Frederick C.Lee wrote:
> 1) How do I properly release my static NSNumber *myNumber after use?
Why would you want to? The point of a static is to last the lifetime of the
application.
However, your code as you posted it, is quite messed up. You create a number
that
This isn't 'real code'.
This is merely an attempt to learn GCD & concurrency: sharing common data, etc.
The reason for alloc a NSNumber is to work with the heap vs stack.
I'll also be working with C structures as well.
Yes, working with static int mynum is of course, much simpler.
I'll peek at OS
On Nov 15, 2010, at 1:08 PM, Frederick C. Lee wrote:
> I'll peek at OSAtomic.h
>
> I'm in a learning phase, so I'll expect to 'flutter about' before I can fly.
In that case, do not peek at OSAtomic.h. Avoid OSAtomic.h until you understand
the basics of coordinating access to shared data.
> BTW
Thanks for the warning!
Understood.
Ric.
On Nov 15, 2010, at 1:09 PM, Greg Parker wrote:
> On Nov 15, 2010, at 1:08 PM, Frederick C. Lee wrote:
>> I'll peek at OSAtomic.h
>>
>> I'm in a learning phase, so I'll expect to 'flutter about' before I can fly.
>
> In that case, do not peek at OSAtomic
On Nov 15, 2010, at 2:08 PM, Frederick C. Lee wrote:
> This isn't 'real code'.
> This is merely an attempt to learn GCD & concurrency: sharing common data,
> etc.
OK.
> The reason for alloc a NSNumber is to work with the heap vs stack.
> I'll also be working with C structures as well.
static i
Ultimate scenario:
Predicting satellites... one...many.
Each satellite is govern my Keplerian physics {drag,etc.}; so I'll be
working with a dozen+ variables, in parallel/concurrently.
Programming Scenario:
a) Satellites' identifiers stored in Core Data. <--- Done.
b) User select sele
Frederick C. Lee wrote:
2) Static variables on stack <-- I was aware of this.
"Static" and "on stack" are mutually exclusive. It's impossible to
have a variable that is both, so "static variables on stack" is
nonsense.
BTW, the C storage specifier for "on stack" is "auto". You might
Hello,
Something doesn't seem right here.
Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will
grey out/de-activate an item in the file browser but the item can
still be selected and doing so copies the file name string into the
Save As: text field.
Is this the expected
On 16/11/2010, at 10:41 AM, Stephen Blinkhorn wrote:
> Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey
> out/de-activate an item in the file browser but the item can still be
> selected and doing so copies the file name string into the Save As: text
> field.
>
> Is
On Mon, Nov 15, 2010 at 3:41 PM, Stephen Blinkhorn
wrote:
> Hello,
>
> Something doesn't seem right here.
>
> Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey
> out/de-activate an item in the file browser but the item can still be
> selected and doing so copies the file
On Nov 15, 2010, at 15:41, Stephen Blinkhorn wrote:
> Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey
> out/de-activate an item in the file browser but the item can still be
> selected and doing so copies the file name string into the Save As: text
> field.
>
> Is t
Thanks for the comprehensive replies.
On 15 Nov 2010, at 17:47, Graham Cox wrote:
On 16/11/2010, at 10:41 AM, Stephen Blinkhorn wrote:
Returning NO for NSSavePanel's panel:shouldShowFilename: delegate
will grey out/de-activate an item in the file browser but the item
can still be selected
On Nov 15, 2010, at 18:48, Erik Buck wrote:
> Mac OS 7,8,9 had no delegates at all. Cocoa was introduced with Mac OS X.
> Before that, the technology had nothing to do with Mac OS (other than
> Rhapsody pre-release and server) and was called Yellow Box. Before that it
> was Openstep, and befo
On 15 Nov 2010, at 22:06, Quincey Morris wrote:
The other thing I forgot to say earlier is that the new
'panel:shouldEnableURL:' method is explicitly documented to be
*ignored* for Save panels, which makes more sense in terms of the
OP's original question than the older delegate method.
20 matches
Mail list logo
