Thank you all so much for your responses - I will give them much better
attention tomorrow, and sober :o)
On 28 Mar 2010, at 02:23, Klaus Backert wrote:
>
> On 27 Mar 2010, at 23:16, Quincey Morris wrote:
>
>> On Mar 27, 2010, at 14:11, Klaus Backert wrote:
>>
>>> something like this (caution
On 27 Mar 2010, at 23:16, Quincey Morris wrote:
On Mar 27, 2010, at 14:11, Klaus Backert wrote:
something like this (caution: typed in mail, etc.)
Yeah, something like this, but *not* this:
self.myFields = [[NSMutableArray alloc] init];
That's a memory leak right there. :)
Ye
On Mar 27, 2010, at 16:51, Noah Desch wrote:
> If you are *not* using getters and setters but instead have myFields declared
> as:
>
> @interface MyClass
> {
> NSMutableDictionary *myFields;
> }
>
> and you use the above line of code, and subsequently release myFields in your
> dealloc m
On Mar 27, 2010, at 5:39 PM, Michael Davey wrote:
> On 27 Mar 2010, at 22:16, Quincey Morris wrote:
>
>> On Mar 27, 2010, at 14:11, Klaus Backert wrote:
>>
>>> something like this (caution: typed in mail, etc.)
>>
>>
>> Yeah, something like this, but *not* this:
>>
>>> self.myFields = [[N
> but *not* this:
> self.myFields = [[NSMutableArray alloc] init];
>
> That's a memory leak right there. :)
This discussion is confusing me a bit... lets see if I got this right:
If you are *not* using getters and setters but instead have myFields declared
as:
@interface MyClass
{
On 27 Mar 2010, at 22:16, Quincey Morris wrote:
> On Mar 27, 2010, at 14:11, Klaus Backert wrote:
>
>> something like this (caution: typed in mail, etc.)
>
>
> Yeah, something like this, but *not* this:
>
>> self.myFields = [[NSMutableArray alloc] init];
>
> That's a memory leak right t
On Mar 27, 2010, at 14:11, Klaus Backert wrote:
> something like this (caution: typed in mail, etc.)
Yeah, something like this, but *not* this:
> self.myFields = [[NSMutableArray alloc] init];
That's a memory leak right there. :)
Incidentally, I think the OP was mistakenly interpreting
On 27 Mar 2010, at 21:31, Michael Davey wrote:
So, you are saying I should call a retain when I get my reference so
that it is kept as an instance var?
On 27 Mar 2010, at 19:33, Sandor Szatmari wrote:
Every time this method runs you would loose the reference to the
memory previously alloc
So, you are saying I should call a retain when I get my reference so that it is
kept as an instance var?
On 27 Mar 2010, at 19:33, Sandor Szatmari wrote:
> Every time this method runs you would loose the reference to the memory
> previously allocated for the fields array. This happens when you
Hi!
I have been running my iPhone application through the Leaks Instrument in an
attempt to further understand what I have been coding, however, I fear I do not
know enough about how retain/release work to be able to fix my leaks, and I was
wondering if I could paste one trouble spot function t
On Mar 27, 2010, at 11:01 AM, Alexander Bokovikov wrote:
> Finally, one extra question. When modal window runloop starts? Does it start
> after the window is shown on screen or before that? If it starts after window
> showing then I'd use performSelector:withObject:afterDelay: to be sure that
>
On 27.03.2010, at 20:36, Ken Thomases wrote:
The app controller should just send a message to the window
controller asking it to do the whole thing. Then, the window
controller can create the window, initiate the process, and invoke -
runModalForWindow:, in whichever order it prefers.
Th
On Mar 27, 2010, at 10:30 AM, Alexander Bokovikov wrote:
>> I think you are used to Windows programming. Cocoa modal sheets are modal to
>> the owning form, not the whole app.
>
> Modal sheet is not so suitable here. Modal sheet is located "within" the
> window which owns it. In my case popup w
On Mar 27, 2010, at 10:20 AM, Alexander Bokovikov wrote:
> On 27.03.2010, at 16:57, Ken Thomases wrote:
>
>>> "separation of concerns" is just the case.
>>
>> Except the timing does not impact on separation of concerns.
>
> I'm not about timing. I'm just about code separation. Initialization is
On 27.03.2010, at 19:39, Joanna Carter wrote:
Every window is "managed" by a Controller and it is from this
Controller that you can run any process you want, as well as
creating and showing a window.
This is correct of course, and this was just what I tried to reach
for. But I had to cal
On 27.03.2010, at 16:57, Ken Thomases wrote:
"separation of concerns" is just the case.
Except the timing does not impact on separation of concerns.
I'm not about timing. I'm just about code separation. Initialization
is a part of dialogue, so its window controller is the right place,
w
Hi Alexander
> I tried to achieve the next effect: some automatic process should be started
> on the modal window appearance on screen. A popup panel with progress
> indicator appears, etc. My idea was not to initiate such process from the
> calling code (where modal window is called from), but
On Mar 27, 2010, at 9:05 AM, Oleg Krupnov wrote:
> Currently I've found only Core Animation, but the information about
> its underlying technology is rather scarce. It's said that it uses the
> graphics hardware, but is it really built on OpenGL? If it is, then
> why such a thing as CAOpenGLLayer
Le 27 mars 2010 à 14:05, Oleg Krupnov a écrit :
> Thanks everyone! Ariel, thanks for the CoreImageGLTextureFBO sample.
> No, Paul, NSImage performance is not enough for my purpose.
>
> Mike, I am aware that OpenGL is perhaps the fastest drawing API in the
> system. However, because it's so low-l
Thanks everyone! Ariel, thanks for the CoreImageGLTextureFBO sample.
No, Paul, NSImage performance is not enough for my purpose.
Mike, I am aware that OpenGL is perhaps the fastest drawing API in the
system. However, because it's so low-level, there must have been built
many wrappers around it in
On Mar 27, 2010, at 7:00 AM, Ken Thomases wrote:
> On Mar 27, 2010, at 6:29 AM, Arun wrote:
>
>> My application is crashing sometimes with the following crash log. It has no
>> traces of my code. Can anyone look into the crash log suggest some ideas?
>
> Probably a memory management bug. You ar
And by the way this question, or basically this question, comes up 2-3 times a
week, every week.
If you checked the archives you would have found many suggestions about how to
find this.
On 27-Mar-2010, at 8:00 PM, Ken Thomases wrote:
> On Mar 27, 2010, at 6:29 AM, Arun wrote:
>
>> My appli
On Mar 27, 2010, at 6:29 AM, Arun wrote:
> My application is crashing sometimes with the following crash log. It has no
> traces of my code. Can anyone look into the crash log suggest some ideas?
Probably a memory management bug. You are over-releasing or under-retaining
something. An NSImage,
On Mar 27, 2010, at 5:45 AM, Alexander Bokovikov wrote:
> On 27.03.2010, at 1:59 PM, Ken Thomases wrote:
>
>> I can't see how this is either correct or incorrect
>> from the point of view of OOP philosophy.
>> OOP involves encapsulation, separation of concerns,
>> polymorphism, etc.
>
> "separat
Hi All,
My application is crashing sometimes with the following crash log. It has no
traces of my code. Can anyone look into the crash log suggest some ideas?
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x2098d5e8
Crashed Thread: 0
Thread 0 Crashed:
On Mar 25, 2010, at 07:55, Jon Pugh wrote:
At 12:02 AM -0700 3/25/10, Brian Willoughby wrote:
Switch to an Intel Mac, or revert to an older version of Xcode.
This was unfortunately broken in the last release of Xcode for
Leopard, but only on PPC Macs, and I wouldn't hold your breath
waitin
On 27.03.2010, at 1:59 PM, Ken Thomases wrote:
I can't see how this is either correct or incorrect
from the point of view of OOP philosophy.
OOP involves encapsulation, separation of concerns,
polymorphism, etc.
"separation of concerns" is just the case.
I would say it's the other way around
On Mar 27, 2010, at 3:23 AM, Alexander Bokovikov wrote:
> On 27.03.2010, at 12:48, Ken Thomases wrote:
>
>> I'm not really sure what you're asking for. A modal window being shown on
>> screen is not something that happens spontaneously _to_ your application,
>> it's something that your applica
On 27.03.2010, at 12:48, Ken Thomases wrote:
I'm not really sure what you're asking for. A modal window being
shown on screen is not something that happens spontaneously _to_
your application, it's something that your application does. So,
whatever you want to do after the window is shown
On Mar 27, 2010, at 2:28 AM, Alexander Bokovikov wrote:
> On 26.03.2010, at 23:10, Fritz Anderson wrote:
>
>> On 26 Mar 2010, at 11:12 AM, Alexander Bokovikov wrote:
>>
>>> Is there any notification or NSWindow delegate method, called immediately
>>> after the modal window is shown on screen? I
On 26.03.2010, at 23:10, Fritz Anderson wrote:
On 26 Mar 2010, at 11:12 AM, Alexander Bokovikov wrote:
Is there any notification or NSWindow delegate method, called
immediately after the modal window is shown on screen? It looks
like windowDidExposed doesn't come to a modal window. Is ther
31 matches
Mail list logo
