Re: Mixing Obj-C and C "methods"

[Andy Lee]

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 methods" that know all about their "class object",

Both class methods and instance methods are indeed C functions (IMPs).  But to 
clarify, it isn't that class methods "know" about their owning class in the 
sense one might imagine, with some sort of back-pointer.  It's that at the time 
a class method is invoked, a class pointer is passed to the function as an 
implicit argument named "self", and *that's* how the function knows the class 
on whose behalf it is executing.  It's a subtle distinction, but an important 
one.

One reason it's important is that you could have a subclass and it could invoke 
the same class method:

[MyClass myClassMethod];
[MySubclass myClassMethod];  // Assume MySubclass does not override the method.

The value of "self" will be different in the two cases at the time that method 
executes.  In each case, "self" is the receiver of the message.

Similarly, at the time an instance method is invoked, an instance pointer is 
passed to the function that constitutes the implementation of the method, again 
as an implicit argument named "self".

> but that are
> not capable of (directly) operating on instances.

All functions, whether pure C functions or Objective-C methods, are capable of 
directly operating on instances.  They can instantiate objects, message them, 
and depending on scope, they can directly access their ivars.

The distinction you may be getting at is that only Objective-C instance methods 
can directly access ivars without having to qualify them with "self->", because 
the "self" is implicit.

--Andy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Oleg Krupnov]

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 it though is that the user should launch the crashed app at least
one more time. Hopefully, it's not going to be a crash on first launch
followed by immediate trashing of the app :)

So it boils down to these questions:

1. What is the correct way of terminating the app if the exception
happens in the main thread? I need the system Crash Reporter to save
the context and stack trace of the original problem, not of some
exception handler.

2. Will it work in sandboxed mode? The folder with crash reports may
appear unaccessible.

P.S. It dawned at me that I could relaunch another instance of the app
(using a shell script) before my app terminates, in this way relying
on the user to do this is not needed.

Thanks.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

LayoutSubviews after orientation change in inactive tab

[Trygve Inda]

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 UIDeviceOrientationDidChangeNotification to The scrollView in
Tab #1 that needs to get resized, but am not sure how to force the
ScrollView frame to auto-resize itself.


Thanks,

Trygve



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

CALayer autoresizing difficulties

[livinginlosangeles]

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 
for my centered layer:



_playLayer = [PlayerButtons genericPlayButton];

[_playLayer setAutoresizingMask:kCALayerMinXMargin | kCALayerMaxXMargin | 
kCALayerMinYMargin | kCALayerMaxYMargin];

[_playLayer setPosition:CGPointMake(CGRectGetMidX([[self layer] frame]), 

CGRectGetMidY([[self layer] 
frame]))]; 

According to this code, the CALayer should be centered, and as the NSView's 
bounds change, the CALayer's frame should adjust to stay centered in the view 
while the layer's bounds don't change. However, my special CALayer's bounds 
grow as I expand my main view.



Patrick


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Any way to get a static table view to update its footer?

[Rick Mann]

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 deselecting it.

Short of creating and returning a UILabel for the footer, is there a way to get 
a static table (in a UIStoryBoard) to update the footer text?


-- 
Rick




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Michael Crawford]

> 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 my code has "@interface Foo" and "@implementation Foo",
then in addition to possibly multiple instantions of Foo objects,
there is a _single_ Foo "class object".  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 methods" that know all about their "class object", but that are
not capable of (directly) operating on instances.

C++ has the concept of class member functions, as well as class data
members, but in the case of C++, it's all implemented purely by
scoping.  There is no actual class object.  Instead class member
functions know all about what is declared in the scope of the class,
but do not have access to "this".  Class data members, more or less,
are stored and implemented just like global data variables, as
individual items that are not, in general required to be actually
stored adjacent to each other in a single record.

Some of the really cool things that one can do with certain languages
other than C++, is to manipulate those class objects as if they were
some regular kind of data.  I can't come up with a meaningful example
for you just now though.

I'm not that familiar with Javascript, but my understanding is that
Javascript functions are actual objects, that are implemented by data
records stored in memory, rather than, as in C or C++, simply the
memory addresses of code entry points.

Michael David Crawford P.E., Process Architect
Solving the Software Problem
li...@warplife.com
http://www.warplife.com/mdc/

   Don't Fix the Bugs.  Fix the People that _Cause_ the Bugs.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTrackingRect not always working

[Quincey Morris]

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 generate mouseExited, mouseEntered, cursorUpdate, and mouseMoved 
> messages in that order.

You could try specifying the 'NSTrackingAssumeInside' option too. Previously, 
the documentation for this option was wildly incorrect. It has now been 
corrected, but it now recommends not using the option, whereas it has always 
seemed to me that it would be more often wanted than not. It *might* have an 
effect in the scenario you described.

