On Sat, Aug 04, 2012 at 08:48:20AM +1000, Graham Cox wrote:
>
> On 04/08/2012, at 6:55 AM, "Gary L. Wade"
> wrote:
>
> > That "color" is actually a pattern. What are you doing that gives you the
> > unexpected result?
>
> I'm expecting it to be a pattern, with a fairly obvious linen texture.
Anyone an idea? Does my own app need to be codesigned for this to work?
Thanks,
- Koen.
> On 03/08/2012, at 11:35 AM, Koen van der Drift wrote:
>
>> After updating to M and Xcode 4.4 I get a crash in the
>> beginSheetModalForWindow part of the showOpenPanel part.
>
>> #1 0x7fff8a9c8
On 4 Aug 2012, at 12:35, Koen van der Drift wrote:
> Anyone an idea? Does my own app need to be codesigned for this to work?
Well any app should really be codesigned with Developer ID these days, though
that's probably not causing the crash. Sign it and see what happens.
___
On 04/08/2012, at 9:35 PM, Koen van der Drift wrote:
> Anyone an idea
Well, does the problem go away if you temporarily remove the QL plugins? If it
does, add them back in one at a time until you find the one causing the issue.
--Graham
___
Coco
On Aug 4, 2012, at 8:35 AM, Mike Abdullah wrote:
> Well any app should really be codesigned with Developer ID these days, though
> that's probably not causing the crash. Sign it and see what happens.
I don't have a paid dev account, so am unable to code sign it. :)
I'll make a test app to see
On Aug 4, 2012, at 8:42 AM, Graham Cox wrote:
> Well, does the problem go away if you temporarily remove the QL plugins? If
> it does, add them back in one at a time until you find the one causing the
> issue.
>
Disabling all plugins (I put them in a different folder) including a
logout/log
On Aug 4, 2012, at 8:55 AM, Koen van der Drift
wrote:
>
> On Aug 4, 2012, at 8:35 AM, Mike Abdullah wrote:
>
>> Well any app should really be codesigned with Developer ID these days,
>> though that's probably not causing the crash. Sign it and see what happens.
>
> I don't have a paid dev
O, just found this:
http://www.openradar.appspot.com/11685851
- Koen.
On Aug 4, 2012, at 9:42 AM, Koen van der Drift
wrote:
>
> On Aug 4, 2012, at 8:55 AM, Koen van der Drift
> wrote:
>
>>
>> On Aug 4, 2012, at 8:35 AM, Mike Abdullah wrote:
>>
>>> Well any app should really be co
On 4 Aug 2012, at 13:55, Koen van der Drift wrote:
>
> On Aug 4, 2012, at 8:35 AM, Mike Abdullah wrote:
>
>> Well any app should really be codesigned with Developer ID these days,
>> though that's probably not causing the crash. Sign it and see what happens.
>
> I don't have a paid dev acco
When our software is running and the Mac goes into Power Nap, our NSTimers
(which are fire-once and set to 3 hour periods) are firing immediately, so
the software does the timer work and installed a new fire-once timer for 3
hours later.
Except that one of course fires immediately and it just keep
On Aug 4, 2012, at 10:08 AM, Mike Abdullah wrote:
> A) Your customers aren't going to be very happy about that
I have no apps in the wild (yet). Of course I plan to do that once I have
something that is ready to release in the MAS. :)
> B) You can still codesign with a self-signed certificat
Code signing and the MAS are distinct. All apps in the MAS are signed. Not all
signed apps are in the MAS.
All apps, MAS or not, should be signed nowadays.
(Sent from my iPhone.)
--
Conrad Shultz
On Aug 4, 2012, at 8:26, Koen van der Drift wrote:
> I have no apps in the wild (yet). Of course
> When our software is running and the Mac goes into Power Nap, our NSTimers
> (which are fire-once and set to 3 hour periods) are firing immediately, so
> the software does the timer work and installed a new fire-once timer for 3
> hours later.
>
> Except that one of course fires immediately and
On Aug 4, 2012, at 9:08 AM, Koen van der Drift
wrote:
> I'll keep digging
Well, the problem is gone. After reading the rdar I mentioned in an earlier
email that the problem was solved by creating a new project, I decided to
remove my project settings, and the xuserdata folder. After a Clean
I am not at all sure about the details but I think your app is receiving some
sort of notification that power sleep is occurring in order to allow it to do
what it needs to do in that situation. My guess is that all timers are caused
to expire because when asleep they will not and then, when wak
I'm working on a scrollable grid view and noticed that its appearance
during scrolling has regressed since installing 10.8.
This grid view loads content in the background and calls
-setNeedsDisplayInRect: (thread-safely) as content becomes available.
With copy-on-scroll enabled, -setNeedsDisplayI
On Aug 4, 2012, at 14:35 , Dave Keck wrote:
> I'm working on a scrollable grid view and noticed that its appearance
> during scrolling has regressed since installing 10.8.
>
> This grid view loads content in the background and calls
> -setNeedsDisplayInRect: (thread-safely) as content becomes av
Hi Quincey,
> For the latter, it seems hardly surprising that the content wouldn't appear
> until you stop scrolling, since by setting the copy-on-scroll flag you've
> promised that the old view contents don't change during scrolling.
The docs don't say one way or another, but on both 10.7 and 10
On Aug 4, 2012, at 4:43 PM, Dave Keck wrote:
> I'm afraid I sent my question before doing my due diligence though, so
> in the interest of the archives: the reason the invalidated regions
> weren't being redrawn during scrolling was because the block that
> calls -setNeedsDisplayInRect: was sched
> I'm unsure of the wisdom of this approach. Presumably the scroll view is
> intentionally blocking the runloop, and thus assuming that the runloop will
> not fire its event sources until after the scrolling is complete. By waking
> up the runloop, you're violating that assumption and could be c
20 matches
Mail list logo
