Re: Navigating in a NSTableView with tab key
On Aug 8, 2012, at 11:09 PM, François Pelsser wrote:
> Hello,
> I want to be able to navigate in a table view with the tab key. So i
> subclassed NSTableView and i added the overwrite the method
>
>
> - (void) textDidEndEditing: (NSNotification *) notification
Since NSTableView subclasses NSControl, you should instead implement
-controlTextDidEditing: on your table view's delegate.
>
> {
>
>CellLoc editedCell;
>
>editedCell.col = [super editedColumn];
>
>editedCell.row = [super editedRow];
>
>
>NSDictionary *userInfo = [notification userInfo];
>
>int textMovement = [[userInfo valueForKey:@"NSTextMovement"] intValue];
>
>
>[super textDidEndEditing:notification];
>
>
>
>if (textMovement == NSTabTextMovement)
>
>{
>
>
>CellLoc nextCell = [self nextEditableCell:editedCell];
>
>
>
>[self selectRowIndexes:[NSIndexSet indexSetWithIndex:nextCell.row]
> byExtendingSelection:NO];
>
>if(nextCell.row > editedCell.row)
>
>[self editColumn:nextCell.col row:nextCell.row withEvent: nil
> select: YES];
>
>
>
>
>}
>
> }
>
>
>
> CellLoc is a dummy struc containing row and col.
>
> The problem is that the movement in cells is ok but when editColumn is
> called the elements edited are cancelled. So it is like i didn't change
> the text. (I use a datasource
> and -tableView:setObjectValue:forTableColumn:row: is not called)
Try sending -validateEditing to the table view before calling -editColumn.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
On Aug 9, 2012, at 10:47 AM, Ken Thomases wrote:
> Better would be to create a property on your controller which returns the
> predicate, constructing it on demand for each call (perhaps with some smart
> caching). (I'll call the property "minMaxPredicate" for discussion.) Bind
> the array controller's filterPredicate binding to that property on your
> controller. Then, arrange for KVO change notifications to be emitted for the
> property when the minimum and maximum value properties change. The easiest
> way to do this is to add a method like the following to your class:
>
> + (NSSet *) keyPathsForValuesAffectingMinMaxPredicate
> {
> return [NSSet setWithObjects:@"minimumValue", @"maximumValue", nil];
> }
Thanks Ken. I implemented this all, but are having some trouble with the
correct syntax for the predicate I'll use for this:
I added this to my Controller loadview method:
self.minMaxPredicate = [NSPredicate predicateWithFormat:@"%f < value < %f",
self.minValue, self.maxValue];
Where the float "value" is a property of the entity that I am displaying in
the table and self.minValue and self.maxValue are floats bound to my
NSTextFields.
But no matter what I try, I get an error "Unable to parse the format string".
Any suggestions?
- Koen.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
MPMoviePlayerController doesn't work with remoteControlReceivedWithEvent
I want to allow the controls from my keyboard to work in my app. The controls
use Apple's Remote Control events (beginReceivingRemoteControlEvents,
endReceivingRemoteControlEvents, and remoteControlReceivedWithEvent), however I
cannot seem to get this to work with MPMoviePlayerController.
I do not see any events at the start of the program, even though
beginReceivingRemoteControlEvents is called at the start.
I do not see any events during the playback of a video.
I do see events after I close the video.
>From the above, it seems that the audio stream of MPMoviePlayerController
>disables the controls. However I do not know how to change this. I tried using
>[moviePlayer setUseApplicationAudioSession:NO]; to change the audio to use the
>system session, yet it does nothing.
Here is my setup. My app delegate is a UIViewController. I set the main
window's root view controller to the app delegate, add views to the view
controller and in the view controller for the parts which has to do with video.
- (BOOL)canBecomeFirstResponder {
return YES;
}
- (void)tableView:(UITableView *)theTableView
didSelectRowAtIndexPath:(NSIndexPath *)theIndexPath {
NSString *file = [[MGMFilesPath stringByExpandingTildeInPath]
stringByAppendingPathComponent:[files objectAtIndex:[theIndexPath
indexAtPosition:1]]];
AVAudioSession *audioSession = [AVAudioSession sharedInstance];
[audioSession setCategory:AVAudioSessionCategoryPlayback error:nil];
[audioSession setActive:YES error:nil];
NSLog(@"%d", [self isFirstResponder]);
moviePlayer = [[MPMoviePlayerController alloc] initWithContentURL:[NSURL
fileURLWithPath:file]];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(exitedFullscreen:)
name:MPMoviePlayerDidExitFullscreenNotification object:moviePlayer];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(playbackFinished:)
name:MPMoviePlayerPlaybackDidFinishNotification object:moviePlayer];
if ([moviePlayer respondsToSelector:@selector(setFullscreen:animated:)]) {
[[self view] addSubview:[moviePlayer view]];
[moviePlayer setFullscreen:YES animated:YES];
[moviePlayer play];
} else {
[moviePlayer play];
}
[fileView deselectRowAtIndexPath:theIndexPath animated:NO];
}
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
[[UIApplication sharedApplication] beginReceivingRemoteControlEvents];
[self becomeFirstResponder];
}
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[[UIApplication sharedApplication] endReceivingRemoteControlEvents];
[self resignFirstResponder];
}
- (void)remoteControlReceivedWithEvent:(UIEvent *)event {
NSLog(@"remoteControlReceivedWithEvent: %@", event);
if (event.type==UIEventTypeRemoteControl) {
if (event.subtype==UIEventSubtypeRemoteControlPlay) {
NSLog(@"Play");
} else if (event.subtype==UIEventSubtypeRemoteControlPause) {
NSLog(@"Pause");
} else if (event.subtype==UIEventSubtypeRemoteControlTogglePlayPause) {
NSLog(@"Play Pause");
}
}
}
- (void)exitedFullscreen:(NSNotification *)notification {
[[moviePlayer view] removeFromSuperview];
[moviePlayer stop];
[moviePlayer release];
moviePlayer = nil;
[[AVAudioSession sharedInstance] setActive:NO error:nil];
}
- (void)playbackFinished:(NSNotification *)theNotification {
[[NSNotificationCenter defaultCenter] removeObserver:self
name:MPMoviePlayerDidExitFullscreenNotification object:moviePlayer];
[[NSNotificationCenter defaultCenter] removeObserver:self
name:MPMoviePlayerPlaybackDidFinishNotification object:moviePlayer];
NSNumber *reason = [[theNotification userInfo]
objectForKey:MPMoviePlayerPlaybackDidFinishReasonUserInfoKey];
if ([reason intValue]!=MPMovieFinishReasonUserExited) {
[moviePlayer setFullscreen:NO animated:YES];
[[moviePlayer view] removeFromSuperview];
[moviePlayer stop];
[moviePlayer release];
moviePlayer = nil;
[[AVAudioSession sharedInstance] setActive:NO error:nil];
}
NSLog(@"%d", [self isFirstResponder]);
}
As you can see in the code above, I verified that it was first responder and it
was, so I know it's not a first responder issue.
Can someone help me get this working?
Thanks
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
On Aug 10, 2012, at 5:07 AM, Koen van der Drift wrote:
>
> On Aug 9, 2012, at 10:47 AM, Ken Thomases wrote:
>
>> Better would be to create a property on your controller which returns the
>> predicate, constructing it on demand for each call (perhaps with some smart
>> caching). (I'll call the property "minMaxPredicate" for discussion.) Bind
>> the array controller's filterPredicate binding to that property on your
>> controller. Then, arrange for KVO change notifications to be emitted for
>> the property when the minimum and maximum value properties change. The
>> easiest way to do this is to add a method like the following to your class:
>>
>> + (NSSet *) keyPathsForValuesAffectingMinMaxPredicate
>> {
>> return [NSSet setWithObjects:@"minimumValue", @"maximumValue", nil];
>> }
>
>
> Thanks Ken. I implemented this all, but are having some trouble with the
> correct syntax for the predicate I'll use for this:
>
> I added this to my Controller loadview method:
>
>self.minMaxPredicate = [NSPredicate predicateWithFormat:@"%f < value <
> %f", self.minValue, self.maxValue];
>
> Where the float "value" is a property of the entity that I am displaying in
> the table and self.minValue and self.maxValue are floats bound to my
> NSTextFields.
>
> But no matter what I try, I get an error "Unable to parse the format string".
>
>
>
> Any suggestions?
Where in the predicate formatting guide
(https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Predicates/predicates.html)
does it show that your syntax is in any way valid?
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
On Fri, Aug 10, 2012 at 8:42 AM, Keary Suska wrote: > > Where in the predicate formatting guide > (https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Predicates/predicates.html) > does it show that your syntax is in any way valid? Well, it talks about using the greater than comparator in the Using Predicates section: NSDate *referenceDate = [NSDate dateWithTimeIntervalSince1970:0]; NSPredicate *predicate = [NSPredicate predicateWithFormat:@"birthday > %@", referenceDate]; - Koen. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: PI-iOS 2.51.19 Log for Taleo's iPhone
Thanks. I've switched to just using a stringWithFormat: with CFGregorianDate. Just simpler overall :) On Aug 10, 2012, at 9:28 AM, Philippe Marsteau wrote: > Seems like a iOS bug: > http://stackoverflow.com/questions/143075/nsdateformatter-am-i-doing-something-wrong-or-is-this-a-bug > > Maybe you could be more permissive when filtering file names knowing > that issue? iOS 6 might fix it but I haven't seen official defect > though. Or you could use plain C function (works in objective C) > instead of NSDateFormatter which should be fine for string > manipulation in log files. > > Let me know if it helps. > Philippe > > > On 2012-08-09, at 20:15, Alex Kac wrote: > >> Correct - the AM/PM text in there causes it to fail. The question is - why >> is it doing that? I see explicitly in our code we're setting the format we >> want the text to be made: >> >> //rename our sqlite file >> //basically, we tack on a date & time to the current file name >> NSString *fileExtension = [[self coreDataStorePath] pathExtension]; >> NSDateFormatter *fileArchiveDateFormat = [[NSDateFormatter alloc] init]; >> [fileArchiveDateFormat setDateFormat: @"MMdd_HHmmss"]; >> NSString *newPath = self coreDataStorePath] >> stringByDeletingPathExtension] stringByAppendingString: >> [fileArchiveDateFormat stringFromDate:[NSDate date]]] >> stringByAppendingPathExtension: fileExtension]; >> [fileArchiveDateFormat release]; >> >> >> So if we do that - why in the world is it overriding that and doing >> something else? >> >> On Aug 4, 2012, at 3:50 PM, Philippe Marsteau wrote: >> >>> See other email containing backup file created from the app and listed >>> in the log file. >>> >>> My problem from start to finish is: issue with backup restore function >>> filtering out backup files created within the app. >>> >>> I wonder if the time format (not 24h format) introducing space in file >>> name causes the issue to filter out all files. >>> <000_log.txt><001_log.txt> >> >> Alex Kac - President and Founder >> Web Information Solutions, Inc. >> >> "The person who is not hungry says that the coconut has a hard shell." >> -- African Tribal Saying >> >> >> >> >> >> Alex Kac - President and Founder Web Information Solutions, Inc. "Patience is the companion of wisdom." --Anonymous ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
On 10 Aug 2012, at 7:48 AM, Koen van der Drift
wrote:
> On Fri, Aug 10, 2012 at 8:42 AM, Keary Suska
> wrote:
>>
>
>> Where in the predicate formatting guide
>> (https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Predicates/predicates.html)
>> does it show that your syntax is in any way valid?
>
> Well, it talks about using the greater than comparator in the Using
> Predicates section:
>
> NSDate *referenceDate = [NSDate dateWithTimeIntervalSince1970:0];
> NSPredicate *predicate = [NSPredicate predicateWithFormat:@"birthday >
> %@", referenceDate];
Notice two differences between the documented example and the predicate you
propose:
- The format specification in the example is %@, not a scalar. ("%@ is a var
arg substitution for an object value—often a string, number, or date.")
- The predicate in the documentation does not chain binary comparisons. The
documentation doesn't show any operator precedence — even if legal, your
proposal might be read as [[%f < value] < %f]. It _does_ show a "BETWEEN"
operator.
— 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
Yeah, I saw the BETWEEN a bit later, I'll go ahead and try that. Or
maybe turn my float into an NSNumber, I need to think how that works
with the rest of my model.
- Koen.
On Fri, Aug 10, 2012 at 10:51 AM, Fritz Anderson
wrote:
> On 10 Aug 2012, at 7:48 AM, Koen van der Drift
> wrote:
>
>> On Fri, Aug 10, 2012 at 8:42 AM, Keary Suska
>> wrote:
>>>
>>
>>> Where in the predicate formatting guide
>>> (https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Predicates/predicates.html)
>>> does it show that your syntax is in any way valid?
>>
>> Well, it talks about using the greater than comparator in the Using
>> Predicates section:
>>
>> NSDate *referenceDate = [NSDate dateWithTimeIntervalSince1970:0];
>> NSPredicate *predicate = [NSPredicate predicateWithFormat:@"birthday >
>> %@", referenceDate];
>
> Notice two differences between the documented example and the predicate you
> propose:
>
> - The format specification in the example is %@, not a scalar. ("%@ is a var
> arg substitution for an object value—often a string, number, or date.")
>
> - The predicate in the documentation does not chain binary comparisons. The
> documentation doesn't show any operator precedence — even if legal, your
> proposal might be read as [[%f < value] < %f]. It _does_ show a "BETWEEN"
> operator.
>
> — 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How make iPhone HOT (yes, increase the temperature)??
Hi Rodrigo, For some reasons [1], getting an iPhone hot is trickier than it looks and engineers have worked hard to make this device's operation as energy-efficient as possible. The only way to make an iPhone heat itself, when not connected to a power source, is by draining its battery power as fast as you can in the most inefficient way possible. The quicker you drain the battery, the less efficient you use that energy, the hotter the device gets (users may not thank you for that). And then you hit this little snag where you can't really control efficiency. Apple engineers made sure iPhones would dissipate as little heat as possible for their operation in order to maximize battery life. So, you're left with controlling the power: the rate at which you spend (drain) the device's battery energy. As you mentioned before, getting the iPhone hot can be achieved by transmitting data over the phone network (3G) or as Alex Zavatone pointed out, you can load the cores (code for such task should be available in some open source tools for linux, achieving this goal on x86 processors). But, that's it. You don't have a lot of flexibility and depending on your specifications it may not be enough (you can't drain the battery in a snap). To give you a more accurate idea of what you can get: An iPhone 4s fully charged stores approximately 19 kJ of power (1.432 Ah; 3.7 V). Using 60% of this energy (from 80 % charge down to 20 %) you get roughly 11.5 kJ. That's the energy required to heat 270 mL of water up by 10 °C (10 °K; 18 °F). And that's only if you proceed really quickly and you get 100 % of your energy in the form of heat (which you won't). Real-world result *will* be worse (The water is not the only thing you heat, you also need to heat the phone. And both are passively cooled down by their environment, so you have to act fast, which is not possible => power control…). It may not even be enough to really heat your hands in cold winter (let me know). Moreover nice chemical devices are commercially available that nicely do the job without killing your mobile's battery life. This is just an "order of magnitude" assessment. An apple engineer would have more data to help. Or you can look on the internet. Maybe keywords such as "Joule power iPhone" could do the trick. With all the tear-downs going on for each iPhone launch I wouldn't be surprised to find some informations on this topic… Cheers, Jean [1] Usually, heat is viewed as an energy wasteful side-effect of electronic devices operation plaguing the industry. Heat is especially bad for mobile devices with limited power supply since it further the reduces the amount of energy actually available for their operation and drains their batteries. Jean Suisse Institut de Chimie Moléculaire de l’Université de Bourgogne (ICMUB) — UMR 6302 U.F.R. Sciences et Techniques, Bâtiment Mirande Aile B, bureau 411 9, avenue Alain Savary — B.P. 47870 21078 DIJON CEDEX T: +333-8039-9037 F: +339-7223-9232 E: jean.sui...@u-bourgogne.fr http://www.icmub.fr/185-JEAN-SUISSE_?id=331 On 8 août 2012, at 21:58, Rodrigo Zanatta Silva wrote: > Hi. I am thinking to do a funny program that make the iPhone to be HOT. I > intensionally want the device increase your temperature. > > Using the iPhone, I knot it will be hot if I use the 3G Internet. > Programing, I can try the program continually transfer files. > > What other strategy I can use to do this? Any idea? > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/jean.lists%40gmail.com > > This email sent to jean.li...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Formatting a set of NSDecimalNumber values
I'm working on an app where I need to take several sets of numeric values (currently stored as NSDecimalNumber), and display them in columns. Each set will have approximately the same magnitude, but the magnitude of each set may change, and I won't know ahead of time what they are. So one might be values like (1.23, 2.3, 1.567), and another (1234.1, 2345, 1999.4). In order to make the columns line up, and to know how much space I'll need, what I'd like to do is to figure out, for each set of numbers, the width of the format I'll need. In other words, the maximum number of integer places, and the maximum number of fractional places. For the examples above: 1 and 3 in the first case, 4 and 1 in the second. Now, the NSDecimal representation would answer this directly, by combining the length of the mantissa and the value of the exponent. The problem is, the fields of that structure are explicitly private, and there doesn't appear to be any API to get the values of the mantissa and exponent out of it. One workaround might be to convert each number to a string in the POSIX locale, and then measure its length and the position of the decimal point. But that seems like a very long way around. And I'm shamefully sketchy on my C math, but I'd guess that there's a route to the answer there, also (possibly with some loss of precision?). What's the simplest and/or most efficient way of deriving this information? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Formatting a set of NSDecimalNumber values
On Aug 10, 2012, at 8:58 AM, Sixten Otto wrote: > In order to make the columns line up, and to know how much space I'll > need, what I'd like to do is to figure out, for each set of numbers, > the width of the format I'll need. In other words, the maximum number > of integer places, and the maximum number of fractional places. Just to make things even more complicated: you're assuming digits are monospaced. In many fonts they are not — it generally looks better if a 1 is narrower than a 0, for instance. The "." is also pretty much guaranteed to be a lot narrower than a digit, and the "e" in scientific notation will be a different width too. There's also the matter that number formatting is localizable. Many countries use "," for a decimal point. > One workaround might be to convert each number to a string in the > POSIX locale, and then measure its length and the position of the > decimal point. That doesn't seem like a workaround, it seems like the correct solution (although why not use the user's real locale?). Fundamentally you are trying to display and align character strings, so you have to treat the numbers as strings when computing their alignment. For best results use AppKit (or UIKit?) methods to compute the pixel width of each string in the font you're using. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trying to capture raw touch events on the trackpad
mouseEntered do you also have a tracking area setup? When are you calling setAcceptsTouchEvent:? FYI, You won't get touch events unless the cursor is over your view when the first touch occurs. While dragging the cursor, the touch doing that was latched to some other view. All touches are latched to that other view until the user removes all touches and starts over. -raleigh On Jul 27, 2012, at 5:25 AM, Akhil Jindal wrote: > Hi all, > > I'm trying to capture raw touch events on the trackpad to define my own > gesture events. I've gone through the documentation here: > http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html > > I've set [mView setAcceptsTouchEvents:YES] and implemented the following > functions: > > > - (void)touchesBeganWithEvent:(NSEvent *)event; > > - (void)touchesMovedWithEvent:(NSEvent *)event; > > > - (void)touchesEndedWithEvent:(NSEvent *)event; > > - (void)touchesCancelledWithEvent:(NSEvent *)event; > > > but *I'm just not getting any calls in any of the above functions*. I keep > getting calls in mouseMoved, mouseEntered, but not any touch messages. > > Am I missing something? > > Kindly help. > > Regards, > Akhil Jindal > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/ledet%40apple.com > > This email sent to le...@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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
They are not alternatives, and the conversion to NSNumber is not optional. You
have to do all three.
— F
On 10 Aug 2012, at 9:58 AM, Koen van der Drift
wrote:
> Yeah, I saw the BETWEEN a bit later, I'll go ahead and try that. Or
> maybe turn my float into an NSNumber, I need to think how that works
> with the rest of my model.
>
> - Koen.
>
>
>
> On Fri, Aug 10, 2012 at 10:51 AM, Fritz Anderson
> wrote:
>> On 10 Aug 2012, at 7:48 AM, Koen van der Drift
>> wrote:
>>
>>> On Fri, Aug 10, 2012 at 8:42 AM, Keary Suska
>>> wrote:
>>>
Where in the predicate formatting guide
(https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Predicates/predicates.html)
does it show that your syntax is in any way valid?
>>>
>>> Well, it talks about using the greater than comparator in the Using
>>> Predicates section:
>>>
>>> NSDate *referenceDate = [NSDate dateWithTimeIntervalSince1970:0];
>>> NSPredicate *predicate = [NSPredicate predicateWithFormat:@"birthday >
>>> %@", referenceDate];
>>
>> Notice two differences between the documented example and the predicate you
>> propose:
>>
>> - The format specification in the example is %@, not a scalar. ("%@ is a var
>> arg substitution for an object value—often a string, number, or date.")
>>
>> - The predicate in the documentation does not chain binary comparisons. The
>> documentation doesn't show any operator precedence — even if legal, your
>> proposal might be read as [[%f < value] < %f]. It _does_ show a "BETWEEN"
>> operator.
>>
>>— 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
On Aug 10, 2012, at 12:28 PM, Fritz Anderson wrote:
> They are not alternatives, and the conversion to NSNumber is not optional.
> You have to do all three.
What? There's no requirement that one use NSNumbers. And BETWEEN is a nice
clear operator to use, but it would be fine to do "%f < value && value < %f".
In fact, the docs for BETWEEN state that it's equivalent to that sort of thing
(except using <= instead of <, which the OP should consider which he wants).
A perfectly suitable solution is:
- (NSPredicate*) minMaxPredicate
{
return [NSPredicate predicateWithFormat:@"%f < value && value < %f",
self.minimumValue, self.maximumValue];
}
+ (NSSet *) keyPathsForValuesAffectingMinMaxPredicate
{
return [NSSet setWithObjects:@"minimumValue", @"maximumValue", nil];
}
Regards,
Ken
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Formatting a set of NSDecimalNumber values
On Aug 10, 2012, at 9:29 AM, Jens Alfke wrote: > > That doesn't seem like a workaround, it seems like the correct solution > (although why not use the user's real locale?). Fundamentally you are trying > to display and align character strings, so you have to treat the numbers as > strings when computing their alignment. For best results use AppKit (or > UIKit?) methods to compute the pixel width of each string in the font you're > using. Don't forget bout languages where numbers read right-to-left. A better solution might be to use a decimal-aligned tabstop in the NSParagraphStyle of all of the currency cells' attributedStringValues. But that might require taking ownership of the entire text system and doing rendering yourself. O, to be able to assign an NSLayoutManager to an NSTextFieldCell… (radar forthcoming). --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Formatting a set of NSDecimalNumber values
I'm definitely aware of the font issues, and those I can deal with (I think?). In particular, if I can line up the decimal separators vertically, everything else should align, as I should be able to force a font that has lining figures. My reasoning for measuring the strings in a fixed locale with a specific format string was specifically to eliminate the issues of localization: have a known decimal separator and nothing else but digits, so that counting the characters doesn't have to account for thousands separators, etc. I could, as you say, measure the drawn sizes of the localized strings. I guess my resistance to that idea is really that I'd have to do it a couple of times (the width of the whole string, and the position of the decimal separator), and that it seems likely to be really slow. On Fri, Aug 10, 2012 at 9:29 AM, Jens Alfke wrote: > > On Aug 10, 2012, at 8:58 AM, Sixten Otto wrote: > > In order to make the columns line up, and to know how much space I'll > need, what I'd like to do is to figure out, for each set of numbers, > the width of the format I'll need. In other words, the maximum number > of integer places, and the maximum number of fractional places. > > > Just to make things even more complicated: you're assuming digits are > monospaced. In many fonts they are not — it generally looks better if a 1 is > narrower than a 0, for instance. The "." is also pretty much guaranteed to > be a lot narrower than a digit, and the "e" in scientific notation will be a > different width too. > > There's also the matter that number formatting is localizable. Many > countries use "," for a decimal point. > > One workaround might be to convert each number to a string in the > POSIX locale, and then measure its length and the position of the > decimal point. > > > That doesn't seem like a workaround, it seems like the correct solution > (although why not use the user's real locale?). Fundamentally you are trying > to display and align character strings, so you have to treat the numbers as > strings when computing their alignment. For best results use AppKit (or > UIKit?) methods to compute the pixel width of each string in the font you're > using. > > —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Not getting all the data over the cell network
Hi Jens, Thanks for pointing me to the other list. I'll continue the conversation over there. To answer your questions quickly here: Generally around 10% of the data doesn't arrive, and it's a different amount every time. As far as I can tell the data is truncated. AT&T cell network here. Unknown at another test location, but checking. -Stevo Brock Sunset Magicwerks, LLC www.sunsetmagicwerks.com 818-609-0258 On Aug 9, 2012, at 11:37 PM, Jens Alfke wrote: > > On Aug 8, 2012, at 12:19 PM, Stevo Brock > wrote: > >> What we see is that occasionally (25% of the time?) the app loads all 87187 >> bytes, but the rest of the time, the app loads less data and no error or any >> other condition is ever returned. > > How much less data? Is it just truncated, or is it the wrong data entirely? > > Also, exactly which cell network is this? Anything special about the server? > > My guess is that it's something going on with the cell network; a lot of them > use proxies. > > Finally, the macnetworkprog list on this site is the best place to ask this; > you have a better chance of reaching the Apple networking gurus. > > —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Formatting a set of NSDecimalNumber values
On Fri, Aug 10, 2012 at 10:46 AM, Kyle Sluder wrote: > Don't forget bout languages where numbers read right-to-left. Like which? (I had, shamefully, completely forgotten r-t-l text in this scheme. But some casual googling leads me to believe that Hebrew and Arabic, at least, write numbers in big-endian form like English.) And while we're poking holes in this idea of mine, are there any iOS localizations that use non-Arabic numerals? :-) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Formatting a set of NSDecimalNumber values
On Aug 10, 2012, at 10:55 AM, Sixten Otto wrote: > I could, as you say, measure the drawn sizes of the localized strings. > I guess my resistance to that idea is really that I'd have to do it a > couple of times (the width of the whole string, and the position of > the decimal separator), and that it seems likely to be really slow. No slower than the kind of layout the text system is already doing in most apps. :) I think all you need to do is measure each number once. Find the offset in the string of the decimal point, measure the width of the substring before it, then move that far to the left of your desired decimal guideline before drawing the entire string. If you want to find the maximum width, then you'll also need to measure the width of the entire string. (Don't just measure the width of the substring starting at the decimal point and add that to the first width; due to factors like kerning, you can't add substring widths that way.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
On Fri, Aug 10, 2012, at 10:44 AM, Ken Thomases wrote: > What? There's no requirement that one use NSNumbers. You're correct, but I certainly didn't expect that! From the Predicate Programming Guide: "The format string supports printf-style format arguments such as %x (see “Formatting String Objects”). Two important arguments are %@ and %K." But what can "%x" possibly mean in this context? Do you need to provide a hex-formatted C string or an integer? If the latter, how does this format specifier differ from "%d"? In practice, it looks like "%x" and "%d" are synonymous, and they mean you can provide a numeric argument. This is just an additional way this method differs from printf and NSLog, where %K isn't a valid format specifier. The Predicate Programming Guide needs to stop relying on half-true references to similar pieces of functionality when defining its grammar. It's been a woefully underspecified document for years. (Predicate Format String Syntax document is underspecified) --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Formatting a set of NSDecimalNumber values
On Fri, Aug 10, 2012, at 11:05 AM, Sixten Otto wrote: > On Fri, Aug 10, 2012 at 10:46 AM, Kyle Sluder wrote: > > Don't forget bout languages where numbers read right-to-left. > > Like which? (I had, shamefully, completely forgotten r-t-l text in > this scheme. But some casual googling leads me to believe that Hebrew > and Arabic, at least, write numbers in big-endian form like English.) Hmm, it looks like my understanding might've been mistaken. Even the Unicode Bidi Algorithm doesn't seem to handle any cases other than European or Arabic numerals, and it treats both of them the same directionally. Regardless, after you've aligned your cells by decimal point, you probably want to left-align the block of them if you're in an RTL interface. > > And while we're poking holes in this idea of mine, are there any iOS > localizations that use non-Arabic numerals? :-) I haven't looked. Perhaps someone else knows? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: filtering the values in an NSTableColumn
How embarrassing. I relied on the description in the documentation I found, and
didn't go deeper.
Sorry.
— F
On 10 Aug 2012, at 12:44 PM, Ken Thomases wrote:
> On Aug 10, 2012, at 12:28 PM, Fritz Anderson wrote:
>
>> They are not alternatives, and the conversion to NSNumber is not optional.
>> You have to do all three.
>
> What? There's no requirement that one use NSNumbers. And BETWEEN is a nice
> clear operator to use, but it would be fine to do "%f < value && value < %f".
> In fact, the docs for BETWEEN state that it's equivalent to that sort of
> thing (except using <= instead of <, which the OP should consider which he
> wants).
>
> A perfectly suitable solution is:
>
> - (NSPredicate*) minMaxPredicate
> {
> return [NSPredicate predicateWithFormat:@"%f < value && value < %f",
> self.minimumValue, self.maximumValue];
> }
>
> + (NSSet *) keyPathsForValuesAffectingMinMaxPredicate
> {
> return [NSSet setWithObjects:@"minimumValue", @"maximumValue", nil];
> }
>
> Regards,
> Ken
>
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Thousands separators added to number fields
As of 10.8, it looks like thousands separators are automatically added to numbers displayed in text boxes. Can this be disabled? In some places it doesn't make sense like in a display of a year. TIA, Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Get EXIF information from a Quicktime Movie
For a JPG image, I can just use CGImageSourceCopyPropertiesAtIndex to obtain the various bits of EXIF information from the image. However, this API does not work with quicktime movie files. What similar Cocoa APIs can I use to extact EXIF information from a Quicktime movie file? Or, if there aren't any Cocoa APIs, what might my best option be? Anyone face a similar issue? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thousands separators added to number fields
> As of 10.8, it looks like thousands separators are automatically added to > numbers displayed in text boxes. > Can this be disabled? In some places it doesn't make sense like in a display > of a year. Ok, I see from: https://developer.apple.com/library/mac/#releasenotes/CoreFoundation/CoreFoundation.html that +[NSString localizedStringWithFormat:] which I am using now adds the thousands separators. I don't see a way around this. Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thousands separators added to number fields
On Fri, Aug 10, 2012, at 01:17 PM, James Merkel wrote: > > As of 10.8, it looks like thousands separators are automatically added to > > numbers displayed in text boxes. > > Can this be disabled? In some places it doesn't make sense like in a > > display of a year. > > Ok, I see from: > https://developer.apple.com/library/mac/#releasenotes/CoreFoundation/CoreFoundation.html > that +[NSString localizedStringWithFormat:] which I am using now adds the > thousands separators. I don't see a way around this. Aside from attaching an NSNumberFormatter to the text field? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thousands separators added to number fields
On Aug 10, 2012, at 1:17 PM, James Merkel wrote: > +[NSString localizedStringWithFormat:] Never mind -- I see I can use +[NSString stringWithFormat:] rather than +[NSString localizedStringWithFormat:] to avoid the thousand separators. Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thousands separators added to number fields
Ok, I could do it that way also. Jim Merkel On Aug 10, 2012, at 1:28 PM, Kyle Sluder wrote: > On Fri, Aug 10, 2012, at 01:17 PM, James Merkel wrote: >>> As of 10.8, it looks like thousands separators are automatically added to >>> numbers displayed in text boxes. >>> Can this be disabled? In some places it doesn't make sense like in a >>> display of a year. >> >> Ok, I see from: >> https://developer.apple.com/library/mac/#releasenotes/CoreFoundation/CoreFoundation.html >> that +[NSString localizedStringWithFormat:] which I am using now adds the >> thousands separators. I don't see a way around this. > > Aside from attaching an NSNumberFormatter to the text field? > > --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
help indexer or hiutil help
I'm trying to use Help Indexer.app after a long while and a few upgrades of a working help project. When trying to select the MyHelp.help bundle, I can't because its grayed out. Any ideas? But I can get into the bundle on the command line, so I go into the dirs and try to use hiutil as shown in the man page (-Caf), and then follow up with hiutil -Af, but it keeps returning null. $ hiutil -Caf ./MyHelp.index . (tried current dir, top level dir, etc...) $ hiutil -Af ./MyHelp.index (null) My structure looks like this. MyHelp.help/ `- Contents/ |- Info.plist `- Resources |- English.proj\ | |- MyHelp.html | |- MyHelp.helpindex | |- InfoPlist.strings | |- ... | `- Shared Any help much appreciated. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Aug 10, 2012, at 12:51 AM, Nick Zitzmann wrote: > On Aug 2, 2012, at 7:02 PM, Kurt Bigler wrote: > >> I'd seriously wish for some statement from Apple ASAP if that were a >> possibility that 32-bit support would be fully eliminated in 10.9. > > You won't get one. But between you and me, I would say it is highly unlikely, > since they'd kill MS Office support if they did that, and Office is one of > the two or three most important third-party apps on OS X. MS is, however, working on rewriting Office in Cocoa (2011 already has some components rewritten; presumably, their next release will be more so). I wouldn't count on this situation continuing indefinitely. I'd get started on rewriting your app if I were you. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Aug 10, 2012, at 5:17 PM, Charles Srstka wrote: >> You won't get one. But between you and me, I would say it is highly >> unlikely, since they'd kill MS Office support if they did that, and Office >> is one of the two or three most important third-party apps on OS X. > > MS is, however, working on rewriting Office in Cocoa (2011 already has some > components rewritten; presumably, their next release will be more so). I > wouldn't count on this situation continuing indefinitely. > > I'd get started on rewriting your app if I were you. Except Apple itself says it might not make sense to do so. From the 64-bit Transition Guide: "Although 64-bit executables make it easier for you to manage large data sets (compared to memory mapping of large files in a 32-bit application), the use of 64-bit executables may raise other issues. Therefore you should transition your software to a 64-bit executable format only when the 64-bit environment offers a compelling advantage for your specific purposes. This chapter explores some of the reasons you might or might not want to transition your software to a 64-bit executable format…." https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/indications/indications.html#//apple_ref/doc/uid/TP40001064-CH206-TPXREF101 Best, __jayson Circus Ponies NoteBook - Introducing An App That Boosts Your Productivity at Work or School, So You Get The Grades, Raises and Promotions You Want. www.circusponies.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Detecting focus on control
Is it the case that setting up a trackingArea over a given control is the easiest way to detect the arrival of focus on a given control? I'm thinking in terms of tab-advancing keyboard activity here, where the user advances onto a modestly complex screen region (a postal address displayed in NSBox holding a multiLineLabel). Upon arrival of focus I want to swap in a fielded edit interface. It seems like this sort of awareness ought to be trivial to glean, but I'm not seeing it in NSView nor NSControl where I would expect to find it documented. Advice on where I ought to look? TIA ~ Erik ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Fri, Aug 10, 2012, at 05:44 PM, Jayson Adams wrote: > Except Apple itself says it might not make sense to do so. From the > 64-bit Transition Guide: > > "Although 64-bit executables make it easier for you to manage large > data sets (compared to memory mapping of large files in a 32-bit > application), the use of 64-bit executables may raise other issues. Therefore > you should transition your software to a 64-bit executable format only when > the 64-bit environment offers a compelling advantage for your specific > purposes. One might consider "future release of operating system does not refuse to launch your executable" to be a compelling advantage. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Detecting focus on control
On Fri, Aug 10, 2012, at 05:54 PM, Erik Stainsby wrote: > Is it the case that setting up a trackingArea over a given control is the > easiest way to detect the arrival of focus on a given control? Hmm? Tracking areas have nothing to do with focus. You probably want to override -becomeFirstResponder. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Aug 10, 2012, at 7:44 PM, Jayson Adams wrote: > On Aug 10, 2012, at 5:17 PM, Charles Srstka wrote: > >>> You won't get one. But between you and me, I would say it is highly >>> unlikely, since they'd kill MS Office support if they did that, and Office >>> is one of the two or three most important third-party apps on OS X. >> >> MS is, however, working on rewriting Office in Cocoa (2011 already has some >> components rewritten; presumably, their next release will be more so). I >> wouldn't count on this situation continuing indefinitely. >> >> I'd get started on rewriting your app if I were you. > > Except Apple itself says it might not make sense to do so. From the 64-bit > Transition Guide: > > "Although 64-bit executables make it easier for you to manage large > data sets (compared to memory mapping of large files in a 32-bit > application), the use of 64-bit executables may raise other issues. Therefore > you should transition your software to a 64-bit executable format only when > the 64-bit environment offers a compelling advantage for your specific > purposes. > > This chapter explores some of the reasons you might or might not want to > transition your software to a 64-bit executable format…." > > https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/indications/indications.html#//apple_ref/doc/uid/TP40001064-CH206-TPXREF101 That article is wildly out of date. Notice how it emphatically advises you *not* to compile your applications as 64-bit only, whereas 64-bit only is not only the default nowadays, but is required for all the latest additions Apple has made to the language (including, but not limited to, ARC). It also advises that you should include PPC code in your binaries, which Xcode doesn't even let you *do* anymore. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Detecting focus on control
On 11/08/2012, at 10:54 AM, Erik Stainsby wrote: > It seems like this sort of awareness ought to be trivial to glean, but I'm > not seeing it in NSView nor NSControl where I would expect to find it > documented. Advice on where I ought to look? Keep going: these inherit from NSResponder. Tracking areas are intended for managing the cursor. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Detecting focus on control
If there's one specific control class that you want to detect focus for, you can subclass it and override becomeFirstResponder. If super returns true, do your thing. If you want to apply this to a bunch of varied controls, you might want to use a subclass of NSWindow and override makeFirstResponder: (again, checking what super returns). --Andy On Aug 10, 2012, at 8:54 PM, Erik Stainsby wrote: > Is it the case that setting up a trackingArea over a given control is the > easiest way to detect the arrival of focus on a given control? > > I'm thinking in terms of tab-advancing keyboard activity here, where the user > advances onto a modestly complex screen region (a postal address displayed in > NSBox holding a multiLineLabel). Upon arrival of focus I want to swap in a > fielded edit interface. > > It seems like this sort of awareness ought to be trivial to glean, but I'm > not seeing it in NSView nor NSControl where I would expect to find it > documented. Advice on where I ought to look? > > TIA > ~ Erik > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com > > This email sent to ag...@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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Aug 10, 2012, at 5:57 PM, Charles Srstka wrote: > On Aug 10, 2012, at 7:44 PM, Jayson Adams wrote: > >> Except Apple itself says it might not make sense to do so. From the 64-bit >> Transition Guide: >> >> https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/indications/indications.html#//apple_ref/doc/uid/TP40001064-CH206-TPXREF101 > > That article is wildly out of date. Notice how it emphatically advises you > *not* to compile your applications as 64-bit only, whereas 64-bit only is not > only the default nowadays, but is required for all the latest additions Apple > has made to the language (including, but not limited to, ARC). Not everyone uses ARC, or the other recent additions Apple has made to the language. > It also advises that you should include PPC code in your binaries, which > Xcode doesn't even let you *do* anymore. This is not the first piece of Apple documentation to contain stale info. It is a leap to conclude that those portions invalidate the rest of the document. I'm not trying to argue that you are wrong in your general conclusion about the fate of 32-bit, because you don't know and I don't know either. What I am saying, though, is that for all of the 32-bit-the-sky-is-falling, the first place a 32-bit straggler turns—the 64-bit porting guide—the beast itself states upfront that you really may not want to make the transition after all. Best, __jayson Circus Ponies NoteBook - Introducing An App That Boosts Your Productivity at Work or School, So You Get The Grades, Raises and Promotions You Want. www.circusponies.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Aug 10, 2012, at 7:42 PM, Jayson Adams wrote: > I'm not trying to argue that you are wrong in your general conclusion about > the fate of 32-bit, because you don't know and I don't know either. What I > am saying, though, is that for all of the 32-bit-the-sky-is-falling, the > first place a 32-bit straggler turns—the 64-bit porting guide—the beast > itself states upfront that you really may not want to make the transition > after all. We recommend that you transition your app to 64-bit. Many of the caveats in the 64-Bit Transition Guide are no longer applicable. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On 8/10/12, Jayson Adams wrote: > > On Aug 10, 2012, at 5:57 PM, Charles Srstka wrote: > >> On Aug 10, 2012, at 7:44 PM, Jayson Adams wrote: >> >>> Except Apple itself says it might not make sense to do so. From the >>> 64-bit Transition Guide: >>> >>> https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/indications/indications.html#//apple_ref/doc/uid/TP40001064-CH206-TPXREF101 >> >> That article is wildly out of date. Notice how it emphatically advises you >> *not* to compile your applications as 64-bit only, whereas 64-bit only is >> not only the default nowadays, but is required for all the latest >> additions Apple has made to the language (including, but not limited to, >> ARC). > > Not everyone uses ARC, or the other recent additions Apple has made to the > language. > >> It also advises that you should include PPC code in your binaries, which >> Xcode doesn't even let you *do* anymore. > > > This is not the first piece of Apple documentation to contain stale info. > It is a leap to conclude that those portions invalidate the rest of the > document. > > I'm not trying to argue that you are wrong in your general conclusion about > the fate of 32-bit, because you don't know and I don't know either. What I > am saying, though, is that for all of the 32-bit-the-sky-is-falling, the > first place a 32-bit straggler turns—the 64-bit porting guide—the beast > itself states upfront that you really may not want to make the transition > after all. > There are actually other compelling reasons to move to 64-bit that have nothing to do with the amount of addressable memory or max int. For example, i386 is register starved which has implications on performance. The modern CPU architectures come with security features like data execution prevention and so forth which aren't available in i386. But as I stated earlier, I have already been the victim of i386 bugs in 10.7 and 10.8 that don't exist on the x86_64 (nor do they exist on the iOS side (which is also 32-bit)). To me, this means Apple is not aggressively testing i386. I would extrapolate they are also not going to put priority on fixing these kinds of bugs. Nor do I have any delusion that Apple wants to continue testing/maintaining Mac i386. I'm already surprised they continue to give API parity in the frameworks for 32-bit with new features. But I don't expect that to last. I'm actually surprised 32-bit wasn't dropped in 10.8. (I also expected Java to already be gone after that last security debacle.) -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Aug 10, 2012, at 9:42 PM, Jayson Adams wrote: > On Aug 10, 2012, at 5:57 PM, Charles Srstka wrote: > >> On Aug 10, 2012, at 7:44 PM, Jayson Adams wrote: >> >>> Except Apple itself says it might not make sense to do so. From the 64-bit >>> Transition Guide: >>> >>> https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/indications/indications.html#//apple_ref/doc/uid/TP40001064-CH206-TPXREF101 >> >> That article is wildly out of date. Notice how it emphatically advises you >> *not* to compile your applications as 64-bit only, whereas 64-bit only is >> not only the default nowadays, but is required for all the latest additions >> Apple has made to the language (including, but not limited to, ARC). > > Not everyone uses ARC, or the other recent additions Apple has made to the > language. Yes, but the fact that everything new that Apple adds assumes that you're compiling for 64-bit only really ought to tell you something. >> It also advises that you should include PPC code in your binaries, which >> Xcode doesn't even let you *do* anymore. > > > This is not the first piece of Apple documentation to contain stale info. It > is a leap to conclude that those portions invalidate the rest of the document. However, that's not the only thing that's out of date — the obsolescence is systemic to the entire article, making constant reference to PowerPC, leaving out any mention of recent Apple technologies that require 64-bit, making no reference to any version of OS X later than 10.6, suggesting build settings that are no longer even possible, and having a "Last Modified" date of almost two years ago. Apple once said that it might sometimes make sense to use Carbon instead of Cocoa. Apple once said that Carbon was a first-class peer of Cocoa and was the "basis for all life." Apple says a lot of things. > I'm not trying to argue that you are wrong in your general conclusion about > the fate of 32-bit, because you don't know and I don't know either. What I > am saying, though, is that for all of the 32-bit-the-sky-is-falling, the > first place a 32-bit straggler turns—the 64-bit porting guide—the beast > itself states upfront that you really may not want to make the transition > after all. I've talked to certain people "on the inside" who have also let me know quite clearly that we need to be porting to 64-bit, but even beyond that, Apple just transitioned the whole OS to 64-bit only with Lion last year. Anyone with basic pattern recognition skills should know what to expect based on what's happened the last few times Apple has transitioned the OS to a new architecture. You're setting yourself up for a disaster if you fail to read the writing on the wall. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On 11/08/2012, at 1:02 PM, Charles Srstka wrote: > Apple says a lot of things. I'm still struggling to build for 680x0 you insensitive clod! --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa-dev Digest, Vol 9, Issue 569
On Fri, 10 Aug 2012 13:47:48 -0600 mail...@ericgorr.net wrote: > For a JPG image, I can just use CGImageSourceCopyPropertiesAtIndex to > obtain the various bits of EXIF information from the image. However, > this API does not work with quicktime movie files. > > What similar Cocoa APIs can I use to extact EXIF information from a > Quicktime movie file? Or, if there aren't any Cocoa APIs, what might my > best option be? > > Anyone face a similar issue? Possibly you can use ExifTool, otherwise you have to roll your own. Here's a link that has info on Quicktime tags: http://owl.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thousands separators added to number fields
On Aug 10, 2012, at 4:06 PM, James Merkel wrote: > Ok, I could do it that way also. > > Jim Merkel > > On Aug 10, 2012, at 1:28 PM, Kyle Sluder wrote: > >> On Fri, Aug 10, 2012, at 01:17 PM, James Merkel wrote: As of 10.8, it looks like thousands separators are automatically added to numbers displayed in text boxes. Can this be disabled? In some places it doesn't make sense like in a display of a year. >>> >>> Ok, I see from: >>> https://developer.apple.com/library/mac/#releasenotes/CoreFoundation/CoreFoundation.html >>> that +[NSString localizedStringWithFormat:] which I am using now adds the >>> thousands separators. I don't see a way around this. >> >> Aside from attaching an NSNumberFormatter to the text field? >> >> --Kyle Sluder Using an NSNumberFormatter on the text field is the *correct* way to do this. Then, you can customize the display to whatever you like, and you can be sure it will stay that way even if the implementation of (localized)StringWithFormat: changes. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Aug 10, 2012, at 8:02 PM, Charles Srstka wrote: >> Not everyone uses ARC, or the other recent additions Apple has made to the >> language. > > Yes, but the fact that everything new that Apple adds assumes that you're > compiling for 64-bit only really ought to tell you something. >> Tell me what exactly? That 32-bit is going away in 10.9? That doesn't follow. That 32-bit will get dropped eventually? That was already obvious. What it doesn't say anything about is the timing of the demise of 32-bit support. >> I'm not trying to argue that you are wrong in your general conclusion about >> the fate of 32-bit, because you don't know and I don't know either. What I >> am saying, though, is that for all of the 32-bit-the-sky-is-falling, the >> first place a 32-bit straggler turns—the 64-bit porting guide—the beast >> itself states upfront that you really may not want to make the transition >> after all. > > I've talked to certain people "on the inside" who have also let me know quite > clearly that we need to be porting to 64-bit, but even beyond that, Apple > just transitioned the whole OS to 64-bit only with Lion last year. Anyone > with basic pattern recognition skills should know what to expect based on > what's happened the last few times Apple has transitioned the OS to a new > architecture. You're setting yourself up for a disaster if you fail to read > the writing on the wall. That's all very nice, but it is still the case that Apple's porting guide declares that you might not want to port to 64 bit. I'm glad that Greg chimed in (I was hoping someone from Apple would say something), but that does absolutely nothing for all of the Mac developers not on cocoadev. Best, __jayson Circus Ponies NoteBook - Introducing An App That Boosts Your Productivity at Work or School, So You Get The Grades, Raises and Promotions You Want. www.circusponies.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSOutlineView group item - suppress ugly show/hide "button" ?
In my outline view I return NO for a certain row from the delegate method [outlineView:shouldCollapseItem:], which is also set to be a 'group' item. This does prevent the group item being collapsed correctly, but it still shows that horrible 'show'/'hide' button - it's just that it no longer actually does anything. Is there a way to get rid of this button? I would have thought that if the row couldn't be collapsed the button should be automatically suppressed, but it's not. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 32-bit on 10.8
On Aug 11, 2012, at 12:10 AM, Jayson Adams wrote: > On Aug 10, 2012, at 8:02 PM, Charles Srstka wrote: > >>> Not everyone uses ARC, or the other recent additions Apple has made to the >>> language. >> >> Yes, but the fact that everything new that Apple adds assumes that you're >> compiling for 64-bit only really ought to tell you something. >>> > > Tell me what exactly? That 32-bit is going away in 10.9? That doesn't follow. > That 32-bit will get dropped eventually? That was already obvious. It tells us that Apple is no longer putting effort into 32-bit, which in turn tells us that its days are almost certainly numbered. > What it doesn't say anything about is the timing of the demise of 32-bit > support. Of course we don't know the exact timing, but it's entirely plausible that it could be removed in 10.9 or 10.10, and if you don't want to get a really rude surprise, you should be assuming that that is what will happen. What we can do is make an educated guess on the timing based on past history. OS X first came out in 2001. Apple dropped Classic with the introduction of the Intel Macs in 2006, five years later. Apple switched away from PowerPC to Intel in 2006. Apple dropped support for PowerPC binaries with Lion, in 2011, five years later. Apple discontinued its last 32-bit Mac in 2007. It's now 2012, five years later. Of course, I could be wrong, but given the information we have right now, to assume that 32-bit support will go on indefinitely (or even more than a year or so) is not a very good gamble at this stage, IMO. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSOutlineView group item - suppress ugly show/hide "button" ?
On Aug 10, 2012, at 22:18 , Graham Cox wrote: > In my outline view I return NO for a certain row from the delegate method > [outlineView:shouldCollapseItem:], which is also set to be a 'group' item. > This does prevent the group item being collapsed correctly, but it still > shows that horrible 'show'/'hide' button - it's just that it no longer > actually does anything. I think you want delegate method 'outlineView:shouldShowOutlineCellForItem:'. > Is there a way to get rid of this button? I would have thought that if the > row couldn't be collapsed the button should be automatically suppressed, but > it's not. 1. There's a difference between "shouldn't" [right now] and "can't" [ever]. 2. I believe "shouldn't" prevents collapsing from code as well as the UI, while "can't" just prevents collapsing from the UI. 3. When your outline view isn't a source list, you *might* want to show the disclosure triangle if the need to indicate visually the presence of children outweighs the inability to collapse the children. This might sound a bit more plausible if you consider the possibility of using a custom outline cell that doesn't look like a disclosure triangle. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