If that doesn't help, I'd suggest removing the 'NSTrackingActiveInKeyWindow' 
option, and checking the key window status yourself, rather than trying to get 
NSTrackingArea to filter your state for you. NSTrackingArea is not as 
sophisticated as the wealth of options might suggest, and it's often necessary 
to micro-manage things yourself, even when your app is not active, or your 
window is not main or key, or whatever.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Palettes not taking advantage of fullscreen mode

[Steve Mills]

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 Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSTrackingRect not always working

[Steve Mills]

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 | NSTrackingMouseEnteredAndExited | 
NSTrackingActiveInKeyWindow) owner:self userInfo:nil];

I then do these steps:

1. Move the mouse into the view with the tracking rect (we'll call this window 
A).
2. Hit a key that causes a modal dialog to be presented. The dlog only 
intersects with a portion of window A, so I have to move the mouse over to the 
dlog. No mouseExited message is sent to window A because it's no longer the key 
window.
3. Dismiss the dlog and quickly move the mouse back into window A.

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 
generate mouseExited, mouseEntered, cursorUpdate, and mouseMoved messages in 
that order.

Has anyone else seen this? Any ideas about solving it? I guess we could remove 
the tracking rect on windowDidResignKey and reinstall it on windowDidBecomeKey, 
but I'd rather have the OS work correctly in the first place and not have to 
hack around this possible bug.

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Kyle Sluder]

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 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 are not OOP, and do not go through method dispatch 
> >> overhead. To turn around and inject direct access to ivars in those is 
> >> really mixing metaphors.
> > 
> > One reason people might directly access ivars applies to methods as well as 
> > functions: the class may not have a getter method for that ivar.  Now, 
> > there is a school of thought that says ivars should *always* be accessed 
> > via a getter method, except in init and dealloc, and if necessary a 
> > "private" getter should be added.  If one does not subscribe to that school 
> > of thought, and accesses ivars directly in methods, I personally don't 
> > think it's a *huge* deal to do so in functions, especially since the 
> > function has to be inside the @implementation section and it won't be a 
> > commonplace thing.  But as always, I'm happy to code to the accepted norms 
> > of whatever team I'm on.
> 
> I'd go for [foo valueForKey:@"privateIvar"] over foo->privateIvar.

Why? It's morally equivalent, except it's slower, opaque to the
compiler, and reliant on the horrible default behavior of
+accessInstanceVariablesDirectly returning YES.

As far as I'm concerned, C functions that exist inside an
@implementation block are statically-dispatched instance methods.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Trying to understand/prevent crash using restorableStateKeyPaths in NSPersistentUI Work

[Lee Ann Rucker]

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 now I have one new window and windowController 
>> - stopped in the window creation code - and one old window that would've 
>> been dealloc'ed if the code had just run a bit longer.
> 
> So that really does sound like a memory management problem -- the old window 
> controller is deallocated while another thread is preparing to tell it to 
> save its restorable state -- but it's not all clear at what level the problem 
> exists (app or frameworks). Perhaps the new window creation is irrelevant 
> except to the extent that it might delay the other-threaded save of 
> restorable state.
> 
> For what its worth, I have state restoration working without crashes in an 
> ARC app. I use the 'encodeRestorableStateWithCoder' approach to save the 
> frame rect (for the purpose Eric described), and there is a bit of extra 
> complexity because I'm restoring the state for a 
> multiple-window-of-the-same-type-per-document app. The complexity is in the 
> NSDocument subclass, not the window controller.
> 
> I remember I had a lot of trouble with the state restoration, but I don't 
> recall any of it being due to the kind of crash you're seeing -- it was a 
> year or more ago that I was working on it.
> 
> The only thing I can suggest, if you're still interested in experimenting, 
> would be to try deferring the release of the window controller to the next 
> iteration of the run loop (or, even more bluntly, to leak all the window 
> controllers for the purpose of testing) and see if the crash disappears. You 
> might at least find a workaround if you can defer deallocation for just long 
> enough.
> 
Yeah. When I have time I'll experiment more and file a bug if necessary.

I've got the encodeRestorableState set too and having that by itself works just 
fine; nothing ever seems to call that on a zombie.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Palettes not taking advantage of fullscreen mode

[Lee Ann Rucker]

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. However, something is causing the palettes to move back into the 
> pre-fullscreen screen bounds as if the menubar is still visible. The 
> palette's constrainFrameRect:toScreen: is being called with nil for the 
> screen. If I let the super handle this, it repositions it as if the menubar 
> were still visible. Why? Is that supposed to be standard behavior? If so, I 
> guess I'll override constrainFrameRect:toScreen: so it doesn't do that.

