On Jul 30, 2013, at 5:29 PM, Michael Crawford wrote:
> That class object occupies a
> non-zero quantity of memory, at its lowest level being somewhat like
> the combination of a single copy of a C struct, as well as some C
> functions, that from the Objective-C point of view, appear to be
> "class
Hi Ken,
> Let the app crash. Let the CrashReporter tell the user that it crashed. If
> you want to receive the crash report yourself, use an external watchdog
> process or collect the crash report file on next launch.
I'd agree that this approach technically is more correct. One downside
of i
I have a tabbed iOS app.
Tab #2 has a background that is obtained from an auto-resizing scrollView in
Tab #1.
If I am viewing Tab #2, and rotate the device, I need the layout for Tab #1
to reconfigure its views immediately rather than until I select it again.
How can I do this?
I have added a U
I am adding a special CALayer to the layer of my NSView. I can create my
special CALayer, configure it, and add it the center of my NSView layer's
heir-achy perfectly fine. However, as soon as I resize my main view, the
special CALayer's bounds change. I specified the following autoresizing mask
I want to display some status text in the footer of a table view section. It's
nice to be able to implement -tableView:titleForFooterInSection:, but the only
way I see to update it is to call -reloadSections:withRowAnimation:, and that
seems to re-create the row in the section, which ends up des
> The same is true for class methods, by the way. If a class method has a
> reference to
> an instance of the class, it can directly access the instance's ivars the
> same way.
Objective-C shares a property with some languages, but not with
others, that classes are actual objects.
That is, if
On Jul 30, 2013, at 12:25 , Steve Mills wrote:
> When the timing it just right the view gets a cursorUpdate message, but
> nothing else. From that point, moving the mouse will not generate mouseMoved
> messages for the view. Only moving the mouse out of the view and back in will
> then generat
On Jul 30, 2013, at 13:50:54, Lee Ann Rucker wrote:
> The Apple sample code for fullscreen custom animation overrides
> constrainFrameRect:toScreen: so I assume the default implementation isn't
> fullscreen-savvy.
Hmm. Great. I'll do that then. Sounds like a bug, which I'll report.
--
Steve M
We've found a case where our tracking callbacks no longer get called. A view
has a tracking rect installed:
NSTrackingArea* trackingArea = [[NSTrackingArea alloc]
initWithRect:localBox options:(NSTrackingInVisibleRect | NSTrackingCursorUpdate
| NSTrackingMouseMoved | NSTrackingM
On Tue, Jul 30, 2013, at 11:49 AM, Lee Ann Rucker wrote:
>
> On Jul 30, 2013, at 8:48 AM, Andy Lee wrote:
>
> > On Jul 30, 2013, at 11:25 AM, Scott Ribe
> > wrote:
> >> On Jul 30, 2013, at 9:08 AM, Andy Lee wrote:
> >>
> >>> I think it's subject to the same criticisms as *any* direct access t
On Jul 29, 2013, at 10:43 PM, Quincey Morris wrote:
> On Jul 29, 2013, at 22:05 , Lee Ann Rucker wrote:
>
>> The repro case is to close the document and then reopen it. It doesn't
>> reopen the windows, it makes a new window of the same class as the old one.
>> Looking at Instruments right no
On Jul 30, 2013, at 10:31 AM, Steve Mills wrote:
> We have some palettes (NSPanel subclasses) that stay visible in fullscreen
> mode. When the doc window enters fullscreen, I'm moving these the appropriate
> amount so they're still snapped to the top of the visible portion of the
> screen. How
On Jul 30, 2013, at 8:48 AM, Andy Lee wrote:
> On Jul 30, 2013, at 11:25 AM, Scott Ribe wrote:
>> On Jul 30, 2013, at 9:08 AM, Andy Lee wrote:
>>
>>> I think it's subject to the same criticisms as *any* direct access to
>>> ivars, although I agree it feels sketchier when done in plain C for s
On Jul 30, 2013, at 10:26 , Graham Cox wrote:
> How often have you encountered an unexpected exception from some low-level
> code you don't own under circumstances you can't control? If your app crashed
> every time you'd soon have a reputation for unreliability that is in all
> probability un
On Jul 30, 2013, at 09:38 , Keith Knauber wrote:
> 1) A splash screen is a *much faster* alternative than drawing an incomplete
> main window.
FWIW, there is an entirely different reason why (I believe) splash screens are
no longer recommended. Because of auto-termination, there's generally no
We have some palettes (NSPanel subclasses) that stay visible in fullscreen
mode. When the doc window enters fullscreen, I'm moving these the appropriate
amount so they're still snapped to the top of the visible portion of the
screen. However, something is causing the palettes to move back into t
On 30/07/2013, at 5:20 PM, Ken Thomases wrote:
> The fact that AppKit continues after catching an exception at the top level
> is not great behavior to be emulating. It often hides errors which would be
> revealed and fixed more promptly if they caused the app to crash.
Hmmm, that's a *very
On Jul 29, 2013, at 5:52 PM, Ian was here wrote:
> I've added a UIButton to a CALayer. The button appears as it should, but the
> button won't send a touch event. I've Googled around on this subject, but
> haven't found a solution that works in this case. Has anyone come across this
> issue?
On Jul 30, 2013, at 08:54 , Vincent Habchi wrote:
> The way SQLite works, after a query is submitted, the thread is suspended and
> a callback is repeatedly executed
There's one other consideration, in the case when the callback is called a
thread other than the main thread, from non-ObjC code
On Jul 30, 2013, at 9:38 AM, Keith Knauber wrote:
> 1) A splash screen is a *much faster* alternative than drawing an incomplete
> main window.
> My splash screen draws in ~30ms.
> My full screen document window draw takes ~200ms, even when empty.
>Why?
> - NSAttributedString takes
1) A splash screen is a *much faster* alternative than drawing an incomplete
main window.
My splash screen draws in ~30ms.
My full screen document window draw takes ~200ms, even when empty.
Why?
- NSAttributedString takes 2000 CPU instructions per *pixel*.
- It takes longer
On Jul 30, 2013, at 8:54 AM, Vincent Habchi wrote:
>> Apple's recommended alternative to having a struct contain an object is to
>> use a class instead of a struct. You could create a MyCallbackInfo class
>> with two properties: the query id and the pointer to self. You'd still have
>> to bri
On Tue, 30 Jul 2013 10:20:21 -0500, Ken Thomases said:
>>> All in all, what you're doing seems like a bad idea.
>>
>> Maybe but what is the right solution to this?
>
>Let the app crash. Let the CrashReporter tell the user that it
>crashed. If you want to receive the crash report yourself, use a
Hi and thanks a lot to anybody!
I posted some answer before, but since it included a screenshot I’m afraid it
didn’t make it through. I was just trying to show that when I access an iVar of
‘self’ in the C-function (e.g. self -> _egg), Xcode autocompletion pop-up shows
the iVars list, but each
Le 30 juil. 2013 à 17:25, Scott Ribe a écrit :
> On Jul 30, 2013, at 9:08 AM, Andy Lee wrote:
>
>> I think it's subject to the same criticisms as *any* direct access to ivars,
>> although I agree it feels sketchier when done in plain C for some reason.
>
> Yes. Because what is the point of p
On Jul 30, 2013, at 11:25 AM, Scott Ribe wrote:
> On Jul 30, 2013, at 9:08 AM, Andy Lee wrote:
>
>> I think it's subject to the same criticisms as *any* direct access to ivars,
>> although I agree it feels sketchier when done in plain C for some reason.
>
> Yes. Because what is the point of pl
On Jul 30, 2013, at 4:26 AM, Michael Crawford wrote:
> However, I expect there is a way you could call an Objective-C method
> from vanilla C. Possibly you will need some assembly-language glue.
The nice thing is, you don't need glue. You can send Objective-C messages from
within C, as long as
On Jul 30, 2013, at 9:08 AM, Andy Lee wrote:
> I think it's subject to the same criticisms as *any* direct access to ivars,
> although I agree it feels sketchier when done in plain C for some reason.
Yes. Because what is the point of plain C functions in Objective-C files? Local
helpers that a
On Jul 30, 2013, at 4:13 AM, Oleg Krupnov wrote:
>> However, you're not supposed to let exceptions escape from blocks which you
>> submit to dispatch queues. That's documented in the link I gave in my
>> previous reply.
>
> Yes, thanks for pointing it out, but let me note that this is not
> co
On Jul 30, 2013, at 10:42 AM, Scott Ribe wrote:
> On Jul 30, 2013, at 8:35 AM, Andy Lee wrote:
>
>> The only effect, as others have explained, is on scope; if you put the
>> function inside the @implementation and the function has a reference to an
>> instance of MyClass, then it can use myObj
On Jul 30, 2013, at 4:27 AM, Vincent Habchi wrote:
> Yes, right; it’s a SQLite callback, the first parameter is a void *. I wanted
> to pass a pointer to a structure containing both a unique query id (out of
> uuid) and a pointer to self, but got told off by ARC because it apparently
> forbids
On Jul 30, 2013, at 8:35 AM, Andy Lee wrote:
> The only effect, as others have explained, is on scope; if you put the
> function inside the @implementation and the function has a reference to an
> instance of MyClass, then it can use myObj->myIvar for direct access to
> instance variables.
In
On Jul 30, 2013, at 4:19 AM, Rick Mann wrote:
> On Jul 30, 2013, at 00:59 , Vincent Habchi wrote:
>
>> I have a very simple question: if I embed a C-function (more precisely, a
>> callback from an external C-library) in an Obj-C object, can I expect this
>> function to behave like a regular me
On Tue, Jul 30, 2013, at 02:13 AM, Oleg Krupnov wrote:
> > However, you're not supposed to let exceptions escape from blocks which you
> > submit to dispatch queues. That's documented in the link I gave in my
> > previous reply.
>
> Yes, thanks for pointing it out, but let me note that this is
Am 26.07.2013 um 12:41 schrieb Uli Kusterer :
>> Since I can use Core Animation, that is obviously the better solution. It
>> also makes my application look less power hungry - because now it is the
>> WindowServer doing the drawing and eating cpu. ;)
>
> Not sure I follow your reasoning here.
I sometimes just access my objc-objects from a C thread-proc via the
AppDelegate (providing there's a trail to the object I need, which there
usually is)... If the callback void pointer parameter isn't being used for
something else, you can simply cast the object in there... or if you need
multiple
On Jul 30, 2013, at 3:13 AM, Oleg Krupnov wrote:
> I'd disagree. This thread has already crashed and its exception was
> not caught, and so the thread is about to be terminated with or
> without my intervention. Killing it myself would hardly produce any
> side effects. I just want to prevent the
Am 26.07.2013 um 12:41 schrieb Uli Kusterer :
> No no no! Don’t do both at the same time! The display link callback is called
> exactly when you’re supposed to draw!
Hm. So i remove drawRect: and call that in the callback instead?
> If you call setNeedsDisplay: there, you’ll be waiting until
The first two parameters to the function have to be an id and a SEL ...
typedef id (*IMP)(id, SEL, ...);
... (this is where we get self and _cmd, by the way) followed by the rest of
the method params, if any.
lowell
On Jul 30, 2013, at 12:59 AM, Vincent Habchi wrote:
> Hi everybody,
>
Subject: Re: Exiting non-POSIX threads?
From: Oleg Krupnov
Date: Tue, 30 Jul 2013 12:13:38 +0300
I'd disagree. This thread has already crashed and its exception was
not caught, and so the thread is about to be terminated with or
without my intervention. Killing it myself would hardly produce any
s
On July 30, 2013 at 12:04:44 AM, cocoa-dev-requ...@lists.apple.com
(cocoa-dev-requ...@lists.apple.com) wrote:
Message: 5
Date: Mon, 29 Jul 2013 12:54:26 +0300
From: Oleg Krupnov
To: Steve Sisak
Cc: Cocoa-Dev List
Subject: Re: Exiting non-POSIX threads?
Message-ID:
Content-Type: text/plain; cha
Thanks Ken,
> However, you're not supposed to let exceptions escape from blocks which you
> submit to dispatch queues. That's documented in the link I gave in my
> previous reply.
Yes, thanks for pointing it out, but let me note that this is not
consistent with other parts of the AppKit. When
Le 30 juil. 2013 à 10:27, Vincent Habchi a écrit :
> Rick,
>
> thanks for answering, because what I found on the Internet seems
> contradictory. Some say that if the C function is placed inside the
> implementation block, then it can access attributes as if it were a true
> Obj-C method; som
On Jul 30, 2013, at 01:27 , Vincent Habchi wrote:
> Rick,
>
> thanks for answering, because what I found on the Internet seems
> contradictory. Some say that if the C function is placed inside the
> implementation block, then it can access attributes as if it were a true
> Obj-C method; some
Rick,
thanks for answering, because what I found on the Internet seems contradictory.
Some say that if the C function is placed inside the implementation block, then
it can access attributes as if it were a true Obj-C method; some say otherwise.
So it’s a bit difficult to find a definitive answ
I don't think so, not it if has a C-language prototype rather than an
Objective-C method prototype.
However, I expect there is a way you could call an Objective-C method
from vanilla C. Possibly you will need some assembly-language glue.
Ultimately, Objective-C method calls are implemented, I ex
On Jul 30, 2013, at 00:59 , Vincent Habchi wrote:
> I have a very simple question: if I embed a C-function (more precisely, a
> callback from an external C-library) in an Obj-C object, can I expect this
> function to behave like a regular method? I.e. can it freely access ‘self’
> and other a
Hi everybody,
I have a very simple question: if I embed a C-function (more precisely, a
callback from an external C-library) in an Obj-C object, can I expect this
function to behave like a regular method? I.e. can it freely access ‘self’ and
other attributes?
Thanks a lot!
Vincent
48 matches
Mail list logo
