Re: Cocoa replacement for Carbon CompositeIconRef() for Snow Leopard 64-bit apps?

[Dalmazio Brisinda]

Kyle, if I had my way, that's exactly what I would be doing... alas!   
It's presently out of my control. I'm stuck with dealing in IconRef's  
for the time being...


Best,
Dalmazio



On Mon, Oct 26, 2009 at 10:26 PM, Dalmazio Brisinda > wrote:
If there's a way to extract an IconRef from an NSImage (I see that  
NSImage
has an -initWithIconRef: method defined) after doing all  
compositing via

NSImage and related classes that would be good too.


Sounds like you should move all of your code to working with NSImage
rather than IconRefs.  As soon as you get an icon, you should convert
it into an NSImage and work with it from then on.

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

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

Re: Cocoa replacement for Carbon CompositeIconRef() for Snow Leopard 64-bit apps?

[Kyle Sluder]

On Mon, Oct 26, 2009 at 10:26 PM, Dalmazio Brisinda  wrote:
> If there's a way to extract an IconRef from an NSImage (I see that NSImage
> has an -initWithIconRef: method defined) after doing all compositing via
> NSImage and related classes that would be good too.

Sounds like you should move all of your code to working with NSImage
rather than IconRefs.  As soon as you get an icon, you should convert
it into an NSImage and work with it from then on.

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

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

Cocoa replacement for Carbon CompositeIconRef() for Snow Leopard 64-bit apps?

[Dalmazio Brisinda]

Hello all,

I'm working with a Snow Leopard 64-bit app that contains a Finder-like  
file browser that uses Carbon IconRef's. I'm trying to get the icons  
for the selected file with a custom overlay based on the current file  
selection and Icon Services. The problem I'm having is that the Icon  
Services CompositeIconRef() doesn't seem to work correctly. For  
example, if I provide


err = CompositeIconRef( targetIconRef, overlayIconRef,  
&compositeIconRef );

if (err != noErr) {
NSLog(@"CompositeIconRef() err = %d", err);
}

I don't get any errors, but all I get in the CompositeIconRef is the  
contents of the targetIconRef. If I swap the targetIconRef and  
overlayIconRef just for kicks, then I get just the contents of the  
overlayIconRef in the compositeIconRef. It looks like CompositeIconRef  
() only copies the source or target icon ref into the composite icon  
ref, completely ignoring the overlay icon ref.


Interestingly, the call seems to work fine for 32-bit applications.

If there's a way to extract an IconRef from an NSImage (I see that  
NSImage has an -initWithIconRef: method defined) after doing all  
compositing via NSImage and related classes that would be good too.


Any ideas or work-arounds really appreciated.

Best,
Dalmazio
___

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: Core Data: Undoing Cut-Paste, Drag-Drop between documents

[Quincey Morris]

On Oct 26, 2009, at 21:18, Jerry Krinock wrote:

But this answer is not as plausible if the user makes the move using  
drag-drop instead of cut-paste.  (Drag-drop is not implemented in  
DepartmentAndEmployees, but it is common in real apps.)  Clearly,  
the user has now performed only one operation, and might rightfully  
expect it to be undoable with a single Undo.


Actually, you're Doing It Wrong™. Look at:


http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGDragDrop/XHIGDragDrop.html#//apple_ref/doc/uid/TP3364-TPXREF30

Especially:

"The principle driving these drag-and-drop guidelines is to prevent  
the user from accidental data loss. Because an Undo command in the  
destination application does not trigger an Undo in the source  
application, moving data across applications may result in potential  
data loss."


Your drag is from one container to another, and should be a copy- 
paste, not a cut-paste.


Now, if you want to argue that *your* application should play by  
different rules, I won't argue, but you're going to have to do some  
heavy lifting to solve the inherent 2-document undo problem.



___

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: first responder being clobbered

[glenn andreas]

On Oct 26, 2009, at 10:55 PM, Michael Link wrote:

I have a custom UITableViewController that uses a custom cell that  
displays a text field. I have this method added to the table view  
controller to set the text field as first responder


- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];

	MLPropertyEditingTableViewCell* __cell =  
(MLPropertyEditingTableViewCell*)[self.tableView  
cellForRowAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:0]];


   [__cell.textField becomeFirstResponder];
}



What if you do it in "viewDidAppear" instead of "viewWillAppear"?

Since the view technically isn't on screen yet (only that it "will  
be"), setting a first responder shouldn't be done then.



Glenn Andreas  gandr...@gandreas.com
  wicked fun!
JSXObjC | the easy way to unite JavaScript and Objective C




___

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: Transitioning to GC-supported

[Jens Alfke]

On Oct 26, 2009, at 8:43 PM, Dave Keck wrote:


For example, I have an object that [self retain]; while it does some
work that takes awhile. I don't hold a reference to this object
anywhere after it's created - it simply notifies its delegate when its
finished.


I remember a thread about this a few weeks ago. I'm pretty sure that  
there will be a reference to that object somewhere, since it is either  
the the receiver of a message running on an NSThread, or the target of  
an NSTimer, or the delegate of an NSURLConnection, or something like  
that.


That is, it's either actively running (and thus has pointers to itself  
on the stack), or it's waiting for something else to call it via a  
pointer to it.


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

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

Core Data: Undoing Cut-Paste, Drag-Drop between documents

[Jerry Krinock]

Steps to Reproduce:

1.  Build Apple's DepartmentAndEmployees sample project.
2.  Launch it.
3.  Create two documents (i.e. two departments)
4.  Add an employee to Document 1.
5.  Select the employee and Edit > Cut.
6.  Click on the Employee table in Document 2.
7.  Click Edit > Paste.  Cut employee appears in Document 2.
8.  Click Edit > Undo.

Although some users might expect that the employee moves from Document  
2 back to Document 1, that does not happen.  Because each document has  
its own managed object context and own undo manager, because Document  
2 is active, the employee disappears from there.  But order to make it  
reappear in Document 1, user also needs to activate Document 1 and  
click Edit > Undo *again*.


One could argue that there is no problem.  Mac Users understand that  
Undo is per-document.  They will instantly realize that they did two  
*do* operations in two different documents (Cut in Document 1, Paste  
in Document 2) to get where they are at, so they expect that two  
*undo* operations, one in each document, will be required to get  
back.  A highly-skilled Core Data developer might even be able to set  
the correct undo actions, "Undo Paste Employee" and "Undo Cut  
Employee", which will help cue in those users with unrealistic  
expectations.


But this answer is not as plausible if the user makes the move using  
drag-drop instead of cut-paste.  (Drag-drop is not implemented in  
DepartmentAndEmployees, but it is common in real apps.)  Clearly, the  
user has now performed only one operation, and might rightfully expect  
it to be undoable with a single Undo.


I suppose that the developer of such an app could replace the undo  
manager in each document, upon creation or loading, with a single,  
common undo manager.  But I fear that this would cause hundreds of  
unintended under-the-hood consequences in Core Data, and am loathe to  
think about it.  Has anyone ever done this?


Another alternative:  In the drag-drop implementation, before doing  
the *delete* operation, temporarily disable undo registration in the  
source document.  Then, explicitly register with the undo manager of  
the destination document an action which would insert an object with  
the old object's attributes into the source document's moc.  An  
equivalent trick would probably work in a non-Core-Data document, but  
I suspect that Core Data's under-hood magic wouldn't be too pleased  
with this.


In either case, there's the little issue of what if the source  
document is closed, then later this Undo action gets invoked.  Setting  
a flag to say that "you've got Document 1's stuff on your undo stack",  
and removing all undo actions when Document 1 is closed would probably  
be a good idea, but this is starting to get messy.


Is there is a better answer?

Sincerely,

Jerry Krinock

___

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: first responder being clobbered

[Dave DeLong]

Nope.  In CocoaTouch, you can explicitly assign a UIResponder to be  
first responder by sending it the -becomeFirstResponder message.   
There is no "makeFirstResponder" method.  IMO, this is one of the  
improvements of CocoaTouch over Cocoa.  The responder system seems to  
be better organized.


Dave

On Oct 26, 2009, at 9:59 PM, Graham Cox wrote:



On 27/10/2009, at 2:55 PM, Michael Link wrote:

Is there a different solution to getting a first responder in a  
table cell and not having it resign on 3.1?


I'm unfamiliar with the iPhone version of Cocoa and whether its  
rules are different, but certainly on the Mac you shouldn't invoke - 
becomeFirstResponder on an object. Instead you must ask its window  
to make it the first responder using -makeFirstResponder. Same?


smime.p7s
Description: S/MIME cryptographic signature
___

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: first responder being clobbered

[Graham Cox]

On 27/10/2009, at 2:55 PM, Michael Link wrote:

Is there a different solution to getting a first responder in a  
table cell and not having it resign on 3.1?



I'm unfamiliar with the iPhone version of Cocoa and whether its rules  
are different, but certainly on the Mac you shouldn't invoke - 
becomeFirstResponder on an object. Instead you must ask its window to  
make it the first responder using -makeFirstResponder. Same?


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

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

first responder being clobbered

[Michael Link]

I have a custom UITableViewController that uses a custom cell that  
displays a text field. I have this method added to the table view  
controller to set the text field as first responder


- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];

	MLPropertyEditingTableViewCell* __cell =  
(MLPropertyEditingTableViewCell*)[self.tableView cellForRowAtIndexPath: 
[NSIndexPath indexPathForRow:0 inSection:0]];


[__cell.textField becomeFirstResponder];
}

This works on iPhone OS 3.0, but not on iPhone OS 3.1. It appears that  
on 3.1 there is an observer that calls reloadData on the table view  
and that forces the first responder to resign.


#0	0x7b9d in -[FRProjectNamePropertyEditorViewController  
textFieldDidEndEditing:] at  
FRProjectNamePropertyEditorViewController.m:131