The Apple sample code for fullscreen custom animation overrides 
constrainFrameRect:toScreen: so I assume the default implementation isn't 
fullscreen-savvy.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Lee Ann Rucker]

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 some 
>>> reason.
>> 
>> Yes. Because what is the point of plain C functions in Objective-C files? 
>> Local helpers that are not OOP, and do not go through method dispatch 
>> overhead. To turn around and inject direct access to ivars in those is 
>> really mixing metaphors.
> 
> One reason people might directly access ivars applies to methods as well as 
> functions: the class may not have a getter method for that ivar.  Now, there 
> is a school of thought that says ivars should *always* be accessed via a 
> getter method, except in init and dealloc, and if necessary a "private" 
> getter should be added.  If one does not subscribe to that school of thought, 
> and accesses ivars directly in methods, I personally don't think it's a 
> *huge* deal to do so in functions, especially since the function has to be 
> inside the @implementation section and it won't be a commonplace thing.  But 
> as always, I'm happy to code to the accepted norms of whatever team I'm on.

I'd go for [foo valueForKey:@"privateIvar"] over foo->privateIvar.

> 
>>> Which reminds me... instance methods can also directly access the ivars of 
>>> *other* instances of the same class.
>> 
>> Now, *that* I knew. I'm sorry senator, I cannot recall if I ever did such a 
>> thing. But I knew it was possible ;-)
> 
> So noted, and we thank you for your testimony today. :)
> 
> --Andy
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/lrucker%40vmware.com
> 
> This email sent to lruc...@vmware.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Quincey Morris]

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 undeserved. On balance it's better to carry on with some minor 
> glitch than "quit unexpectedly".

Surely the problem with this perspective is that the uncaught exception results 
in an abrupt transfer of control from the point of the exception back to 
(approximately) [NSApplication sendEvent:]?

If you don't own the low-level code where the exception was thrown, you can 
have no confidence that non-stack data structures being maintained by that code 
-- along with all of the intermediate levels of calling code -- are in any 
usable state.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting a splash screen to show

[Quincey Morris]

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 clear 
relationship between app launching (how the user sees it) and process creation 
(how the system sees it). In a modern application, it's quite possible for the 
app's process to exit when the app is in the background, and to start up again 
when the app is brought to the foreground. A user wouldn't expect to see a 
splash screen in that case.

You *could* opt out of auto-termination, if your app's startup is too slow to 
fit this "secret launch" scenario, but you'd be fighting the technological 
current, which says it really matters to avoid the consumption of resources 
(such as battery power) by inactive apps.

> 2) Talk to the marketing director.  Splash screen is company branding.

I see the power that this exerts over marketing directors' mental processes, 
but it's a pretty strange argument for all that. If the user is watching the 
splash screen, then they're already using your app, and the marketing task is 
already done.

The only apps I currently own which have splash screens are in Adobe's Creative 
Suite. Maybe it's just me, but what I think about while I sit and watch 
Illustrator's splash screen linger on my display is the way it seems to glory 
in emphasizing how slow its own startup is, and -- on some days -- this gives 
me time to think about what other brand to go purchase instead. Conversely, I 
could mention Panic Coda (one example out of many) as an app whose branding is 
in-your-face crystal-clear, almost to a fault, with no splash screen in sight.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Palettes not taking advantage of fullscreen mode

[Steve Mills]

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 the 
pre-fullscreen screen bounds as if the menubar is still visible. The palette's 
constrainFrameRect:toScreen: is being called with nil for the screen. If I let 
the super handle this, it repositions it as if the menubar were still visible. 
Why? Is that supposed to be standard behavior? If so, I guess I'll override 
constrainFrameRect:toScreen: so it doesn't do that.

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Graham Cox]

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* contentious statement. 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 undeserved. On balance it's better 
to carry on with some minor glitch than "quit unexpectedly". I guess if you are 
really concerned about this, install your own top-level handler.

JM2¢W

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: UIButton events on a CALayer

[David Duncan]

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?


You should follow Kyle's advice, but at the heart of your problem is that 
CALayers don't understand events in any way shape or form, thats what UIView 
adds. By interposing a CALayer, you've effectively broken the event handling 
and thus broken your button.
--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Quincey Morris]

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. You should also ensure 
that there's an autorelease pool in place, especially when using ARC (which may 
invoke 'autorelease' at times you can't easily predict).

Thus, I would advocate an approach based on the one Jean-Daniel mentioned 
earlier in the thread: move the code that does the actual work needed in the 
callback to a separate *method*, but hide your housekeeping -- the ugly bits -- 
in the function itself:

static int MyCallback (void* context) { // assuming the parameter is 
just the object pointer
@autoreleasepool {
int result = [(__bridge MyClass*) context 
myCallbackMethod];
return result;
}
}

In the case where the context is actually a structure containing the object 
pointer, then I'd retrieve it in this function (and likely all the other 
structure members, to pass as arguments to the method, unless there are an 
awful lot of them) so that the method can be written cleanly using normal ObjC 
conventions.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting a splash screen to show

