Re: how to prevent TableView update on key repeat?
On May 3, 2012, at 19:38 , Graham Cox wrote: > You probably should do this as your last line: > > [self performSelector: withObject:nil afterDelay:[NSEvent > keyRepeatInterval] + 0.1]; > > because the key repeat rate is set by the user in the "Keyboard" system > preferences and can change. I see your logic here, but I think this isn't the optimal answer. On the one hand, you want the delay to be as short as possible. Let's say the keyboard repeat interval is 0.83 as Marc reported. With the above delay, the user might have to wait more than 0.93 secs to see the detail view *start* to update, even after a single isolated keypress. From this point of view, the best delay is the shortest. From this point of view, the best delay is 0. On the other hand, you want the delay to be as long as possible. We're dealing with a situation where the time to update the detail view is greater than the repeat interval. Let's say it takes 1.0 secs to do the update. Once the update (the performed method) starts to execute, then even the next keystroke is delayed for the full 1.0 secs, not just subsequent detail updates. This is a kind of freeze from the user's point of view, hence the pressure to defer it as long as possible. [Note: The other scenario to consider here is that the user might mash an arrow key rather than hold it down. The key repeat interval seems irrelevant in this case, another reason not to use it.] Statistically (that is, over a wide variety of key presses), the time-alignment of keypresses and updates would [I think] be randomly distributed, so the *expected* completion time after the last keypress in a series would be the total of: -- half of the 1.0 sec freeze, or 0.5 secs, resulting from intermediate non-canceled updates occurring at "random" times -- the performSelector delay, which must happen before the last update -- the full 1.0 sec freeze of the last update. That's a really long time -- 1.5 secs with no delay, or 2.33 secs with your suggested repeat-interval-based delay. To summarize, therefore, the expected update completion time would be: -- after a single keystroke, 'performSelector delay plus update freeze time' -- after multiple keystrokes (whether repeated or mashed singly), 'performSelector delay plus 1.5 * update freeze time' Since I can't control the update freeze time, I'd *really* want to set the performSelector delay to 0 -- certainly not 0.93. My thinking about the delay of 0.1 secs (instead of 0) was do with trying to ensure that the detail update didn't start if another event was about to happen that might get delayed due to the update freeze starting first. On second thoughts, though, I think my reasoning was flawed, so I'm back to thinking a delay of 0 is the best solution. ___ 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: Core Data: Setting attribute of deleted object causes it to remain in store
On 3 May 2012, at 7:19 PM, Jerry Krinock wrote: > I've seen the nilling of attributes happen before, upon re-inserting a > deleted object [1]. This behavior is obviously related, but different. If > anyone can think of a good reason for this behavior, it would be interesting > to read. By the database rules, the record that backs a managed object may be deleted, but by the memory-management rules, the managed object that wraps the record must remain until it is dealloced. Core Data represents this state by turning the managed object into an irrecoverable fault. — 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 to prevent TableView update on key repeat?
El may 4, 2012, a las 3:19 a.m., Quincey Morris escribió:
> On May 3, 2012, at 19:38 , Graham Cox wrote:
>
>> You probably should do this as your last line:
>>
>> [self performSelector: withObject:nil afterDelay:[NSEvent
>> keyRepeatInterval] + 0.1];
>>
>> because the key repeat rate is set by the user in the "Keyboard" system
>> preferences and can change.
>
> I see your logic here, but I think this isn't the optimal answer.
>
> On the one hand, you want the delay to be as short as possible. Let's say the
> keyboard repeat interval is 0.83 as Marc reported. With the above delay, the
> user might have to wait more than 0.93 secs to see the detail view *start* to
> update, even after a single isolated keypress. From this point of view, the
> best delay is the shortest. From this point of view, the best delay is 0.
>
> On the other hand, you want the delay to be as long as possible. We're
> dealing with a situation where the time to update the detail view is greater
> than the repeat interval. Let's say it takes 1.0 secs to do the update. Once
> the update (the performed method) starts to execute, then even the next
> keystroke is delayed for the full 1.0 secs, not just subsequent detail
> updates. This is a kind of freeze from the user's point of view, hence the
> pressure to defer it as long as possible.
>
> [Note: The other scenario to consider here is that the user might mash an
> arrow key rather than hold it down. The key repeat interval seems irrelevant
> in this case, another reason not to use it.]
>
> Statistically (that is, over a wide variety of key presses), the
> time-alignment of keypresses and updates would [I think] be randomly
> distributed, so the *expected* completion time after the last keypress in a
> series would be the total of:
>
> -- half of the 1.0 sec freeze, or 0.5 secs, resulting from intermediate
> non-canceled updates occurring at "random" times
> -- the performSelector delay, which must happen before the last update
> -- the full 1.0 sec freeze of the last update.
>
> That's a really long time -- 1.5 secs with no delay, or 2.33 secs with your
> suggested repeat-interval-based delay.
>
> To summarize, therefore, the expected update completion time would be:
>
> -- after a single keystroke, 'performSelector delay plus update freeze time'
>
> -- after multiple keystrokes (whether repeated or mashed singly),
> 'performSelector delay plus 1.5 * update freeze time'
>
> Since I can't control the update freeze time, I'd *really* want to set the
> performSelector delay to 0 -- certainly not 0.93.
>
>
> My thinking about the delay of 0.1 secs (instead of 0) was do with trying to
> ensure that the detail update didn't start if another event was about to
> happen that might get delayed due to the update freeze starting first. On
> second thoughts, though, I think my reasoning was flawed, so I'm back to
> thinking a delay of 0 is the best solution.
When I set the delay to zero, there is no delay. My selector is called
immediately as if I didn't change anything. It seems that the selector must be
set to fire just after the key repeat because tableViewSelectionDidChange: is
going to be called at the keyRepeatInterval. By setting the interval to
[NSEvent keyRepeatInterval] + 0.01; everything works fabulously if your key
repeat rate is high because the selection change won't fire until the interval
no matter what. When the repeat interval is very slow, the selection changes
very slowly no matter how it changes (click, type to select, repeatedly hitting
up/down).
I added this to determine what the delay interval should be
NSTimeInterval delayInterval = 0.0;
NSEvent *event = [NSApp currentEvent];
if(event != nil && [event type] == NSKeyDown && [event isARepeat])
{
delayInterval = [NSEvent keyRepeatInterval] + 0.01;
}
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(selectionDidChange) object:nil];
[self performSelector:@selector(selectionDidChange) withObject:nil
afterDelay:delayInterval];
The objection to that was that I don't know what the current event is. If that
is true, when [NSApp currentEvent] is useful? It seems that the current event
will be the one that caused tableViewSelectionDidChange: to be called.
In my limited testing with different key repeat rates, everything works fine.
I'm using a standard NSTableView. If my key repeat is very slow, then selection
change is slow and updates wait until I lift the key. Type to select works
fine. Clicking works fine. Repeatedly hitting up/down works fine. I don't see
any problem with this but I've already not seen things so thoughts on this
solution are appreciated.
Thanks again
Marc
___
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
Re: how to prevent TableView update on key repeat?
On May 4, 2012, at 08:25 , Marc Respass wrote:
> When I set the delay to zero, there is no delay. My selector is called
> immediately as if I didn't change anything.
Not exactly. Consider what happens when you mash the arrow key. Thus, there
might be multiple (normal) key events queued. The selector won't actually be
performed until they're *all* dequeued from the main event queue (because,
presumably, any queued perform is further down the queue).
At that point, no subsequent key events can be dequeued until the update has
run. IOW, there's a slight hitch every time the event queue empties of key
events. That's *much* better than the original (non-performSelector) approach,
because at least some of the updates are suppressed.
So a delay of 0 helps key-mashers (and doesn't penalize other methods of
selection change, such a click). It doesn't help the key-repeat case very much.
Trying to solve the repeat case like this is a neat idea:
> I added this to determine what the delay interval should be
>
> NSTimeInterval delayInterval = 0.0;
> NSEvent *event = [NSApp currentEvent];
>
> if(event != nil && [event type] == NSKeyDown && [event isARepeat])
> {
> delayInterval = [NSEvent keyRepeatInterval] + 0.01;
> }
>
> [NSObject cancelPreviousPerformRequestsWithTarget:self
> selector:@selector(selectionDidChange) object:nil];
> [self performSelector:@selector(selectionDidChange) withObject:nil
> afterDelay:delayInterval];
but it still has the drawback that there's an additional '[NSEvent
keyRepeatInterval] + 0.01 + timeToUpdateDetailView' delay after the last one,
during the latter part of which the user is frozen out of the UI.
Let's say, though, that you wanted to pursue the approach that the above code
represents. In that case, I probably *would* subclass the table view, and
override keyDown: and keyUp:. You could simply set a flag at key down and clear
it at key up, and use that information to control the way the performSelectors
are timed. (It's still something of a hack, but at least it keeps the NSEvent
details out of your selectionDidChange code.)
However, once you get to this level of complexity, then it's probably
worthwhile to spend your effort on moving the time-consuming part of the update
process into a background thread instead. That would solve the problem for
realz, letting keys repeat at their proper rate and letting updates happen as
soon as they're ready, without freezes and artificial delays.
> The objection to that was that I don't know what the current event is. If
> that is true, when [NSApp currentEvent] is useful? It seems that the current
> event will be the one that caused tableViewSelectionDidChange: to be called.
It's useful when you know that you dequeued the last event and that you haven't
dequeued another one since. In this case, you know that the table view dequeued
a key event, but you don't know what it did after that. It *might* have created
a background async GCD block to do the selection pre-processing, then executed
a completion handler on the main thread to send the notification that triggered
your method. Or, it *might* have looked ahead in the main event queue and
dequeued some event.
Even if you determined empirically that [NSApp currentEvent] gives you the key
event, you can't be sure it will continue to do so in future frameworks
versions.
___
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: No validation with a bound NSTableView and custom NSFormatter
> On May 3, 2012, at 6:11 PM, Ben Kennedy wrote: > >> Separate from the above, I also have a new performance problem. The loop in >> which I do my cascading updates executes inordinately slowly; simply >> assigning new values for two properties takes about 0.45 seconds when >> iterating a data set of a mere 135 objects. It used to be instantaneous >> before bindings came into the picture. I suspect that all of the KVO >> overhead is to blame (a quick peek in Instruments supports this). In defence of KVO, I must rescind this hasty conclusion. The real problem occurred to me in the shower this morning: the array controller was constantly re-sorting the data after every property change, by virtue of its sortDescriptors. By temporarily clearing the sortDescriptors before the loop (and restoring afterwards), performance is golden again. I should have realized this earlier. On 03 May 2012, at 8:04 pm, Keary Suska wrote: > Don't get me wrong, I think bindings are great, and I use them extensively in > almost everything I do. But it seems to me they are really built for > straightforward usage and if you need to stretch them they tend to break. Not > to mention that they are completely opaque and are a bear to debug. Having not used bindings much (despite their availability for many years), I appreciate your experience and perspective, because it's in line with the impressions I've nonetheless been forming. (Cocoa bindings sort of remind me of BOOPSI from the Amiga days, akin to a well-intentioned but awkward and gangly teenager.) The motivation for moving my delegate-based table to a bound data source was in part to simplify the code needed for sorting and filtering in the UI -- but I was a bit naïve about the additional work implied by some of the trade-offs. thanks, b -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca ___ 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 to prevent TableView update on key repeat?
El may 4, 2012, a las 1:02 p.m., Quincey Morris escribió:
> On May 4, 2012, at 08:25 , Marc Respass wrote:
>
>> When I set the delay to zero, there is no delay. My selector is called
>> immediately as if I didn't change anything.
>
>
> Not exactly. Consider what happens when you mash the arrow key. Thus, there
> might be multiple (normal) key events queued. The selector won't actually be
> performed until they're *all* dequeued from the main event queue (because,
> presumably, any queued perform is further down the queue).
>
> At that point, no subsequent key events can be dequeued until the update has
> run. IOW, there's a slight hitch every time the event queue empties of key
> events. That's *much* better than the original (non-performSelector)
> approach, because at least some of the updates are suppressed.
>
> So a delay of 0 helps key-mashers (and doesn't penalize other methods of
> selection change, such a click). It doesn't help the key-repeat case very
> much. Trying to solve the repeat case like this is a neat idea:
>
>> I added this to determine what the delay interval should be
>>
>> NSTimeInterval delayInterval = 0.0;
>> NSEvent *event = [NSApp currentEvent];
>>
>> if(event != nil && [event type] == NSKeyDown && [event isARepeat])
>> {
>> delayInterval = [NSEvent keyRepeatInterval] + 0.01;
>> }
>>
>> [NSObject cancelPreviousPerformRequestsWithTarget:self
>> selector:@selector(selectionDidChange) object:nil];
>> [self performSelector:@selector(selectionDidChange) withObject:nil
>> afterDelay:delayInterval];
>
> but it still has the drawback that there's an additional '[NSEvent
> keyRepeatInterval] + 0.01 + timeToUpdateDetailView' delay after the last one,
> during the latter part of which the user is frozen out of the UI.
>
> Let's say, though, that you wanted to pursue the approach that the above code
> represents. In that case, I probably *would* subclass the table view, and
> override keyDown: and keyUp:. You could simply set a flag at key down and
> clear it at key up, and use that information to control the way the
> performSelectors are timed. (It's still something of a hack, but at least it
> keeps the NSEvent details out of your selectionDidChange code.)
>
> However, once you get to this level of complexity, then it's probably
> worthwhile to spend your effort on moving the time-consuming part of the
> update process into a background thread instead. That would solve the problem
> for realz, letting keys repeat at their proper rate and letting updates
> happen as soon as they're ready, without freezes and artificial delays.
>
>> The objection to that was that I don't know what the current event is. If
>> that is true, when [NSApp currentEvent] is useful? It seems that the current
>> event will be the one that caused tableViewSelectionDidChange: to be called.
>
> It's useful when you know that you dequeued the last event and that you
> haven't dequeued another one since. In this case, you know that the table
> view dequeued a key event, but you don't know what it did after that. It
> *might* have created a background async GCD block to do the selection
> pre-processing, then executed a completion handler on the main thread to send
> the notification that triggered your method. Or, it *might* have looked ahead
> in the main event queue and dequeued some event.
>
> Even if you determined empirically that [NSApp currentEvent] gives you the
> key event, you can't be sure it will continue to do so in future frameworks
> versions.
Thanks again. Ideally, the update method would just be fast but it is now as
fast as it is going to get. The problem that I want to solve is delay update
during key-repeat (which is something that Mail does very well).
I subclassed NSTableView adding BOOL isRepeating. I set isRepeating = YES in
keyDown: if isRepeating == NO && event isARepeat and isRepeating = NO in
keyUp:. I replaced my tableViewSelectionDidChange: with the following.
CMTableView *tableview = [notification object];
NSTimeInterval delayInterval = 0.0;
if(tableview.isRepeating)
{
delayInterval = [NSEvent keyRepeatInterval] + 0.01;
}
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(selectionDidChange) object:nil];
[self performSelector:@selector(selectionDidChange) withObject:nil
afterDelay:delayInterval];
If not repeating, update right now. If repeating then delay. Now, the delay is
in affect if repeating so tying it to keyRepeatInterval makes sense. Otherwise,
the table updates right away. This is working great. What do you think?
Thanks again for the help. It's been really valuable. Events and Run Loop are
weak areas for me so I'm learning a lot here.
Marc
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contac
Re: how to prevent TableView update on key repeat?
On May 4, 2012, at 12:39 , Marc Respass wrote:
> This is working great. What do you think?
"Working great" sounds great!
If you want to go the extra mile for your users, you could try something like
this:
CMTableView *tableview = [notification object];
NSTimeInterval delayInterval = 0.0;
if(tableview.isRepeating)
{
[detailView setEnabled: NO]; // or something that "dims" the detail
view(s)
[spinningProgressIndicatorOnTopOfDetailView: setHidden: NO];
[spinningProgressIndicatorOnTopOfDetailView: startAnimating];
delayInterval = [NSEvent keyRepeatInterval] + 0.01;
}
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(selectionDidChange) object:nil];
[self performSelector:@selector(selectionDidChange) withObject:nil
afterDelay:delayInterval];
and add something like the following to the *end* of your performed method:
[detailView setEnabled: YES];
[spinningProgressIndicatorOnTopOfDetailView: setHidden: YES];
[spinningProgressIndicatorOnTopOfDetailView: stopAnimating];
(Note that there's no need to condition this last on how you got there. It's
always safe to do.)
At least, you could try it and see if they like it.
___
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
Strange issue in stroking a bezier path
Xcode 4.3.2, Lion 10.7.3,
Apple 30" Cinema Display, Samsung SyncMaster 950p
Consider the following simple drawRect to demonstrate the issue
- (void)drawRect:(NSRect)dirtyRect
{
// Drawing code here.
NSRect bounds = [self bounds];
NSBezierPath *path = [NSBezierPath bezierPathWithRect:bounds];
[path stroke];
}
In the specific case of the Cinema Display having a resolution setting of 1280
x 800
the rectangle is not fully drawn every time. The top and right edges are
missing.
But sometimes they do draw. It seems quite arbitrary.
I have tested this with all other resolutions on the Cinema Display under both
standard
and HiDPI and also on the Samsung CRT. They all work just fine. Even the
Samsung at 1280 x 800.
(I have tried things such as NSIntegralRect but nothing works except to change
the resolution)
Why would this occur and only at that resolution and only on the Cinema Display?
Any ideas for tracking it down, or working around it, gratefully received.
TIA and respect….
Peter
___
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: Strange issue in stroking a bezier path
I am having a similar problem but not with an Apple display and at a resolution
of 1920 x 1080 and not with stroking a path. My problem occurs with textfield
rendering when the fields abut one another. Sometimes the edges do not line up
even when they are configured to do so in IB.
(I'm staying in Snow Leopard using Xcode 3; I hate Lion and it's move away from
the mouse. I suffer from familial tremors and have a tough enough time with the
mouse and find the gesture pad impossible. I will stay on Snow Leopard until I
am forced to a new machine. Needless to say I program as a hobby - just for my
own enjoyment)
At any rate I believe the problem is with the graphics chip and its ability to
consistently activate pixels in close proximity when not drawn with a single
stroke. I know of no solution except to adjust the placement of your drawn
objects to minimize the effect.
Changing monitors or resolution, I think, will not address the problem. A
different, perhaps "better" graphics card might.
On May 4, 2012, at 9:19 PM, Peter Teeson wrote:
> Xcode 4.3.2, Lion 10.7.3,
> Apple 30" Cinema Display, Samsung SyncMaster 950p
>
> Consider the following simple drawRect to demonstrate the issue
>
> - (void)drawRect:(NSRect)dirtyRect
> {
>// Drawing code here.
>NSRect bounds = [self bounds];
>NSBezierPath *path = [NSBezierPath bezierPathWithRect:bounds];
>[path stroke];
> }
>
> In the specific case of the Cinema Display having a resolution setting of
> 1280 x 800
> the rectangle is not fully drawn every time. The top and right edges are
> missing.
> But sometimes they do draw. It seems quite arbitrary.
>
> I have tested this with all other resolutions on the Cinema Display under
> both standard
> and HiDPI and also on the Samsung CRT. They all work just fine. Even the
> Samsung at 1280 x 800.
>
> (I have tried things such as NSIntegralRect but nothing works except to
> change the resolution)
>
> Why would this occur and only at that resolution and only on the Cinema
> Display?
>
> Any ideas for tracking it down, or working around it, gratefully received.
>
> TIA and respect….
>
> Peter
> ___
>
> 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/3tothe4th%40comcast.net
>
> This email sent to 3tothe...@comcast.net
Charlie Dickman
3tothe...@comcast.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Strange issue in stroking a bezier path
On 2012-05-04, at 10:22 PM, Charlie Dickman wrote:
> (I'm staying in Snow Leopard using Xcode 3; I hate Lion and it's move away
> from the mouse.
I don't understand. I only use a mouse on my Mac Pro. No Tablet. (I don't do
iDevice apps)
So I don't see any of the bouncy castle scroll things that some people abhor.
> Changing monitors or resolution, I think, will not address the problem. A
> different, perhaps "better" graphics card might.
It's an NVIDIA GeForce GT 120 card provided by Apple when I bought the MacPro
and Display.
Thanks for your thoughts but, with respect, I think we are dealing with
different issues.
> On May 4, 2012, at 9:19 PM, Peter Teeson wrote:
>> Xcode 4.3.2, Lion 10.7.3,
>> Apple 30" Cinema Display, Samsung SyncMaster 950p
>>
>> Consider the following simple drawRect to demonstrate the issue
>>
>> - (void)drawRect:(NSRect)dirtyRect
>> {
>> // Drawing code here.
>> NSRect bounds = [self bounds];
>> NSBezierPath *path = [NSBezierPath bezierPathWithRect:bounds];
>> [path stroke];
>> }
>>
>> In the specific case of the Cinema Display having a resolution setting of
>> 1280 x 800
>> the rectangle is not fully drawn every time. The top and right edges are
>> missing.
>> But sometimes they do draw. It seems quite arbitrary.
>>
>> I have tested this with all other resolutions on the Cinema Display under
>> both standard
>> and HiDPI and also on the Samsung CRT. They all work just fine. Even the
>> Samsung at 1280 x 800.
>>
>> (I have tried things such as NSIntegralRect but nothing works except to
>> change the resolution)
>>
>> Why would this occur and only at that resolution and only on the Cinema
>> Display?
>>
>> Any ideas for tracking it down, or working around it, gratefully received.
>>
>> TIA and respect….
>>
>> Peter
>> ___
>>
>> 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/3tothe4th%40comcast.net
>>
>> This email sent to 3tothe...@comcast.net
>
> Charlie Dickman
> 3tothe...@comcast.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Strange issue in stroking a bezier path
On May 4, 2012, at 8:19 PM, Peter Teeson wrote:
> - (void)drawRect:(NSRect)dirtyRect
> {
>// Drawing code here.
>NSRect bounds = [self bounds];
>NSBezierPath *path = [NSBezierPath bezierPathWithRect:bounds];
>[path stroke];
> }
>
> In the specific case of the Cinema Display having a resolution setting of
> 1280 x 800
> the rectangle is not fully drawn every time. The top and right edges are
> missing.
Well, I don't think you're drawing what you think you are. The bounds rect is
outside of the view. It's the exterior boundary of the view. Now, when you
stroke it, assuming you haven't changed the default line width of NSBezierPath,
the stroke will be 1 point wide, half a point inside the view and half outside.
This may involve anti-aliasing or, under HiDPI, perhaps a one-pixel wide line
since that's half a point.
It's probably up to the graphics driver to decide precisely how to render that
half-point-wide line.
Generally, if you actually want to draw just within the view's bounds, you
would inset the rectangle by half the line width.
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: Are there any way to update NSPanel content during dragging the panel ?
> My custom NSView in a NSPanel shows some information depends on panel's
> position to the main window. I want to update it during dragging the panel.
> I try [self setNeedsDisplay:YES] in mouseDragged: delegate, drawRect: called
> many times during dragging, but it will not appear on screen until mouse stop.
> I test it on Mac OS X 10.7 and want to support 10.6.
Found the solution. Simply, drag the panel by my self. Following code in the
custom view do this.
- (void)mouseDown:(NSEvent*)event {
offset = [event locationInWindow];
}
- (void)mouseDragged:(NSEvent *)event {
NSPoint location = [NSEvent mouseLocation];
location.x -= offset;
location.y -= offset;
[[self window] setFrameOrigin:location];
[self setNeedsDisplay:YES];
}
Thanks.
Yoshiaki Katayanagi
http://www.jizoh.jp/english.html
___
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