#1  0x0030b1ea in -[UITextField fieldEditorDidResignFirstResponder:]
#2  0x00319b61 in -[UIFieldEditor resignFirstResponder]
#3  0x0030d341 in -[UITextField resignFirstResponder]
#4  0x002f4384 in -[UITableView reloadData]
#5  0x002f189f in -[UITableView layoutSubviews]
#6  0x036c62b0 in -[CALayer layoutSublayers]
#7  0x036c606f in CALayerLayoutIfNeeded
#8  0x036c58c6 in CA::Context::commit_transaction
#9  0x036c553a in CA::Transaction::commit
#10 0x036cd838 in CA::Transaction::observer_callback
#11 0x01d49252 in __CFRunLoopDoObservers
#12 0x01d4865f in CFRunLoopRunSpecific
#13 0x01d47c48 in CFRunLoopRunInMode
#14 0x0253478d in GSEventRunModal
#15 0x02534852 in GSEventRun
#16 0x002ab003 in UIApplicationMain
#17 0x2980 in main at main.m:14

Is there a different solution to getting a first responder in a table  
cell and not having it resign on 3.1?


--
Michael
___

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: Transitioning to GC-supported

[Dave Keck]

>> 4. Search for every call to -retain, -alloc, -init pairs, and -copy.
>> Verify that the object being retained is strongly referenced, and if not, it 
>> must
>> be CFRetain()ed or -disableCollectorForPointer: must be called for it.
>
> I'm not sure what you mean by this.

For example, I have an object that [self retain]; while it does some
work that takes awhile. I don't hold a reference to this object
anywhere after it's created - it simply notifies its delegate when its
finished. In this case, this object would need to CFRetain itself to
keep itself alive.

>> 6. Search for every use of '&', and use objc_assign_global() and
>> objc_assign_ivar() as necessary.
>
> I don't know what you mean by this.

I'm not sure either. :) This is on my list of things to understand
better, but I mentioned it after reading "Global Object Pointers",
here:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcUsing.html

> In summary, I think what you're saying is formally correct, but you're
> overestimating the amount of trouble. I have converted significant amounts
> of code to be GC-compatible, and only ran into minor problems. The biggest
> thing to watch out for is mixing CF and NS types, and mostly you just need
> to insert an NSMakeCollectable call to take care of those. It's really not
> that bad.

Thanks for the reassurance. I tend to be pretty obsessive over my code
(as I'm sure you can tell) which can be a good and a bad thing.
___

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: keyPathsForValuesAffectingValueFor: not updating immediately

[Jim Correia]

On Mon, Oct 26, 2009 at 10:03 PM, Brad Gibbs  wrote:

> I did read the documentation, which is why I used
> +keyPathsForValuesAffectingFullAddress.  I also tried
> +keyPathsForValuesAffectingValueForFullAddress:
>
> Both methods work, but only after changing the view and then coming back to
> it.

+keyPathsForValuesAffecting is not fundamentally broken - I use
it on my NSManagedObject subclasses as needs dictate.

At this point, I think we need more information to help. At the very
least, let's see your implementation of +
keyPathsForValuesAffectingFullAddress.

- Jim
___

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: NSURLDownload and file quarantine

[Wim Lewis]

On Oct 21, 2009, at 2:34 PM, Wim Lewis wrote:
Is there any useful documentation on what the behavior of  
NSURLDownload is supposed to be w.r.t. file quarantine? I'm having a  
hard time getting consistent behavior out of it.


FYI, if anyone else is having similar problems, it turns out that this  
was just a manifestation of a quarantine API bug I actually knew about  
(discovered in the 10.5 seeds, then forgotten) where if your bundle  
identifier is longer than 27 characters the quarantine APIs fall over  
in various ways. I guess the bug is still there.




___

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: keyPathsForValuesAffectingValueFor: not updating immediately

[Brad Gibbs]

I did read the documentation, which is why I used  
+keyPathsForValuesAffectingFullAddress.  I also tried  
+keyPathsForValuesAffectingValueForFullAddress:


Both methods work, but only after changing the view and then coming  
back to it.


On Oct 26, 2009, at 6:27 PM, I. Savant wrote:


On Oct 26, 2009, at 9:07 PM, Brad Gibbs wrote:

I have a Core Data app with a category on a model object, Address.   
The category has a method to return a fullAddress property, which  
is composed of the streetAddress, city, state and zipCode.


 Did you read the documentation for this method?

"Note: You must not override this method when you add a computed  
property to an existing class using a category, overriding methods  
in categories is unsupported. In that case, implement a matching  
+keyPathsForValuesAffecting to take advantage of this mechanism."


--
I.S.




___

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: Getting a handle on inf

[Andrew Farmer]

On 26 Oct 2009, at 12:11, Ian Piper wrote:

...and I still get a failed build with this message:

Expecting inf; we got inf

Which seems odd.


And internally, this is because the IEEE float machinery guarantees  
that all infinite and NaN values compare as not-equal to each other,  
so that 1/0 != 2/0, 1e100 != 1e100 + 1, and so on. Sadly, this also  
means that some floats will compare as not equal to themselves -- an  
unfortunate, but necessary result.

___

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: keyPathsForValuesAffectingValueFor: not updating immediately

[I. Savant]

On Oct 26, 2009, at 9:07 PM, Brad Gibbs wrote:

I have a Core Data app with a category on a model object, Address.   
The category has a method to return a fullAddress property, which is  
composed of the streetAddress, city, state and zipCode.


  Did you read the documentation for this method?

"Note: You must not override this method when you add a computed  
property to an existing class using a category, overriding methods in  
categories is unsupported. In that case, implement a matching  
+keyPathsForValuesAffecting to take advantage of this mechanism."


--
I.S.


___

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

keyPathsForValuesAffectingValueFor: not updating immediately

[Brad Gibbs]

Hi,

I have a Core Data app with a category on a model object, Address.   
The category has a method to return a fullAddress property, which is  
composed of the streetAddress, city, state and zipCode.


Updating one of the dependent properties only updates the fullAddress  
property after I've switched views.  I've tried saving the context and  
reloading the view programmatically, but neither method works.


All of the text fields for the dependent keys are set in IB to  
continuously update values.


Is there any way to get fullAddress to update to reflect changes  
immediately?



Thanks.

Brad
___

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: Moving from standalone apps to some internet related programming

[PCWiz]

Its much easier to just build a Universal Binary (which will run on  
any architecture) and distribute that. A few megabytes here and there  
will not make a huge difference, as others have said.


On 2009-10-26, at 4:50 PM, Nick Rogers wrote:


Hi,
In my some 2 yrs of cocoa programming with cocoa, I have been able  
to make a main app (which is selling) and a few related small apps.
Now I have to make a small utility that would download the  
appropriate (best) version of main app that would run on the user  
system by polling for the MacOS type and its ability to run 64-bit  
apps.

I have no internet related programming experience till now.
Are there any resources available for a beginner for developing such  
a utility.

How should I proceed?

Also how to know if a particular mac would be able to run a 64-bit  
app? Some earlier Macs like PowerPC G4 could run Leopard but are not  
able to run 64-bit apps.


Wishes,
Nick

___

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/pcwiz.support%40gmail.com

This email sent to pcwiz.supp...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTableView Always Undesirably Selects First Row when It Loses Key Focus

[Grant Erickson]

On 10/23/09 4:31 PM, Grant Erickson wrote:
> I have a device list in my preference pane implemented as a NSTableView under
> 10.5, not unlike the list of network devices in Apple's Network preference
> pane.
> 
> Unlike the Network table, in my case there is no mandate that an item (i.e.
> row) always be selected. However, if there are no rows selected, when I hit
> the tab key to change the key focus from my table to the preferences search
> field, the table automatically, yet undesirably, selects the first row.
> 
> Is this standard, albeit undocumented, NSTableView behavior? If so, what is
> the best way to prevent this from happening? Is one of the should*Select*
> delegate methods most appropriate?

It was suggested off-list to set breakpoints on a few of the table delegate
methods. I get two calls to selectionShouldChangeInTableView, one to
shouldSelectRow and one to tableViewSelectionDidChange.

The curiosity seems to be why NSTableView keyDown, when receiving  and
losing key focus, insists on "selecting the next focused cell" when there is
no currently focused cell and the overall table is, in fact, losing focus.

> #0-[MyPreferencePane selectionShouldChangeInTableView:]
> #1-[NSTableView _userCanChangeSelection]
> #2-[NSTableView _selectNextFocusedCellGoingForward:andEdit:]
> #3-[NSTableView keyDown:]
> #4-[NSWindow sendEvent:]
> #5-[NSApplication sendEvent:]
> #6??
> #7-[NSApplication run]
> #8NSApplicationMain
> #9??
>  
> #0-[MyPreferencePane selectionShouldChangeInTableView:]
> #1-[NSTableView _userCanChangeSelection]
> #2-[NSTableView
> _userSelectableRowIndexesForProposedSelection:userCanAlreadyChangeSelection:]
> #3-[NSTableView _userSelectableRowIndexesForProposedSelection:]
> #4-[NSTableView _userCanSelectRow:withNewSelectedIndexes:]
> #5-[NSTableView
> _findFirstUserSelectableRowStartingFrom:to:selectedRowsOkay:byExtendingSelecti
> on:]
> #6-[NSTableView _selectNextFocusedCellGoingForward:andEdit:]
> #7-[NSTableView keyDown:]
> #8-[NSWindow sendEvent:]
> #9-[NSApplication sendEvent:]
> #10   ??
> #11   -[NSApplication run]
> #12   NSApplicationMain
> #13   ??
> 
> #0-[MyPreferencePane tableView:shouldSelectRow:]
> #1-[NSTableView _sendDelegateCanSelectRow:]
> #2-[NSTableView _oldUserCanSelectRow:]
> #3-[NSTableView
> _userSelectableRowIndexesForProposedSelection:userCanAlreadyChangeSelection:]
> #4-[NSTableView _userSelectableRowIndexesForProposedSelection:]
> #5-[NSTableView _userCanSelectRow:withNewSelectedIndexes:]
> #6-[NSTableView
> _findFirstUserSelectableRowStartingFrom:to:selectedRowsOkay:byExtendingSelecti
> on:]
> #7-[NSTableView _selectNextFocusedCellGoingForward:andEdit:]
> #8-[NSTableView keyDown:]
> #9-[NSWindow sendEvent:]
> #10   -[NSApplication sendEvent:]
> #11   ??
> #12   -[NSApplication run]
> #13   NSApplicationMain
> #14   ??
> 
> #0-[MyPreferencePane tableViewSelectionDidChange:]
> #1_nsnote_callback
> #2__CFXNotificationPost
> #3_CFXNotificationPostNotification
> #4-[NSNotificationCenter postNotificationName:object:userInfo:]
> #5-[NSNotificationCenter postNotificationName:object:]
> #6-[NSTableView _enableSelectionPostingAndPost]
> #7-[NSTableView selectRowIndexes:byExtendingSelection:]
> #8-[NSTableView _selectNextFocusedCellGoingForward:andEdit:]
> #9-[NSTableView keyDown:]
> #10   -[NSWindow sendEvent:]
> #11   -[NSApplication sendEvent:]
> #12   ??
> #13   -[NSApplication run]
> #14   NSApplicationMain
> #15   ??
> 
FWIW, the NSOutlineView in the Desktop and Screen Saver preference pane
exhibits this same behavior.