[Kyle Sluder]

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 2000 CPU instructions per *pixel*.

1. NSAtrributedString drawing time is almost certainly proportional to string 
length, not number of pixels covered.

2. Unless you're constantly invalidating the window, how often are you actually 
going to draw the text? Once.

3. If you're concerned about string drawing, then by definition your window 
isn't empty.

>   - It takes longer to _recursiveTickleNeedsDisplay a view hierarchy than 
> it does to draw a splash screen NSImage.

This is a serious allegation, considering drawing a splash screen involves 
displaying a view hierarchy anyway.

What kind of view hierarchy do you have? How are you measuring this time? Do 
you frequently override -setNeedsDisplay: or -viewWillDraw?

>   For this reason I suppress any document window drawing or other unnecessary 
> NSTimers while loading.

This is, of course, a good idea. Running with the inference that you have an 
extremely deep view hierarchy, you might benefit further by delaying adding 
your subviews until your document is done loading.


>   If you want to talk about optimizing, why don't you analyze how much 
> _recursiveTickleNeedsDisplay you're doing before your app is ready to draw 
> anything.

I've _never_ seen _recursiveTickleNeedsDisplay show up in a sample.


> Apple has become more focused on its $.99 Mac App Store apps.
> I notice there are very few products in the Mac App store that cost > $99

True, but I happen to work for a company that makes a couple. None of them has 
or needs a splash screen.

--Kyle Sluder

> 
> 
> 
> On Jul 29, 2013, at 4:08 PM, Keith Knauber 
> mailto:kknau...@prg.com>> wrote:
> 
> I can't have my splash screen get stuck on, and obscure anything in case a 
> modal dialog decides to present itself.
> 
> The general recommendation is to avoid splash screens altogether. If your app 
> takes long enough to launch that the user would have time to read a splash 
> screen, you're better off putting the effort into profiling and optimizing 
> the startup path so the splash screen isn't necessary.
> 
> —Jens
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/kyle%40ksluder.com
> 
> This email sent to k...@ksluder.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting a splash screen to show

[Keith Knauber]

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 to _recursiveTickleNeedsDisplay a view hierarchy than 
it does to draw a splash screen NSImage.
   For this reason I suppress any document window drawing or other unnecessary 
NSTimers while loading.
   If you want to talk about optimizing, why don't you analyze how much 
_recursiveTickleNeedsDisplay you're doing before your app is ready to draw 
anything.
2) Talk to the marketing director.  Splash screen is company branding.  The 
splash screen is really the only place where my app does any branding.
Apple has become more focused on its $.99 Mac App Store apps.
I notice there are very few products in the Mac App store that cost > $99



On Jul 29, 2013, at 4:08 PM, Keith Knauber 
mailto:kknau...@prg.com>> wrote:

I can't have my splash screen get stuck on, and obscure anything in case a 
modal dialog decides to present itself.

The general recommendation is to avoid splash screens altogether. If your app 
takes long enough to launch that the user would have time to read a splash 
screen, you're better off putting the effort into profiling and optimizing the 
startup path so the splash screen isn't necessary.

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[John McCall]

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 bridge-cast *that* object when passing it to the callback.
> 
> Makes me think of that French saying: “it’s like using a pneumatic drill to 
> crack a nut”.

I would say that this is *a* recommended solution, and yes, it can be massive 
overkill.  The __unsafe_unretained solution is more efficient if you can make 
it safe.  If that’s not acceptable, __strong and __weak fields are allowed in 
Objective-C++, where the generated constructors and destructor will manage the 
retain/release operations for you; if you need to heap-allocate the struct, 
just be sure to use new/delete instead of malloc/free.  All of these are 
reasonable solutions.

One final, ugly option that is *not* recommended but can nonetheless work is to 
make the field itself a void* and manage the lifetime manually with bridge 
casts.

Functions defined in the @implementation have access to private ivars because 
they’re clearly part of the implementation.  Our recommendations about avoiding 
direct access to ivars are generally directed towards code that’s not part of 
the class’s implementation.  Within the implementation, there can be many good 
reasons to directly access ivars; for example, you might specifically not want 
KVO to fire for some particular change, or you might not care about KVO and 
need the performance benefits of direct memory access, or you might not want to 
publicize getters or setters for the ivar.

John.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Sean McBride]

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 an
>external watchdog process or collect the crash report file on next launch.

Oleg's problem is basically the same as an issue I have.

Basically, when a Objective-C exception (from one's own code, third party 
libraries, or the OS) is thrown and not caught, the OS does what?  The answer 
depends on a few things: 

 1) which thread did it happen on?
 2) have you called NSSetUncaughtExceptionHandler(), see:

 3) the value of NSApplicationShowExceptions, see:


