date:20090317

Re: Enforcing trial software on Mac

2009-03-17 Thread Jean-Daniel Dupas



Le 17 mars 09 à 03:46, Jeff Laing a écrit :


I have seen a couple of fairly nice solutions, and lots of really
awful ones.  Generally speaking, the awful ones try to go to great
lengths to be sneaky and hide files or other data in places in your
computer they shouldn't be messing with.


Its worth pointing out that most hacker-types know about 'fs_usage' -
there's little hiding that your app can do without being seen by  
those

who want to know.

http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man1/
fs_usage.1.html


Very good point, and for those who don't know about fs_usage,  
Instrument (known by all developers) provide a similar facility.


I really don't like softwares that write random files where it should  
not.



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Garbage Collection, Core Foundation, and the -finalize problem

2009-03-17 Thread Bill Cheeseman



On Mar 16, 2009, at 2:32 PM, Michael Tsai wrote:


On Mar 16, 2009, at 2:08 PM, Bill Cheeseman wrote:

I am looking for a strategy to avoid implementing a -finalize  
method in a garbage-collected Objective-C class that declares a  
CFTypeRef-style Core Foundation instance variable. I believe this  
is a fairly common problem, because any Cocoa wrapper class for a  
Core Foundation API would have to do it, but I haven't seen a  
usable solution. Apple's GC documentation stops just short of  
suggesting an answer.



I believe you're supposed to declare your CFTypeRef ivar as __strong  
and call CFMakeCollectable so that the garbage collector will be  
responsible for releasing it. You can still use CFRelease in - 
dealloc for when you aren't running under garbage collection.


After thinking on this overnight, I have concluded that in a mixed- 
mode framework the best practice is indeed to call CFMakeCollectable  
as soon as the CFTypeRef ivar is created so that garbage-collected  
clients can ignore memory management issues.


As a corollary, when the problem domain served by the framework is  
such that there is no convenient way to know when to call an - 
invalidate method, simply put all the cleanup code in -finalize and be  
done with it.


But perhaps even in this situation, it would be good practice to  
provide -invalidate and -isValid methods, and write -finalize so that  
it checks -isValid before calling -invalidate itself. This way,  
clients who do know when to call -invalidate can do so.


This leaves unresolved the need in some cases to do cleanup work  
before -finalize because of order-of-execution issues with -finalize.  
My tentative conclusion is that this is a huge can of worms for  
garbage collection when CFTypeRef ivars are involved.


--

Bill Cheeseman
b...@cheeseman.name

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

How can i change the view.

2009-03-17 Thread haresh vavdiya

Hi,

Actually i want to develop small application which is for register
and login.

I have set one box on MainMenu.xib and it should contain login view
and if i will press register then it should change the view to register view
in same box itself.

   I have one login view and one button which will derive to register
view. What should i do for that? any sample code or app?

Thanks,
Haresh.
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How can i change the view.

2009-03-17 Thread Ron Fleckner



On 17/03/2009, at 8:16 PM, haresh vavdiya wrote:


Hi,

   Actually i want to develop small application which is for  
register

and login.

   I have set one box on MainMenu.xib and it should contain  
login view
and if i will press register then it should change the view to  
register view

in same box itself.

  I have one login view and one button which will derive to  
register

view. What should i do for that? any sample code or app?

Thanks,
Haresh.


A tabless NSTabView might help you here.  I'd first have a look at  
using NSTabView, then google tabless NSTabView to find some sample  
code.


The effect is to essentially swap the views on your 'box' window.

Ron
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Double Initialize - is that how it should be?

2009-03-17 Thread Jim Correia

On Mar 16, 2009, at 10:21 PM, Steve Cronin wrote:

I use an object in my application called 'appDelegate'; it's a
subclass of NSObject.

I instantiate this object in the main Nib file
This object has IBActions for the main menu and since it is -app
delegate it is a kind on central dispatcher.

My question is this:
The +initialize is run twice when the app loads:
2009-03-16 20:21:42.690 XYZ[6676:813] *[AppDelegate initialize]
2009-03-16 20:21:42.781 XYZ[6676:813] *[NSKVONotifying_AppDelegate
initialize]

Once for the object itself and then again as the instance in the
Nib. That's how I read this. Is that wrong?

The specific reason that you got +initialize twice has to do with an
implementation detail of automatic KVO.

There are also other reasons that you could get +initialize twice.
(For example, a subclass of yours doesn't implement initialize.)

This is discussed in the NSObject documentation, and the pattern to
use to avoid double initialization is given.

http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/nsobject_Class/Reference/Reference.html#/
/apple_ref/occ/clm/NSObject/initialize

56 matches

Mail list logo