Command-click whatever current saver you have selected to deselect it and
then hit  to get to the preference search box. The outline view will
auto-select whatever saver shows up in the first expanded grouping.

-Grant

___

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: Moving from standalone apps to some internet related programming

[Jon Nall]

On Oct 26, 2009, at 3:50 PM, Nick Rogers wrote:


Hi,
In my some 2 yrs of cocoa programming with cocoa, I have been able  
to make a main app (which is selling) and a few related small apps.
Now I have to make a small utility that would download the  
appropriate (best) version of main app that would run on the user  
system by polling for the MacOS type and its ability to run 64-bit  
apps.

I have no internet related programming experience till now.
Are there any resources available for a beginner for developing such  
a utility.

How should I proceed?



Have you looked at Sparkle? http://sparkle.andymatuschak.org

___

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: Moving from standalone apps to some internet related programming

[Nick Zitzmann]

On Oct 26, 2009, at 4:50 PM, Nick Rogers wrote:

Now I have to make a small utility that would download the  
appropriate (best) version of main app that would run on the user  
system by polling for the MacOS type and its ability to run 64-bit  
apps.

I have no internet related programming experience till now.
Are there any resources available for a beginner for developing such  
a utility.

How should I proceed?


The 1990s are over, almost nobody cares about executable smallness  
anymore, and the few that do care will use some program to strip out  
the architectures they're not using. So I wouldn't worry about this  
unless you get customer complaints about the application size.


Also how to know if a particular mac would be able to run a 64-bit  
app? Some earlier Macs like PowerPC G4 could run Leopard but are not  
able to run 64-bit apps.


Use sysctlbyname() with the key "hw.cpu64bit_capable". If the key  
value is set to 1, then it's able; if it's undefined or set to 0, then  
it isn't.


Nick Zitzmann


___

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: Moving from standalone apps to some internet related programming

[Nick Rogers]

hi,
the package is 6 MB for the demo & 11 MB for the full version, so  
packaging all is not desired.


thanks,
Nick

On 27-Oct-2009, at 4:32 AM, Philip Ershler wrote:



On Oct 26, 2009, at 4:50 PM, Nick Rogers wrote:


Hi,
In my some 2 yrs of cocoa programming with cocoa, I have been able  
to make a main app (which is selling) and a few related small apps.
Now I have to make a small utility that would download the  
appropriate (best) version of main app that would run on the user  
system by polling for the MacOS type and its ability to run 64-bit  
apps.

I have no internet related programming experience till now.
Are there any resources available for a beginner for developing  
such a utility.

How should I proceed?

Also how to know if a particular mac would be able to run a 64-bit  
app? Some earlier Macs like PowerPC G4 could run Leopard but are  
not able to run 64-bit apps.


Wishes,
Nick




Depending on the size of your app, might it be easier to package up  
various versions and let the Installer take care if it?


Phil


___

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/roger_s1%40mac.com

This email sent to roger...@mac.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Getting a handle on inf

[Ian Piper]

On 26 Oct 2009, at 19:46, Ken Thomases wrote:

You want STAssertEqualObjects, here.  You want to compare for equal  
value, not identity, which is what STAssertEquals does.


Greg, Ken,

Thanks, that is what I was looking for. Great help, thank you.


Ian.
--
___

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: Moving from standalone apps to some internet related programming

[Philip Ershler]

On Oct 26, 2009, at 4:50 PM, Nick Rogers wrote:


Hi,
In my some 2 yrs of cocoa programming with cocoa, I have been able  
to make a main app (which is selling) and a few related small apps.
Now I have to make a small utility that would download the  
appropriate (best) version of main app that would run on the user  
system by polling for the MacOS type and its ability to run 64-bit  
apps.

I have no internet related programming experience till now.
Are there any resources available for a beginner for developing such  
a utility.

How should I proceed?

Also how to know if a particular mac would be able to run a 64-bit  
app? Some earlier Macs like PowerPC G4 could run Leopard but are not  
able to run 64-bit apps.


Wishes,
Nick




Depending on the size of your app, might it be easier to package up  
various versions and let the Installer take care if it?


Phil


___

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

Moving from standalone apps to some internet related programming

[Nick Rogers]

Hi,
In my some 2 yrs of cocoa programming with cocoa, I have been able to  
make a main app (which is selling) and a few related small apps.
Now I have to make a small utility that would download the appropriate  
(best) version of main app that would run on the user system by  
polling for the MacOS type and its ability to run 64-bit apps.

I have no internet related programming experience till now.
Are there any resources available for a beginner for developing such a  
utility.

How should I proceed?

Also how to know if a particular mac would be able to run a 64-bit  
app? Some earlier Macs like PowerPC G4 could run Leopard but are not  
able to run 64-bit apps.


Wishes,
Nick

___

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: Transitioning to GC-supported

[John Engelhart]

What follows is my $0.02, and is worth every penny you paid for it.  :)

On Mon, Oct 26, 2009 at 9:45 AM, Dave Keck  wrote:

> I'm planning on systematically going through each of my source files and
> updating them to be GC-supported. I've been compiling a list of things to
> do
> and to look out for. So far, this is what I've got:
>
> 1. Apply workaround for interior pointers by '[containingObject self];' at
> the end of the method, to keep the containing object alive. It would be
> great if I had a list of every accessor method that returned an interior
> pointer - I figure I'll just make a fancy regex to search through the
> framework headers for anything returning a void *, char *, etc., but of
> course this won't catch everything. I fear the bugs caused by using
> interior
> pointers will be subtle and intermittent which is why I'd like to exert the
> effort to patch every instance in one fell swoop, ideally without having to
> re-read every line that I've written for this (somewhat large) project.
>

My advice?  Don't bother.  While I have definitely had problems with the
above, it is almost always when I'm stress testing things.  Often, though
not always, this problem is a "race condition" bug at its heart, so if
you're not pushing things hard, you're not likely to ever see it manifest.
 Second, having done exercises like this, you're almost certainly going to
do it wrong.  You are trying to out-think the compiler, and it has a way of
making you very humble.  Furthermore, this problem is almost exclusively due
to the use of the optimizer- simply turning off optimization causes 99% of
the reasons why you need to do this to go away.

And if you're really stuck on using the optimizer and making all these
changes, I still wouldn't do it unless you're willing to audit the assembly
code that comes out of the compiler.  You'd be surprised at how often the
compiler will do something different than what you expected.


> 6. Search for every use of '&', and use objc_assign_global() and
> objc_assign_ivar() as necessary.
>

Hopefully you wont end up having to deal with these kinds of cases.  When
you do, it's not always clear which objc_assign_*() function you need to
use.  When you need to use objc_assign_global() is obvious in only the most
trivial case: when you're directly accessing / referencing a global
variable.  Many times it can be ambiguous.  Another caveat is weak pointers,
which have a whole different set of functions and one of those has to be
used to even read the __weak variable.


> 7. Search for all opaque pointer types (void *, uintptr_t) and scold them.
>

The problem isn't opaque pointer types. The C language has a number of
rules, all very meticulously and well thought out, for dealing with this
very issue.  The problem is, at least IMHO, not enough through was given to
how GC __strong and __weak interact with those rules, the consequences of
those interactions, and how to deal with the problems of those interactions
cause.  For example, assigning a NSString *stringPointer to a void
*voidPointer = stringPointer; should probably be at least a warning, if not
an error.  Since the compiler accepts it without complaint or warning it's
often hard to tell that you've created a potential problem.  :(  This has
been a big source of hard to find GC bugs for me- where a GC qualifier was
"dropped" during handling at some point.


> 8. Test and maintain sanity.
>
> This is my first trip to GC-land, so it's sure to be a learning experience.
> Any tips or pitfalls to look out for would be greatly appreciated!
>

One problem I've had with GC is that when things do go wrong, things go
really wrong.  I've found that tracking down a GC caused bug to be many,
many orders of magnitude more difficult than its manual memory management
counterpart.  This is mostly due to the nature of GC- if you "got something
wrong", say missed an objc_assign() somewhere, it's often not a problem.
 The timing often has to be just right- even though you missed the call,
something else may make a objc_assign call that happens to cover your
mistake just a few thousand instructions later.  Or, more frequently, the
lifetime of an object is so short that it doesn't matter anyway- it's really
only a problem when the collector is actively collecting.  All in all, it's
just a big bag of hurt.
___

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