The next question is: what would be nice to do in response?  Ideally, a UI 
would be shown allowing the user to submit the crash report over the internet.  
Presenting this UI from the same process is probably a bad idea since the 
process is in a bad state.  So I guess the best thing to do is let the OS kill 
the process and create a crash log, which you can then read when you relaunch 
(modulo sandbox issues).

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Vincent Habchi]

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 one is crossed-off; I was wondering if this was an 
Xcode bug.

> So you'd be able to access the myObj member of the struct without having to 
> cast.  But you'd have to make sure myObj doesn't get dealloc'ed before the 
> struct is used (i.e., before the callback is invoked), so maybe you wouldn't 
> be doing any less work code-wise.

No, it would be perfectly fine. The way SQLite works, after a query is 
submitted, the thread is suspended and a callback is repeatedly executed to 
store each row of the result, until the response is exhausted; the query-thread 
is then released (i.e. the query submission call returns). So there is no risk 
for the calling object to be de-allocated (at least the way I code it).

> 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 bridge-cast *that* object when passing it to the callback.

Makes me think of that French saying: “it’s like using a pneumatic drill to 
crack a nut”.

Thanks for everybody’s advice.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Jean-Daniel Dupas]

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 plain C functions in Objective-C files? 
> Local helpers that are not OOP, and do not go through method dispatch 
> overhead. To turn around and inject direct access to ivars in those is really 
> mixing metaphors.
> 
>> Which reminds me... instance methods can also directly access the ivars of 
>> *other* instances of the same class.
> 
> Now, *that* I knew. I'm sorry senator, I cannot recall if I ever did such a 
> thing. But I knew it was possible ;-)

I think I don't have a single copyWithZone: implementation that does not use 
this feature.

Foo *copy = [super copyWithZone:];
copy->_myivar = _myivar;

Especially as all ivars are not exposed as properties.


-- Jean-Daniel





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Andy Lee]

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 plain C functions in Objective-C files? 
> Local helpers that are not OOP, and do not go through method dispatch 
> overhead. To turn around and inject direct access to ivars in those is really 
> mixing metaphors.

One reason people might directly access ivars applies to methods as well as 
functions: the class may not have a getter method for that ivar.  Now, there is 
a school of thought that says ivars should *always* be accessed via a getter 
method, except in init and dealloc, and if necessary a "private" getter should 
be added.  If one does not subscribe to that school of thought, and accesses 
ivars directly in methods, I personally don't think it's a *huge* deal to do so 
in functions, especially since the function has to be inside the 
@implementation section and it won't be a commonplace thing.  But as always, 
I'm happy to code to the accepted norms of whatever team I'm on.

>> Which reminds me... instance methods can also directly access the ivars of 
>> *other* instances of the same class.
> 
> Now, *that* I knew. I'm sorry senator, I cannot recall if I ever did such a 
> thing. But I knew it was possible ;-)

So noted, and we thank you for your testimony today. :)

--Andy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Andy Lee]

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 the code is compiled as Objective-C or Objective-C++.  All 
you need is...

> You will need some way for your C callback to be told what "self" is.

...bearing in mind that within the C function it doesn't have to be called 
"self".  It *can* be, if that makes things clearer, but as Jean-Daniel 
mentioned, "self" has no special meaning within a C function.  Depending on the 
situation, "self" might be a *more* confusing name; personally, I would use 
something else in most if not all cases but that may be a matter of taste.

Whether you use the name "self" or not, you can't refer to ivars in a C 
function without a qualifier:

@implementation MyClass

- (void)myMethod
{
NSLog(@"%@", _myIvar);  // okay because of implicit "self"
}

void myFunction(MyClass *self)
{
NSLog(@"%@", _myIvar);  // compile error
NSLog(@"%@", self->_myIvar);  // compiles okay
NSLog(@"%@", self.myIvar);  // compiles okay if there is a myIvar property
[self myMethod];  // compiles okay
}

@end

--Andy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Scott Ribe]

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 are not OOP, and do not go through method dispatch overhead. To 
turn around and inject direct access to ivars in those is really mixing 
metaphors.

> Which reminds me... instance methods can also directly access the ivars of 
> *other* instances of the same class.

Now, *that* I knew. I'm sorry senator, I cannot recall if I ever did such a 
thing. But I knew it was possible ;-)


-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Ken Thomases]

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
> consistent with other parts of the AppKit. When an exception happens
> in the main thread, it is logged to the console and quietly absorbed
> without any additional action on my part.

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.


> Now if the exception happens in a non-main thread, I am obliged to
> catch it or otherwise the app will be instantly terminated. This is
> inconsistent. I may not be using or even expecting any exceptions in
> the thread, but merely use some NSAssert's and want to report logical
> errors in my code. Putting explicit @try/@catch in every thread with
> NSAssert's seems like an overkill or even something I should not rely
> upon, because I want to write a catch-all for problems, including my
> own bugs, such as forgetting to wrap the thread in @try/@catch.

The point of asserts is to fail early and very noticeably.  Terminating the 
process is good.  The fact that Cocoa's asserts throw exceptions and, 
therefore, can be quietly absorbed by AppKit's main event loop is bad.  
Consider replacing your use of Cocoa asserts with custom asserts.  See this, 
for example:
http://www.mikeash.com/pyblog/friday-qa-2013-05-03-proper-use-of-asserts.html


>> If you exit a thread that you don't own, you may screw up your app's ability 
>> to present a dialog.  Perhaps AppKit relies on that thread.  Perhaps the 
>> thread held a crucial resource and other threads will deadlock when they try 
>> to access it.
> 
> 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 entire app from termination
> and so far it seems darn impossible.

The difference is precisely between terminating the process versus terminating 
a single thread but keeping the process alive and attempting to use frameworks 
whose internals may be corrupted.  Of course, the default behavior of 
terminating the process is safe.  It's the way you're trying to deviate from 
that that's not.


>> 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 an external watchdog process 
or collect the crash report file on next launch.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Andy Lee]

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->myIvar for direct access to 
>> instance variables.
> 
> Interesting, did not know that. Not sure I'll ever need it… Plain C is one 
> thing, plain C but with direct access to instance vars?

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.

Which reminds me... instance methods can also directly access the ivars of 
*other* instances of the same class.

- (void)myMethod
{
MyClass *otherInstance = [[MyClass alloc] init];

NSLog(@"%@", otherInstance->myIvar);
}

--Andy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Andy Lee]

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 to embed pointers to Obj-C objects in C-structs. So I just 
> bridge-cast it to void *.

A couple of alternatives, just for your consideration in case they hadn't 
occurred to you.

One alternative would be to use __unsafe_unretained.  ARC allows structs like 
this:

typedef struct _MyStruct {
__unsafe_unretained id myObj;
} MyStruct;

So you'd be able to access the myObj member of the struct without having to 
cast.  But you'd have to make sure myObj doesn't get dealloc'ed before the 
struct is used (i.e., before the callback is invoked), so maybe you wouldn't be 
doing any less work code-wise.

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 
bridge-cast *that* object when passing it to the callback.

--Andy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Scott Ribe]

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.

Interesting, did not know that. Not sure I'll ever need it… Plain C is one 
thing, plain C but with direct access to instance vars?

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Andy Lee]

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 method? I.e. can it freely access ‘self’ 
>> and other attributes?
> 
> No; it'll be a stand-alone method with no implicit knowledge of the 
> Objective-C class.

This may be pedantic, but just to clarify: if you put a C function in MyClass's 
implementation file you aren't really "embedding" it in the sense that some 
people might think you mean.  There is no formal association between MyClass 
and the function, MyClass doesn't know about the function, and you can't call 
the function as if it were a method.  The function is not a method, stand-alone 
or otherwise.

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.

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.

--Andy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Kyle Sluder]

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 not
> consistent with other parts of the AppKit. When an exception happens
> in the main thread, it is logged to the console and quietly absorbed
> without any additional action on my part.

libdispatch is not part of AppKit.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Leak when "drawing too fast"

[Andreas Mayer]

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. The Window server only manages layers 
> and triggers redraws. The actual drawing is still done by Quartz in your 
> process.

Ops. Missed this.

I'm essentially just drawing once and then moving bitmaps around. Before, I was 
redrawing the bitmaps at their new positions manually, which wasn't too bad 
since the system seems to optimize that case already. Now the window server is 
doing the moving around. My CPU is down to around 1% most of the time while the 
window server's is up by about 3,5%.


Andreas
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[KappA]

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 parameters you can create a struct that stores what you need and
pass that. Not sure if this helps but figured I'd mention it.

AppDelegate *d = [[UIApplication sharedApplication] delegate];



On Tue, Jul 30, 2013 at 8:53 AM, lowell  wrote:

> 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,
> >
> > 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
> >
> >
> >
> >
> > ___
> >
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> > https://lists.apple.com/mailman/options/cocoa-dev/lowellv%40me.com
> >
> > This email sent to lowe...@me.com
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/rejekted%40gmail.com
>
> This email sent to rejek...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Scott Ribe]

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 entire app from termination
> and so far it seems darn impossible.

The entire app is about to terminated precisely because the thread is in an 
unknown corrupt state, likely having corrupted the heap or stack, and possibly 
holding a crucial lock or other resource, so continuing is completely 
unreliable.

If your goal is to present a dialog to the user and ask that the user send 
diagnostic info to you, use an external process monitoring your logs and/or 
crash reports. (And don't try to log after an unhanded exception; log info 
before.)

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Leak when "drawing too fast"