Snow Leopard Address Book rejecting dragged vCards

[Doug Knowles]

Hi,

My company's application has the ability to drag contact information for one
or more contacts from our application in multiple formats, including vCard.
Under Leopard, this enabled us to support dragging contacts from our
application into the Address Book.

This has stopped working in Snow Leopard; as near as I can tell, the Address
Book is refusing to validate the drop (as opposed to failing to convert the
data), because our application is not being asked to provide the promised
data.

We "advertise" the following types for the drag: NSVCardPboardType,
NSStringPboardType, and an internal representation we use for
intra-application drags. (I wrote a quick and dirty drag recipient to verify
that these types are indeed available in a drag from our application.)

I found a note that Snow Leopard deprecates NSVCardPboardType, and
recommends using kUTTypeVCard. I've added this as an available format to no
effect.

Has anyone seen similar problems, or have any ideas?

Thanks in advance.

Doug Knowles
___

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: Professional Error Handling

[Kyle Sluder]

On Mon, Oct 26, 2009 at 12:57 PM, Dick Bridges
 wrote:
> IIUC, 
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Exceptions/Exceptions.html
>  is available to everyone and is not under NDA. It's the "Introduction to 
> Exception Programming Topics for Cocoa". As noted on this page, the first 
> article is titled "Exceptions and the Cocoa Frameworks" and "...describes 
> NSException objects and their general use with the Cocoa frameworks." The 
> page also contains a reference to the related CoreRecipes sample code. The 
> document applies to both iPhone OS and Mac OS X. (FWIW, I am believe that 
> exception handling is also used *->within<-* some or all of the core 
> frameworks.)

In fact, some frameworks are implemented in C++, and use exceptions in
a way more idiomatic in that language.

> When discussing the relative merits of exceptions and error codes, the 
> distinction between "expected" and "unexpected" errors (i.e., exceptions) 
> must be maintained. Apple's "Error Handling Programming Guide for Cocoa" does 
> an excellent job of describing "...the recommended way to communicate 
> *->expected<-* errors in Cocoa applications" (emphasis added).


Correct, which is why you don't want to use exceptions for things like
"File not Found", but rather for programmer mistakes like "Tried to
set string value of integer attribute."

> The original question from Squ Aire contained a reference to the option of 
> returning nil. It may well be that I misunderstood, but I interpreted that as 
> exception handling and not the communication of normal, expected errors.

It appears you have misunderstood.  The NSError paradigm involves
returning a sentinel value (most frequently NO and nil) and filling in
the outError parameter.  No exception is thrown in this case.

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

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

RE: Professional Error Handling

[Dick Bridges]

> -Original Message-
> From: Alastair Houghton [mailto:alast...@alastairs-place.net]
> Sent: Monday, October 26, 2009 4:02 AM
> To: Dick Bridges
> Cc: Squ Aire; cocoa-dev@lists.apple.com
> Subject: Re: Professional Error Handling
>
> On 25 Oct 2009, at 22:44, Dick Bridges wrote:
>
> > FWIW, there are some people (myself included) that consider "error
> > numbers" to be something of an anti-pattern when exception handling
> > is available.
>
> There are also some people (myself included) that consider that you
> are wrong.
>
> This has been discussed before on this very mailing list, so probably
> no need to start the debate again---just search the archives if you're
> interested.
>
> Kind regards,
>
> Alastair.

IIUC, 
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Exceptions/Exceptions.html
 is available to everyone and is not under NDA. It's the "Introduction to 
Exception Programming Topics for Cocoa". As noted on this page, the first 
article is titled "Exceptions and the Cocoa Frameworks" and "...describes 
NSException objects and their general use with the Cocoa frameworks." The page 
also contains a reference to the related CoreRecipes sample code. The document 
applies to both iPhone OS and Mac OS X. (FWIW, I am believe that exception 
handling is also used *->within<-* some or all of the core frameworks.)

When discussing the relative merits of exceptions and error codes, the 
distinction between "expected" and "unexpected" errors (i.e., exceptions) must 
be maintained. Apple's "Error Handling Programming Guide for Cocoa" does an 
excellent job of describing "...the recommended way to communicate 
*->expected<-* errors in Cocoa applications" (emphasis added).

The original question from Squ Aire contained a reference to the option of 
returning nil. It may well be that I misunderstood, but I interpreted that as 
exception handling and not the communication of normal, expected errors.

BTW, I did not neglect to research the archives. I did, however, fail to find 
related references to the above cited Apple developer documents. Might be some 
sloppy searching on my part. I'll go back and look again.

Regards,
Dick
___

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: Getting a handle on inf

[Ken Thomases]

On Oct 26, 2009, at 2:11 PM, Ian Piper wrote:


On 26 Oct 2009, at 18:45, Greg Parker wrote:


On Oct 26, 2009, at 11:26 AM, Ian Piper wrote:
So I am guessing that when I get a float displayed as "inf" this  
is not the string it seems to be. Also, it looks like the string  
value of whatever is coming back is not something that I can use.  
Can anyone suggest how I might handle a test case like this?


As Kyle noted, -stringValue returns an NSString, not a char*. You'd  
need to compare to @"inf" and print with %...@.


Kyle, Greg,

Thanks for that. I tried it out:

- (void)testVeryLargeNumberShouldReturnInf {
testConverter = Converter.new;
	[testConverter setValue:[NSNumber numberWithFloat: 
1000.0] forKey:@"originalTemp"];
	NSNumber *newTemperatureInF = [NSNumber numberWithFloat:(float) 
[testConverter convertCToF]];
	STAssertEquals(@"inf", [newTemperatureInF stringValue], @"Expecting  
inf; we got %@", [newTemperatureInF stringValue]);


You want STAssertEqualObjects, here.  You want to compare for equal  
value, not identity, which is what STAssertEquals does.



[testConverter release];
}

...and I still get a failed build with this message:

Expecting inf; we got inf

Which seems odd. When I look at the transcript for the test result  
it looks like this:


TCTests.m:58: error: -[TCTests testVeryLargeNumberShouldReturnInf] :  
'<28810c00 0100>' should be equal to '':  
Expecting inf; we got inf


So I am still not comparing apples with apples...


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

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

Re: Getting a handle on inf

[Nick Zitzmann]

On Oct 26, 2009, at 1:11 PM, Ian Piper wrote:

	[testConverter setValue:[NSNumber numberWithFloat: 
1000.0] forKey:@"originalTemp"];


I don't know if it makes a difference, but I'm curious as to why  
you're not using the INFINITY #define that's in math.h... isinf() is  
in the same header.


Nick Zitzmann


___

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: Getting a handle on inf

[Greg Parker]

On Oct 26, 2009, at 12:11 PM, Ian Piper wrote:


On 26 Oct 2009, at 18:45, Greg Parker wrote:


On Oct 26, 2009, at 11:26 AM, Ian Piper wrote:
So I am guessing that when I get a float displayed as "inf" this  
is not the string it seems to be. Also, it looks like the string  
value of whatever is coming back is not something that I can use.  
Can anyone suggest how I might handle a test case like this?


As Kyle noted, -stringValue returns an NSString, not a char*. You'd  
need to compare to @"inf" and print with %...@.


Kyle, Greg,

Thanks for that. I tried it out:

- (void)testVeryLargeNumberShouldReturnInf {
testConverter = Converter.new;
	[testConverter setValue:[NSNumber numberWithFloat: 
1000.0] forKey:@"originalTemp"];
	NSNumber *newTemperatureInF = [NSNumber numberWithFloat:(float) 
[testConverter convertCToF]];
	STAssertEquals(@"inf", [newTemperatureInF stringValue], @"Expecting  
inf; we got %@", [newTemperatureInF stringValue]);

[testConverter release];
}

...and I still get a failed build with this message:

Expecting inf; we got inf

Which seems odd. When I look at the transcript for the test result  
it looks like this:


TCTests.m:58: error: -[TCTests testVeryLargeNumberShouldReturnInf] :  
'<28810c00 0100>' should be equal to '':  
Expecting inf; we got inf


So I am still not comparing apples with apples...


STAssertEquals() uses the moral equivalent of `==` to compare the  
values. Your test should use STAssertEqualObjects(), which compares  
the values with -isEqual:.



A better way to check for floating-point +infinity and -infinity is  
to use the isinf() macro.


  if (isinf([number floatValue])) {
  NSLog(@"number is +inf or -inf");
  }


That macro isn't part of OCUnit is it? I don't see it in the  
Documentation.


It's part of the standard C library. For OCUnit you'd use something  
like `STAssertTrue(isinf([number floatValue]), ...)`.



--
Greg Parker gpar...@apple.com Runtime Wrangler


___

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: Getting a handle on inf

[Ian Piper]

On 26 Oct 2009, at 18:45, Greg Parker wrote:


On Oct 26, 2009, at 11:26 AM, Ian Piper wrote:
So I am guessing that when I get a float displayed as "inf" this is  
not the string it seems to be. Also, it looks like the string value  
of whatever is coming back is not something that I can use. Can  
anyone suggest how I might handle a test case like this?


As Kyle noted, -stringValue returns an NSString, not a char*. You'd  
need to compare to @"inf" and print with %...@.


Kyle, Greg,

Thanks for that. I tried it out:

- (void)testVeryLargeNumberShouldReturnInf {
testConverter = Converter.new;
	[testConverter setValue:[NSNumber numberWithFloat: 
1000.0] forKey:@"originalTemp"];
	NSNumber *newTemperatureInF = [NSNumber numberWithFloat:(float) 
[testConverter convertCToF]];
	STAssertEquals(@"inf", [newTemperatureInF stringValue], @"Expecting  
inf; we got %@", [newTemperatureInF stringValue]);

[testConverter release];
}

...and I still get a failed build with this message:

Expecting inf; we got inf

Which seems odd. When I look at the transcript for the test result it  
looks like this:


TCTests.m:58: error: -[TCTests testVeryLargeNumberShouldReturnInf] :  
'<28810c00 0100>' should be equal to '':  
Expecting inf; we got inf


So I am still not comparing apples with apples...


A better way to check for floating-point +infinity and -infinity is  
to use the isinf() macro.


   if (isinf([number floatValue])) {
   NSLog(@"number is +inf or -inf");
   }


That macro isn't part of OCUnit is it? I don't see it in the  
Documentation.



Ian.
--
___

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: Preparing for MOM versioning in version 1

[mmalc Crawford]

On Oct 26, 2009, at 9:00 am, Fritz Anderson wrote:

> I'm about to unleash a Core Data-based application, and I'm sure the schema 
> will change in later versions. The Core Data Model Versioning and Data 
> Migration Programming Guide seems to say that migrating a store from one 
> version to another, at least in simple cases, is magical: The application 
> embeds the historical MOMs, with one of them marked "current," and when a 
> store built to an earlier model is opened, it is (in SIMPLE cases) migrated 
> to the current model.
> Is this the case?
> 

It's not clear what the question is.  The implication appears to be that the 
documentation is simply presenting a fiction of functionality that's not 
actually present.


It's not magical.

Per the Guide 
():

"To request automatic lightweight migration, you set appropriate flags in the 
options dictionary you pass 
inaddPersistentStoreWithType:configuration:URL:options:error:. You need to set 
values corresponding to both the NSMigratePersistentStoresAutomaticallyOption 
and the NSInferMappingModelAutomaticallyOption keys to YES..."


The (iPhone) PhotoLocations example 
() 
illustrates the feature.

mmalc


___

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: Custom NSScroller

[Bryan Matteson]

On Oct 26, 2009, at 1:37 PM, Bryan Matteson wrote:

Calling the setCornerView: method with nil accomplished what I was  
looking for.


Correction, that does not work, either. Setting a custom corner view  
does solve the problem however. 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Getting a handle on inf

[Greg Parker]

On Oct 26, 2009, at 11:26 AM, Ian Piper wrote:
So I am guessing that when I get a float displayed as "inf" this is  
not the string it seems to be. Also, it looks like the string value  
of whatever is coming back is not something that I can use. Can  
anyone suggest how I might handle a test case like this?


As Kyle noted, -stringValue returns an NSString, not a char*. You'd  
need to compare to @"inf" and print with %...@.


A better way to check for floating-point +infinity and -infinity is to  
use the isinf() macro.


if (isinf([number floatValue])) {
NSLog(@"number is +inf or -inf");
}


--
Greg Parker gpar...@apple.com Runtime Wrangler


___

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: Custom NSScroller

[Bryan Matteson]

That's the corner view.  NSOutlineView asks its document view for a
corner view by checking to see if it responds to the -cornerView
method.


Thank you, Kyle. Calling the setCornerView: method with nil  
accomplished what I was looking for.

___

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: Getting a handle on inf

[Kyle Sluder]

On Mon, Oct 26, 2009 at 11:26 AM, Ian Piper  wrote:
> STAssertEquals("inf", [newTemperatureInC stringValue], @"Expecting inf; we
> got %s", [newTemperatureInC stringValue]);

-stringValue returns an NSString, you used a %s specifier rather than %...@.

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

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

Re: Custom NSScroller

[Kyle Sluder]

On Mon, Oct 26, 2009 at 11:24 AM, Bryan Matteson  wrote:
> Any nudge in the right direction would be appreciated.

That's the corner view.  NSOutlineView asks its document view for a
corner view by checking to see if it responds to the -cornerView
method.

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

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

Getting a handle on inf

[Ian Piper]

Hi all,

Following up on my query about unit tests yesterday... I am writing  
another test checking boundary conditions for a calculation. In the  
normal running program I am feeding a very large number  
(1000) into one text field and the  
result displayed in the other text field is "inf". I want to write a  
test to explore this, so I did this:


- (void)testVeryLargeNumberShouldReturnInf {
testConverter = Converter.new;

	[testConverter setValue:[NSNumber numberWithFloat: 
1000.0] forKey:@"originalTemp"];


	NSNumber *newTemperatureInC = [NSNumber numberWithFloat:(float) 
[testConverter convertFToC]];


	STAssertEquals("inf", [newTemperatureInC floatValue], @"Expecting  
inf; we got %f", [newTemperatureInC floatValue]);

[testTempConverter release];

}

When I run this test I see this message: Expecting inf; we got inf

I tried this:

STAssertEquals("inf", [newTemperatureInC stringValue], @"Expecting  
inf; we got %s", [newTemperatureInC stringValue]);


and saw this message: Expecting inf; we got ¿√Ωpˇ

So I am guessing that when I get a float displayed as "inf" this is  
not the string it seems to be. Also, it looks like the string value of  
whatever is coming back is not something that I can use. Can anyone  
suggest how I might handle a test case like this?


Thanks,


Ian.
--___

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

Custom NSScroller

[Bryan Matteson]

Well, after much work I've finally gotten some scrollbars to look how  
I want. There's one thing I can't seem to figure out how to get rid  
of, as I have pointed out in the screenshot you can find at the link  
below. I want the top of the vertical scroller to sit flush against  
the top of the view, just like iTunes and many other programs do, but  
I'm not sure what I'm doing wrong.

Any nudge in the right direction would be appreciated.

http://img260.imageshack.us/img260/9206/scrollbar.png
___

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: Transitioning to GC-supported

[Greg Parker]

On Oct 26, 2009, at 6:45 AM, Dave Keck wrote:

3. Wrap all CF*Create(), CG*Create(), CF*Copy(), CG*Copy(), etc. with
CFMakeCollectable(), and replace corresponding CFRelease()s with a  
custom
macro - CFReleaseIfRC(). (This way, if I ever choose to go GC-only,  
I can

simply remove all calls to CFReleaseIfRC().)


This is more complicated.

If you use temporary CF objects, then CFCreate+CFRelease still works  
just fine (assuming you trust your own l33t memory management skillz).


If you store CF objects in instance variables, this is one way to  
handle it. Then you don't need CFReleaseIfRC().

ivar = NSMakeCollectable(CFCreate());
-dealloc: CFRelease(ivar)
-finalize: /* nothing */


4. Search for every call to -retain, -alloc, -init pairs, and -copy.  
Verify
that the object being retained is strongly referenced, and if not,  
it must

be CFRetain()ed or -disableCollectorForPointer: must be called for it.


Some of these references may be candidates for zeroing weak variables  
instead.



5. Search for every call to -release and -autorelease. If the object  
being

released is a CFType, then it must be CFReleaseIfRC() instead.


Beware of toll-free typecasts. CFRelease() must balance CFRetain(),  
even if the type is actually `id`. Vice versa for -retain/-release of  
CF types.




6. Search for every use of '&', and use objc_assign_global() and
objc_assign_ivar() as necessary.


You shouldn't need to do this. I don't remember when there last was a  
known bug here, but Snow Leopard and the most recent gcc-4.2 ought to  
be good. For a 64-bit screen saver you don't care about anything  
earlier.



Some more suggestions:

* Beware of malloc allocations that store object pointers. They need  
to be changed.
* CF containers with NULL callbacks that store object pointers are  
almost always GC-unsafe. NSHashTable, NSMapTable, and NSPointerArray  
can be configured as safe replacements.
* Use the leaks tools to catch malloc and CFRetain problems, and use  
the Object Allocation instrument to look for GC leaks. A "GC leak" is  
an object that you want to be dead but isn't, because something else  
still has a pointer to it. Common examples are a pointer from a long- 
lived controller to some other short-lived object that needs to be  
explicitly set to nil, or a long-lived container to which objects are  
added but never removed.



--
Greg Parker gpar...@apple.com Runtime Wrangler


___

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: Make a solid line look like 3D

[I. Savant]

On Oct 26, 2009, at 1:10 PM, Jean-Daniel Dupas wrote:

What do you expect as rectangle ?  drawRect: parameter is the  
smaller rectangle that contains all rect marked as dirty.
If you want to exact list of dirty rects, you can query it using the  
-getRectsBeingDrawn:count: methods.


  This is more specific and more correct than what I said (see my "in  
the general sense" comment, though). :-)


  In practice, however, for an on-screen view, the dirty rects are  
usually the areas that are or have just become visible.


--
I.S.




___

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: Make a solid line look like 3D

[Matthias Arndt]

Am 26.10.2009 um 17:44 schrieb Matthias Arndt:

or some reasons I still don't understand (Argh!) the drawRect:  
method of my view didn't pass the right rectangle to the object  
actually responsible for the drawing.


I mis-phrased that! There is no *technical* thing I don't understand  
with the rect parameter! I just don't understand, why I didn't passed  
it down to the drawing code. Completely my fault and it was fixed in a  
few minutes. Now everything works as expected!


@Jean-Daniel: While scrolling a zoomed area only the visible part is  
marked as dirty and passed in rect, that's why I mentioned "visible"  
in the context of dirty rects.


Thanks again, guys!

Matthias
___

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: Make a solid line look like 3D

[Jean-Daniel Dupas]

Le 26 oct. 2009 à 17:44, Matthias Arndt a écrit :


Hi guys,

first let me thank you for all information and suggestions you  
provided!


Am 26.10.2009 um 00:48 schrieb I. Savant:

That was entirely my fault, sorry. I have no idea where I got the  
idea it was for a screen saver. I did not follow the link. In my  
defense, a better description of the application's requirements  
would've helped in determining a course.


You're right and the first draft of my mail included much more  
details about the application, especially about the drawing sequence  
leading to this high number of NSBezierPath operations. Afterwards I  
though, why to bother you with embroideries, stitches etc., and I  
deleted the stuff and include the screenshot link instead ... No  
need to be sorry, but I am:


Hit me with a stick (and hit me hard)!

For some reasons I still don't understand (Argh!) the drawRect:  
method of my view didn't pass the right rectangle to the object  
actually responsible for the drawing.


What do you expect as rectangle ?  drawRect: parameter is the smaller  
rectangle that contains all rect marked as dirty.
If you want to exact list of dirty rects, you can query it using the - 
getRectsBeingDrawn:count: methods.


But it has nothing to do with the visible rect.

I just fixed the code to aim for the best performance improvement:  
Don't draw at all (at least not hidden objects). I'm satisfied with  
the result as the poor performance was while zooming and scrolling  
zoomed areas, exactly the situations, which benefit most from  
drawing only in the visible part.


I do apologize wasting your time ... well, not completely, because I  
learned a thing or two about image caching, performance measurement,  
Cocoa drawing performance and I promise I will sometime get my hands  
on OpenGL ... maybe for a screen saver!


Thanks again, I adore this list, Matthias


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

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

Re: Make a solid line look like 3D

[I. Savant]

On Oct 26, 2009, at 12:44 PM, Matthias Arndt wrote:

For some reasons I still don't understand (Argh!) the drawRect:  
method of my view didn't pass the right rectangle to the object  
actually responsible for the drawing. I just fixed the code to aim  
for the best performance improvement: Don't draw at all (at least  
not hidden objects). I'm satisfied with the result as the poor  
performance was while zooming and scrolling zoomed areas, exactly  
the situations, which benefit most from drawing only in the visible  
part.


  Well, this is an important issue. :-)

  While you don't have to include all your drawing code, I would  
encourage you to post at least the basics.


  Speaking in the general sense and assuming your "stitch view" is  
all one view (not a combination of subviews), your view should  
definitely be getting only the visible rect passed into -drawRect:  
when displaying it on screen in this way unless something's  
specifically asking for the entire view (as in saving as an image or  
printing).


  If you're having problems that are causing the entire view to be  
redrawn while zoomed into a small portion and scrolling around,  
something is wrong and should be addressed.


  Also, some people seem to want to call -drawRect: directly, or call  
-display when they really should be calling -setNeedsDisplay:. Another  
thing to consider is your NSScrollView settings in Interface  
Builder ... is Copy On Scroll enabled or disabled?


  The best way to get help from the list on this issue is to post  
(the relevant parts of) your code.


--
I.S.




___

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: IKImageBrowserView Dragging outside

[Tobias Jordan]

Hey Jonathan & Thomas,

it's finally working and even more easier than I've thought: So I made  
a subclass of my IKImageBrowserView and added a new delegate method,  
the one's missing:


//  
---

// -browserView:droppedIndexes:atDestination:
//  
---
- (void)browserView:(ESPImageBrowserView *)bv droppedIndexes: 
(NSIndexSet *)indexSet atDestination:(NSURL *)dropDestination

{
if (self.delegate)
{
		if ([self.delegate  
respondsToSelector 
:@selector(browserView:droppedIndexes:atDestination:)])

{
			[self.delegate browserView:bv droppedIndexes:indexSet  
atDestination:dropDestination];

}
}
}

it's called from:

//  
---

// -namesOfPromisedFilesDroppedAtDestination:
//  
---
- (NSArray *)namesOfPromisedFilesDroppedAtDestination:(NSURL  
*)dropDestination

{
	[self browserView:self droppedIndexes:[self selectionIndexes]  
atDestination:dropDestination];

return nil;
}

No need to implement :mouseDown- or -mouseDragged: :-)

Thank you for your help!

Best regards,
Tobias Jordan.

On Oct 25, 2009, at 12:41 PM, jonat...@mugginsoft.com wrote:


That might prove to be the case.
Others think the same: 
http://www.cocoabuilder.com/archive/message/cocoa/2009/7/29/241852

An approach might be to use an NSTableView instance as a drag source  
proxy.
When your IKImageBrowserView instance gets a drag request pass it on  
to the tableview which can deliver on the promise.

You would have to keep the datasources synchronised of course.
Either that or populate the tableview with just the items to be  
dragged when the IKImageBrowserView

drag begins.

Just an idea. Might be tricky to pull off in practice.

Regards

Jonathan Mitchell

Developer
http://www.mugginsoft.com




On Oct 25, 2009, at 3:41 PM, Thomas Goossens wrote:


Ok, I didn't catch you need to create special folder structures.
So you can only do that with promised files and since there is no  
equivalent to "tableView:namesOfPromisedFilesDroppedAtDestination"  
in the IKImageBrowseView, you will have to do everything at the  
NSView level using  
"dragPromisedFilesOfTypes:fromRect:source:slideBack:event:" and  
"namesOfPromisedFilesDroppedAtDestination:".
But that means you will have to detect when the drag should start  
(with mouseDown/mouseDragged + IK's indexOfItemAtPoint) and setup  
your drag image yourself.


-- Thomas


___

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: Make a solid line look like 3D

[Matthias Arndt]

Hi guys,

first let me thank you for all information and suggestions you provided!

Am 26.10.2009 um 00:48 schrieb I. Savant:

 That was entirely my fault, sorry. I have no idea where I got the  
idea it was for a screen saver. I did not follow the link. In my  
defense, a better description of the application's requirements  
would've helped in determining a course.


You're right and the first draft of my mail included much more details  
about the application, especially about the drawing sequence leading  
to this high number of NSBezierPath operations. Afterwards I though,  
why to bother you with embroideries, stitches etc., and I deleted the  
stuff and include the screenshot link instead ... No need to be sorry,  
but I am:


Hit me with a stick (and hit me hard)!

For some reasons I still don't understand (Argh!) the drawRect: method  
of my view didn't pass the right rectangle to the object actually  
responsible for the drawing. I just fixed the code to aim for the best  
performance improvement: Don't draw at all (at least not hidden  
objects). I'm satisfied with the result as the poor performance was  
while zooming and scrolling zoomed areas, exactly the situations,  
which benefit most from drawing only in the visible part.


I do apologize wasting your time ... well, not completely, because I  
learned a thing or two about image caching, performance measurement,  
Cocoa drawing performance and I promise I will sometime get my hands  
on OpenGL ... maybe for a screen saver!


Thanks again, I adore this list, Matthias
___

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: Preparing for MOM versioning in version 1

[Volker in Lists]

Hi Fritz,

I have it running that way in one of my applications. The user base is  
small (< 50 users), so I might not have yet had the chance to discover  
magic not happening. I also invested a lot of time in the model  
process, to avoid too many changes.


My changes, that worked well, included addition of new properties/ 
fields. No changes to relationships so far. These will be harder I  
guess.


I also have a manual upgrade process for older version files - still  
dating back to 10.4. The manual migration isn't too hard if you can't  
rely on the automagic process.


Hth,

Volker

Am 26.10.2009 um 17:00 schrieb Fritz Anderson:

I'm about to unleash a Core Data-based application, and I'm sure the  
schema will change in later versions. The Core Data Model Versioning  
and Data Migration Programming Guide seems to say that migrating a  
store from one version to another, at least in simple cases, is  
magical: The application embeds the historical MOMs, with one of  
them marked "current," and when a store built to an earlier model is  
opened, it is (in SIMPLE cases) migrated to the current model.


Is this the case?

In that event, is it necessary to do anything at all (other,  
perhaps, than attaching a version string for human consumption) in  
version 1 to prepare for migration?


— F

___

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/volker_lists%40ecoobs.de

This email sent to volker_li...@ecoobs.de


___

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

Preparing for MOM versioning in version 1

[Fritz Anderson]

I'm about to unleash a Core Data-based application, and I'm sure the  
schema will change in later versions. The Core Data Model Versioning  
and Data Migration Programming Guide seems to say that migrating a  
store from one version to another, at least in simple cases, is  
magical: The application embeds the historical MOMs, with one of them  
marked "current," and when a store built to an earlier model is  
opened, it is (in SIMPLE cases) migrated to the current model.


Is this the case?

In that event, is it necessary to do anything at all (other, perhaps,  
than attaching a version string for human consumption) in version 1 to  
prepare for migration?


— F

___

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: Transitioning to GC-supported

[Jens Alfke]

On Oct 26, 2009, at 6:45 AM, Dave Keck wrote:

1. Apply workaround for interior pointers by '[containingObject  
self];' at

the end of the method, to keep the containing object alive.


A valid point, but in my experience this is a rare problem: I have  
never run into an instance of a bug caused by interior pointers.


2. Go through every -dealloc and implement an -invalidate or  
equivalent for
cases where non-memory-related cleanup is needed, or -finalize if  
absolutely

necessary.


Yup, but you'll find the vast majority of your -dealloc methods only  
release memory so you don't need to create a -finalize.



3. Wrap all CF*Create(), CG*Create(), CF*Copy(), CG*Copy(), etc. with
CFMakeCollectable(), and replace corresponding CFRelease()s with a  
custom
macro - CFReleaseIfRC(). (This way, if I ever choose to go GC-only,  
I can

simply remove all calls to CFReleaseIfRC().)


You only need to worry about this if you cast a CFxxxRef to an NSxxx*  
and later call -release or -autorelease on it. If you just call  
CFRelease without keeping a longer-term reference to the object, you  
don't need to change anything.


Actually it's easier to call NSMakeCollectable, simply because its  
return type is id. Saves you a type-cast.


4. Search for every call to -retain, -alloc, -init pairs, and -copy.  
Verify
that the object being retained is strongly referenced, and if not,  
it must

be CFRetain()ed or -disableCollectorForPointer: must be called for it.


I'm not sure what you mean by this.

5. Search for every call to -release and -autorelease. If the object  
being

released is a CFType, then it must be CFReleaseIfRC() instead.


This is basically what I described above under #3.


6. Search for every use of '&', and use objc_assign_global() and
objc_assign_ivar() as necessary.


I don't know what you mean by this.

In summary, I think what you're saying is formally correct, but you're  
overestimating the amount of trouble. I have converted significant  
amounts of code to be GC-compatible, and only ran into minor problems.  
The biggest thing to watch out for is mixing CF and NS types, and  
mostly you just need to insert an NSMakeCollectable call to take care  
of those. It's really not that bad.


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

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

Re: Professional Error Handling

[Jens Alfke]

On Oct 25, 2009, at 3:44 PM, Dick Bridges wrote:

FWIW, there are some people (myself included) that consider "error  
numbers" to be something of an anti-pattern when exception handling  
is available. Because of [IMHO] improvements in gcc, Objective-C now  
supports exception handling and it might be worth your time to  
investigate how exceptions work.


I happen to agree with you in general, but if you do this in a Cocoa  
app you're going against the grain of the frameworks, which will make  
your life somewhat more difficult. These are issues that come up  
whenever you try to use exceptions in any framework that doesn't use  
them:


First, every time you call a framework function that returns an  
NSError, you're going to have to add a call to a function of your own  
that looks at the NSError* and throws an exception if it's non-nil.  
That's annoying, and causes intermittent problems if you forget it.


Second, you should not throw any exceptions out of your code into  
framework code, or you'll unwind the stack frames of Cocoa methods  
that may need to do cleanup after your call returns. This is very  
likely to result in memory leaks in a non-GC app, and a lot of worse  
things can happen. I have had to debug problems like this in the past,  
and they can be really, really, really nasty to track down.


To prevent that, you have to consider what all of your methods are  
that could be called from framework code, and wrap each of those in an  
@try block, with an @catch that calls another utility function to  
convert the exception into an NSError and return it.


Now you have the problem that all of these methods in your code have  
different semantics, in that they no longer throw exceptions. So your  
code now has two types of exception handling, which you have to take  
into account when calling into your own methods...


It's rather a mess. I would strongly urge you to avoid it unless you  
have a very clear distinction between your own code and the  
frameworks, i.e. this is some kind of back-end code that has one or  
two clear entry points and no callbacks.


—Jens

PS: Also, using exceptions doesn't mean not having error numbers. I  
know Java uses an entire class hierarchy for this, but that turns out  
to be fairly wasteful, as classes cost time and memory to initialize  
at runtime. Moreover, you then have the problem of mapping a class to  
an error message when displaying alerts; it's easier to map error codes.___


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: PackageMaker installer not always installing into /Applications

[Fritz Anderson]

On 25 Oct 2009, at 6:28 PM, Paul Messmer wrote:

I'm trying to build simple application installers (one for 10.4, one  
for 10.5+) that place required files into Application Support as  
well as the application itself into the Applications folder.  Our  
current installers (built with a superset of the script below) work  
fine on a clean machine.  The problem is that if a version of the  
app already exists somewhere else on disk when installer is run, the  
installer overwrites that copy of the app instead of installing into  
the Applications folder - what we'd like.   This could create a  
number of tech-support issues that we'd rather avoid.  Is there a  
reasonable way to get the installer behaviour we want (always simply  
have it install a fresh copy of our app into /Applications?)  The  
version of PackageMaker is 3.0.2 (174).


Installer.app has a feature that tracks down a copy of a previously- 
installed application and updates it, in case the user moved it to a  
more convenient place. This is called "relocation," and there is a  
flag you can set in PackageMaker to turn it off.


However, PackageMaker sets it randomly even if you turn it off. This  
is a bug of years' standing. You can expect a number of years-old bugs  
in PackageMaker.


You deal with this by editing the raw project file before each build,  
preferably with a script you can put into a makefile.


Details in the archive of installer-dev, to which you should direct  
your followups.


— F

___

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

Transitioning to GC-supported

[Dave Keck]

Hey list,

Until recently, I didn't realize that System Preferences on 10.6 required
preferences panes to be GC-supported. As such, I wrote my preference pane
RC-only, and now I've got a fun few weeks ahead of me. :)

I'm planning on systematically going through each of my source files and
updating them to be GC-supported. I've been compiling a list of things to do
and to look out for. So far, this is what I've got:

1. Apply workaround for interior pointers by '[containingObject self];' at
the end of the method, to keep the containing object alive. It would be
great if I had a list of every accessor method that returned an interior
pointer - I figure I'll just make a fancy regex to search through the
framework headers for anything returning a void *, char *, etc., but of
course this won't catch everything. I fear the bugs caused by using interior
pointers will be subtle and intermittent which is why I'd like to exert the
effort to patch every instance in one fell swoop, ideally without having to
re-read every line that I've written for this (somewhat large) project.

2. Go through every -dealloc and implement an -invalidate or equivalent for
cases where non-memory-related cleanup is needed, or -finalize if absolutely
necessary.

3. Wrap all CF*Create(), CG*Create(), CF*Copy(), CG*Copy(), etc. with
CFMakeCollectable(), and replace corresponding CFRelease()s with a custom
macro - CFReleaseIfRC(). (This way, if I ever choose to go GC-only, I can
simply remove all calls to CFReleaseIfRC().)

4. Search for every call to -retain, -alloc, -init pairs, and -copy. Verify
that the object being retained is strongly referenced, and if not, it must
be CFRetain()ed or -disableCollectorForPointer: must be called for it.

5. Search for every call to -release and -autorelease. If the object being
released is a CFType, then it must be CFReleaseIfRC() instead.

6. Search for every use of '&', and use objc_assign_global() and
objc_assign_ivar() as necessary.

7. Search for all opaque pointer types (void *, uintptr_t) and scold them.

8. Test and maintain sanity.

This is my first trip to GC-land, so it's sure to be a learning experience.
Any tips or pitfalls to look out for would be greatly appreciated!

David
___

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: Professional Error Handling

[Alastair Houghton]

On 25 Oct 2009, at 22:44, Dick Bridges wrote:

FWIW, there are some people (myself included) that consider "error  
numbers" to be something of an anti-pattern when exception handling  
is available.


There are also some people (myself included) that consider that you  
are wrong.


This has been discussed before on this very mailing list, so probably  
no need to start the debate again---just search the archives if you're  
interested.


Kind regards,

Alastair.

--
http://alastairs-place.net



___

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: pump event

[Alastair Houghton]

On 25 Oct 2009, at 14:59, simon Scylla wrote:


hello every one

i need to get current system event,waiting until the function get some
event,then remove it from the queue

what should i do?


Usually, *not* that.  There are two occasions on which you *might*  
want to run an event pump yourself:


1. You're implementing mouse tracking.  In this case you have two  
options... either handle mouse events in -mouseDown: in a loop (or in  
your custom NSCell subclass, again in a loop), or use the three method  
approach.  The three method approach (-mouseDown:/-mouseDragged:/- 
mouseUp:) is cleaner and easier to subclass, but it's also slightly  
less responsive.


2. You're writing a computer game.  In this case, you're better off  
asking this question on one of the game developer mailing lists.


Otherwise, you almost certainly don't want to do this.  If you're  
porting code from e.g. Windows that uses its own event pump, there are  
normally better ways to achieve the same effect on Mac OS X.


Kind regards,

Alastair.

--
http://alastairs-place.net



___

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: kCGErrorIllegalArgument: CGSUnionRegionWithRect : Invalid region

[Matthew Lindfield Seager]

It did in fact make it through; a good way to check is to look at
Cocoabuilder (http://www.cocoabuilder.com) and the Apple mailing list
archives (http://lists.apple.com).  In this case, I found your message
here: http://lists.apple.com/archives/cocoa-dev/2009/Oct/msg01683.html


In Jon's defence I thought his email seemed familiar so I went
straight to cocoabuilder & searched for both kCGErrorIllegalArgument &
nall. Neither search revealed either of his posts (they now reveal
yours however Kyle).

That's not to say it isn't on there
(http://www.cocoabuilder.com/archive/message/cocoa/2009/10/22/248139)
just that it doesn't appear to be returned by a standard search

*makes mental note to use Google not cocoabuilder for search next time*

Matt
___

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: MIN(), MAX()?

[Dave Keck]

> also, my flaming shields are up.  this is certainly very basic so flame away
> if you must, but i just can't remember coming across these functions in any
> of my c books.

Try command+double-clicking them in Xcode. That'll take you to their definition.
___

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: MIN(), MAX()?

[Graham Cox]

On 26/10/2009, at 8:35 PM, Chunk 1978 wrote:

i can't find any info about these c functions in the documentation.   
each
take 2 floating point arguments, but i'm not positive what the  
function is

doing with the arguments:

float myMinimumFloat = MIN(50.0, 78.0);


what does the function do with 50 and 78?


also, my flaming shields are up.  this is certainly very basic so  
flame away
if you must, but i just can't remember coming across these functions  
in any

of my c books.



They're not functions, they're macros. I don't think they're part of  
the C standard, but they are very useful and usually one of the first  
things that get added to a runtime.


MIN(a, b) returns the smaller value of a or b, and MAX( a, b ) returns  
the larger value.


Note: Apple's current implementations of MIN and MAX don't nest well  
if you have extra warnings enabled, because they use an internal local  
variable called _a, which is true of both macros, so one ends up  
shadowing the other. It's harmless, but slightly annoying.


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

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

Releasing NSCarbonWindow question.

[Motti Shneor]

Hello everyone.

In my Cocoa Plugin, which runs in a Carbon host application, I need to  
access and manipulate a host-created Carbon window.

My Cocoa interface would be

NSWindow *cocoaWrap = [[NSWindow alloc] initWithWindowRef: hostWindow];

However, when I finish my plugin's work, and I need to release  
everything and return to the host, I want and need to release the  
cocoaWrap object I created. Alas, when I do [cocoWrap release]; it  
closes and dismisses the original host window

This something undesirable, and illegal as far as the host plugin  
interface goes.

If i neglect to release the NSCarbonWindow object (that's what it is  
really isn't it?) then I crash as soon as I return to the host,  
because the  plugin's memory pool is released, and it contains an  
object with nonzero retain count.

How can I break this catch-22 ?




Motti Shneor
--
Senior Software Engineer
Waves Audio ltd.

Phone: +972-3-6094415
Mobile: +972-54-4470730
[mailto: mot...@waves.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

MIN(), MAX()?

[Chunk 1978]

i can't find any info about these c functions in the documentation.  each
take 2 floating point arguments, but i'm not positive what the function is
doing with the arguments:

float myMinimumFloat = MIN(50.0, 78.0);


what does the function do with 50 and 78?


also, my flaming shields are up.  this is certainly very basic so flame away
if you must, but i just can't remember coming across these functions in any
of my c books.
___

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

NSCarbonWindow vs NSSavePanel sheets - Incompatibility?

[Motti Shneor]

Hello everyone. I'm just changing the title of a previous thread, as my 
problems were narrowed down from general NSSavePanel modality, into a 
(possibly) bug in the OS.

The problems occur whenever I try to display  a NSSavePanel as a sheet over a 
Carbon window.

- (void) saveCarbonWindow: (WindowRef) carbonWin
{
NSWindow *cocoaWrap = [[NSWindow alloc] initWithWindowRef: carbonWin]];
NSSavePanel *myPanel=[NSSavePanel savePanel];
[myPanel beginSheetForDirectory:nil file:nil ..

}

No matter what NSSavePanel API I use (10.6 with codeblock completion handler, 
10.5 with didEnd selector, or even runModal) I get strange behaviors.

1. Sometimes the sheet will be displayed  BEHIND its parent (carbon originated) 
window. In such cases, the program hangs as the sheet is still key, but I cant 
dismiss it, because the parent (carbon) window is blocking the events sent to 
it.

2. Most every time it will be displayed in a WRONG PLACE i.e. the sheet is 
centered on screen instead of attached to the carbon window). This is 
especially evident when I try to block after creating the NSSavePanel using 
[NSApp runModalForWindow:myPanel]; In the docs it says that this will center a 
window if it is not visible, but my panel IS visible BEFORE i call on 
runModalForWindow.

3. Sometimes the Save/Cancel (or Open/Cancel in case of NSOpenPanel) will do 
nothing --- as if someone is eating up the events). In that case the didEnd or 
Completion handler will never be called.

Many other weirdnesses happen, and in the Debugger console I can many time 
detect errors concerning the window-ordering of these windows. Things like..
Mon Oct 26 10:31:18 BlancVox.local NavTester[1110] : 
kCGErrorIllegalArgument: _CGSFindSharedWindow: WID 187
Mon Oct 26 10:31:18 BlancVox.local NavTester[1110] : 
kCGErrorIllegalArgument: CGSOrderFrontConditionally: Invalid window

The whole Carbon/Cocoa window binding is very obscure, and I can not find good 
guide for matching the two together.

Another important note: I get the same (well... minor modification...) behavior 
when I use Carbon Navigation Services API's, on Leopard and Snow Leopard. I saw 
in the docs that as of Leopard Navigation Services are Cocoa-based, so that 
might explain this behavior.

I saw in the debugger that the actual class of the cocoaWrap is NSCarbonWindow 
which is not documented at all, and I simply do not know what to do --- Am I 
missing a critical configuration of the carbon window that I need to do before 
attaching an NSSavePanel to it?

Maybe there is a real bug in the OS that I'm not aware of?

Please help.

Motti Shneor
--
Senior Software Engineer
Waves Audio ltd.

Phone: +972-3-6094415
Mobile: +972-54-4470730
[mailto: mot...@waves.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to use Uniform Type Identifiers for this ... ?

[Jay Reynolds Freeman]

By "mousing on", I refer to the action of double-clicking a document  
so as to cause an an appropriate application to launch and deal with  
that document.


The desired actions are:  Double-click Able ==> Alice launches and  
deals with Able; double-click Bravo ==> Bob launches and deals with  
Bravo.  Dragging Bravo onto Alice or Able onto Bob should result in no  
launch of either.


The goal is an end-to-end test of the double-click/launch/deal-with  
process.  There are matters of initialization and synchronization of  
the various threads of my app, hence I intend to test all flavors of  
document-opens-on-launch frequently, to be sure I have not messed  
things up.


I thank the group for advice, I think I am on top of this one for the  
moment.


--  Jay Reynolds Freeman
-
jay_reynolds_free...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)


On Oct 25, 2009, at 11:57 PM, Greg Guerin wrote:

Drag the binary file of interest onto the given version of "MyApp".   
You don't have to rely on Finder matching them up.  You can do it  
yourself, and IIRC the same sequence of actions/events results as if  
the app were started by double-clicking the data file in Finder.  I've  
done tests like this myself and never seen a difficulty.


Or I may still be misunderstanding what you're trying to do.  It might  
clarify things if you called the two versions of your app Alice and  
Bob, and two versions of the file Able and Bravo.  So Alice can get  
Able or Bravo files, Bob can get Able or Bravo files, and tell us what  
you want to happen (or don't want to happen).


Finally, I'm unsure of exactly what you mean in your original post  
when you use the word "mouse" as a verb, as in "If I mouse on ...".   
Do you mean a hover, a single-click, a double-click, a drag-n-drop, or  
a contextual-click (right or ctrl click)?  All of these gestures  
involve the mouse, but each one is a distinct gesture with a distinct  
meaning.


___

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: Professional Error Handling

[Kyle Sluder]

On Sun, Oct 25, 2009 at 3:44 PM, Dick Bridges  wrote:
> N.B. Switching from error codes to exception handling can be somewhat 
> disconcerting initially so it's probably not something you'd want to take on 
> if you are under strong time pressures.

In Cocoa, we don't use exceptions to handle cases other than
programmer error.  Since your code will probably interact with the
framework at some point, it will probably be better if you do the
same.

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

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

Re: PackageMaker installer not always installing into /Applications

[Kyle Sluder]

You want the installer-dev list.

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

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

Re: pump event

[Jonathan Hess]

Perhaps you're looking for these methods:

-[NSApplication currentEvent]
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]

Documented here:

http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html

Good Luck -
Jon Hess

On Oct 25, 2009, at 7:59 AM, simon Scylla wrote:


hello every one

i need to get current system event,waiting until the function get some
event,then remove it from the queue

what should i do?
___

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/jhess%40apple.com

This email sent to jh...@apple.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to use Uniform Type Identifiers for this ... ?

[Greg Guerin]

Subject: Re: How to use Uniform Type Identifiers for this ... ?
From: Jay Reynolds Freeman 
Date: Sun, 25 Oct 2009 20:28:24 -0700
Delivered-to: em...@hidden
Delivered-to: em...@hidden


The issue isn't that it crashes, the issue is that I cannot test  
that any given version of "MyApp" does the right thing with the  
right version of the binary file, unless I can get the finder to  
match up the file that I mouse on with the right version of the app.



Drag the binary file of interest onto the given version of "MyApp".   
You don't have to rely on Finder matching them up.  You can do it  
yourself, and IIRC the same sequence of actions/events results as if  
the app were started by double-clicking the data file in Finder.   
I've done tests like this myself and never seen a difficulty.


Or I may still be misunderstanding what you're trying to do.  It  
might clarify things if you called the two versions of your app Alice  
and Bob, and two versions of the file Able and Bravo.  So Alice can  
get Able or Bravo files, Bob can get Able or Bravo files, and tell us  
what you want to happen (or don't want to happen).


Finally, I'm unsure of exactly what you mean in your original post  
when you use the word "mouse" as a verb, as in "If I mouse on ...".   
Do you mean a hover, a single-click, a double-click, a drag-n-drop,  
or a contextual-click (right or ctrl click)?  All of these gestures  
involve the mouse, but each one is a distinct gesture with a distinct  
meaning.


  -- GG

___

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

PackageMaker installer not always installing into /Applications

[Paul Messmer]

I'm trying to build simple application installers (one for 10.4, one for 10.5+) 
that place required files into Application Support as well as the application 
itself into the Applications folder.  Our current installers (built with a 
superset of the script below) work fine on a clean machine.  The problem is 
that if a version of the app already exists somewhere else on disk when 
installer is run, the installer overwrites that copy of the app instead of 
installing into the Applications folder - what we'd like.   This could create a 
number of tech-support issues that we'd rather avoid.  Is there a reasonable 
way to get the installer behaviour we want (always simply have it install a 
fresh copy of our app into /Applications?)  The version of PackageMaker is 
3.0.2 (174).
Thanks,-- Paul

mkdir "$STAGINGDIR/software"mkdir "$STAGINGDIR/software/Applications"ditto -v 
"$APPDIR/$APPNAME.app" "$STAGINGDIR/software/Applications/$APPNAME.app"
mkdir "$STAGINGDIR/software/Library"mkdir 
"$STAGINGDIR/software/Library/Application Support"mkdir 
"$STAGINGDIR/software/Library/Application Support/$COMPANY"mkdir 
"$STAGINGDIR/software/Library/Application Support/$COMPANY/$APPNAME"ditto -v 
"$APPSUPPORTDIR/$COMPANY/$APPNAME/Version 3" 
"$STAGINGDIR/software/Library/Application Support/$COMPANY/$APPNAME/Version 3"
$PACKAGEMAKER \  --root "$STAGINGDIR/software" \  --out "$OUTPUTDIR/$OUTPUT" 
\  --title "$APPNAME 3 for OS X 10.5" \  --id 
"com.our-company.our-product.3.osx105" \  --version 1 --target 10.5 --domain 
system --verbose --root-volume-only

(The 10.4 installer is built similarly, but with "--target 10.4")
  
___

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