[Andreas Mayer]

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 next time *by 
> definition*.

In that case redraw would lag a bit behind, which wouldn't be a problem in my 
case. But the timers piling up suggests, that this is more of a fundamental 
mistake to make.

Thanks Uli. I might give this solution a try just to see if I can get it to 
work. :)


Andreas
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[lowell]

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,
> 
> 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
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/lowellv%40me.com
> 
> This email sent to lowe...@me.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[j.carlson]

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
side effects.

Ken's right. The side effects may be significant, and you shouldn't assume that 
it will not impact system/foreign implementations executing in that context 
(i.e. thread). When an exception is thrown, the program unwinds. This gives 
other implementations the opportunity to perform their cleanup, even though 
*your* implementation may not do anything meaningful when unwinding. 
Killing/exiting the thread at an arbitrary point in execution is more likely to 
leave other implementations in unspecified states. A (non-shared) int on the 
stack is not a concern, but what if your thread's autorelease pools were never 
drained or locked shared resources never unlocked?

I just want to prevent the entire app from termination
and so far it seems darn impossible.
> All in all, what you're doing seems like a bad idea.
Maybe but what is the right solution to this?

The easy way is to just not introduce exceptions into your Cocoa programs, and 
to design with appropriate error handling and recovery in mind. That also means 
preventing your implementation from doing something which would cause an API 
you call to throw. If you use an implementation which throws (e.g. C++), forbid 
that exception from entering your Cocoa implementations. Some Cocoa APIs throw, 
but those errors are generally nonrecoverable and you should not try to handle 
them (you could prevent them, if it is your error). This default 'works' for 
most projects.
Defending your implementation from anything that could possibly throw while 
being prepared to appropriately handle what *could* be thrown without context 
is futile at this abstraction level. If you really insist you should intercept 
this information and think you can do meaningful things with it or allow 
meaningful tasks on other threads to complete, another angle would be to 
specify the thread's NSAssertionHandler instance in the -[NSThread 
threadDictionary] (key: NSAssertionHandlerKey). However, there's not much good 
you can do here beyond noting the error for future presentation or your log for 
review and immediately exiting -- I would not bother forcing an alert through 
to the user on the dying process' main run loop.___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[j.carlson]

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; charset=ISO-8859-1

Thanks for your answer, Steve, but the problem remains.

In my case, the exception has already been thrown inside the block and
I cannot catch it or modify it in any way in my handler. I'm basically
writing an uncaught exception handler. My app should show a crash
report window and then terminate itself.


Shortest path in this case may be to wrap dispatch_async() and pass a block 
which executes the block parameter (currently passed to dispatch_async()) but 
this added block introduces your exception handling. Be sure to copy the block 
parameter, as dispatch_async() would.

Remember that exceptions originating from Cocoa APIs are generally 
nonrecoverable (C++ implementations OTOH are generally designed to be safe to 
catch and resume -- recoverable without leaking resources or leaving them in 
potentially invalid states).

Assume killing threads is never an option ;) Just let them exit naturally so 
that all implementations within that context may conclude what they are in the 
process of executing. Sometimes that means you must choose (or design) more 
robust implementations.

So when you catch that halting exception, then you can add some work to the 
main run loop (e.g. to present the alert). You should then suspend the thread 
which handled the exception (until your process is exited from the other thread 
after the alert you mentioned was presented) to avoid returning control flow to 
the implementation/queue which executed your block. Make sure your presentation 
is quick and always exits, and avoid creating autoreleased objects in the 
suspended thread (the pools will not be drained).

Of course, if it's your API that throws nonrecoverable exceptions you should 
just use another mechanism for error handling to avoid all the above (and 
perhaps recover gracefully).___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Oleg Krupnov]

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 an exception happens
in the main thread, it is logged to the console and quietly absorbed
without any additional action on my part.

Now if the exception happens in a non-main thread, I am obliged to
catch it or otherwise the app will be instantly terminated. This is
inconsistent. I may not be using or even expecting any exceptions in
the thread, but merely use some NSAssert's and want to report logical
errors in my code. Putting explicit @try/@catch in every thread with
NSAssert's seems like an overkill or even something I should not rely
upon, because I want to write a catch-all for problems, including my
own bugs, such as forgetting to wrap the thread in @try/@catch.

> If you exit a thread that you don't own, you may screw up your app's ability 
> to present a dialog.  Perhaps AppKit relies on that thread.  Perhaps the 
> thread held a crucial resource and other threads will deadlock when they try 
> to access it.

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 entire app from termination
and so far it seems darn impossible.

> All in all, what you're doing seems like a bad idea.

Maybe but what is the right solution to this?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Jean-Daniel Dupas]

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; some say otherwise. So it’s a bit difficult to find a 
> definitive answer thereon.

If it is in the implementation block, you can access all private ivar and 
property, but only if you have a reference to self in the first place.

For instance, you can have this:

@implementation Foo {
id privateVar;
}

static inline void internalInlineFunction(Foo *self) {
// do something with self->privateVar.
}

- (void)publicMethod {
internalInlineFunction(self);
}

@end

I'm using this trick when I need inline code (something that can't be done with 
Obj-C method), but for a callback, I would rather just keep it simple and 
simply call a method to handle it.

@implementation Foo

static void callback(void *ctxt) {
// Sidenote; 'self' is a reserved keyword only inside Obj-C method 
body. You can use it freely elsewhere, and it does not have special meaning.
// that's why you have to pass it as explicit parameter.
Foo *self = (Foo *)ctxt;
[self handleCallback];
}

- (void)handleCallback {
// 
}

@end


> 
>> Having said that, most callback APIs allow you to pass a context parameter 
>> that gets passed back to your C callback. Often times, this context 
>> parameter is a void* you pass in along with a pointer to your callback 
>> function. You can pass "self" in this parameter when you register the 
>> callback, then cast it inside your callback back to MyClass* (or whatever 
>> your class is).
> 
> 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 to embed pointers to Obj-C objects in C-structs. So I just 
> bridge-cast it to void *.
> 
> Assuming the pointer to the struct is named ‘info’ and the field containing a 
> reference to ‘self’ is called ‘this’, [info->this someMethod] as well as 
> info->this->someAttribute are legal, aren’t they?
> 
> Thanks a lot!
> Vincent
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
> 
> This email sent to devli...@shadowlab.org

-- Jean-Daniel





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Rick Mann]

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 say otherwise. So it’s a bit difficult to find a 
> definitive answer thereon.
> 
>> Having said that, most callback APIs allow you to pass a context parameter 
>> that gets passed back to your C callback. Often times, this context 
>> parameter is a void* you pass in along with a pointer to your callback 
>> function. You can pass "self" in this parameter when you register the 
>> callback, then cast it inside your callback back to MyClass* (or whatever 
>> your class is).
> 
> 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 to embed pointers to Obj-C objects in C-structs. So I just 
> bridge-cast it to void *.
> 
> Assuming the pointer to the struct is named ‘info’ and the field containing a 
> reference to ‘self’ is called ‘this’, [info->this someMethod] as well as 
> info->this->someAttribute are legal, aren’t they?

I think you can embed the pointer, but you might have to qualify it with 
something to make ARC happy (it probably can't auto-nil it inside a C struct, 
so you have to use one of the other storage modifiers).

Alternatively, you can put your additional metadata in your object, and just 
pass self with appropriate ARC bridging (almost certainly no retain/transfer of 
ownership).

-- 
Rick




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Vincent Habchi]

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 answer thereon.

> Having said that, most callback APIs allow you to pass a context parameter 
> that gets passed back to your C callback. Often times, this context parameter 
> is a void* you pass in along with a pointer to your callback function. You 
> can pass "self" in this parameter when you register the callback, then cast 
> it inside your callback back to MyClass* (or whatever your class is).

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 to embed pointers to Obj-C objects in C-structs. So I just bridge-cast 
it to void *.

Assuming the pointer to the struct is named ‘info’ and the field containing a 
reference to ‘self’ is called ‘this’, [info->this someMethod] as well as 
info->this->someAttribute are legal, aren’t they?

Thanks a lot!
Vincent


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Michael Crawford]

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 expect, as C
functions that have some "extra stuff" attached, for example to pass
in "self" as a hidden (first I think) parameter.

Try writing a small Objective-C method, that calls another one in the
same source file.  Then in Xcode, use Product -> Generate Output ->
Assembly File to see how that first method calls the second.

You will need some way for your C callback to be told what "self" is.

Mike Crawford
li...@warplife.com
http://www.warplife.com/

On Tue, Jul 30, 2013 at 7:59 AM, Vincent Habchi  wrote:
> 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
>
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/lists%40warplife.com
>
> This email sent to li...@warplife.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mixing Obj-C and C "methods"

[Rick Mann]

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 attributes?

No; it'll be a stand-alone method with no implicit knowledge of the Objective-C 
class.

Having said that, most callback APIs allow you to pass a context parameter that 
gets passed back to your C callback. Often times, this context parameter is a 
void* you pass in along with a pointer to your callback function. You can pass 
"self" in this parameter when you register the callback, then cast it inside 
your callback back to MyClass* (or whatever your class is.

Precisely how you do this depends on the API you're using.

If it's a non-Apple API, it's much more likely they did it wrong and did not 
provide a context parameter.

What API are you using?

-- 
Rick




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Mixing Obj-C and C "methods"

[Vincent Habchi]

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




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com