Hello Guys,
Is there any way I can send multiple files via Bluetooth transfer using
GameKit?
I have already done the single
file transfer but how about if I send multiple files without sacrificing speed?
Can I do it synchronously? I am new to this so maybe somebody can point me to
the right di
I’m surprised nobody else mentioned this.
The Java bridge isn’t supported and you can no longer write Cocoa apps in Java.
So you’re much better off learning Obj-C or going fully Java. Or even Ruby
Apple won’t even be shipping Java with the OS in the future (there was an
announcement about this
On Jan 19, 2011, at 8:19 PM, Graham Cox wrote:
> On 20/01/2011, at 12:14 PM, Eric Gorr wrote:
>
>> The table is also owned by the the scrolling view and therefore the window
>> and would not be deallocated here...it will stick around long after the
>> controller is deallocated.
>
> You're righ
On 20/01/2011, at 12:14 PM, Eric Gorr wrote:
> However, simply setting the the datasource and delegate to nil works as well
> and is a better solution.
It is also the correct solution.
> The table is also owned by the the scrolling view and therefore the window
> and would not be deallocated
The reason was that removing the table columns from the table prevented the
crash from happening.
However, simply setting the the datasource and delegate to nil works as well
and is a better solution.
Without any table columns, even though the table might have been marked as
dirty, neither the
Yes, I know, I should use FSCopyObjectAsync().
Anyway, my mistake, I copied the file twice, so copyItemAtPath took double
time. Now I fixed my code and copyItemAtPath takes almost the same time as
the Finder takes. Cool.
Regards
-- Leonardo
> Da: Mike Abdullah
> Data: Wed, 19 Jan 2011 23:15:13
Why not have the Finder do the job?
You can use AppleEvents to send a duplicate message to the Finder;
you can do it sync (kAEWaitReply) or async (kAENoReply).
Behaviour and performance will be the same as using the Finder,
including proper update of .DS_Store files.
Am 20.01.2011 um 00:49
On Jan 19, 2011, at 3:21 PM, Corbin Dunn wrote:
>
> In general, it is good practice in your apps to set your delegate and
> datasource to nil. Who is to say something might cause a draw to happen,
> which would then message your (now dealloced) delegate? Ideally, NSTableView
> shouldn't messa
On 20/01/2011, at 11:28 AM, Corbin Dunn wrote:
> for ( column in tableColumns )
> {
> [table removeTableColumn:column];
> }
>
> [table release];
Since the table owns its columns, why not just release the table - if it gets
deallocated the columns wi
Hi eric,
As I mentioned earlier, it is good practice to set your delegate/ds to nil,
since people inadvertently don't realize when they tell the table to redraw,
and are
surprised when they get the delegate messages after they are deallocd. I looked
at your app, and I can point out the problem
Both FSCopyObjectAsync and FSCopyObjectSync leak memory in Mac OS X
10.6.x, even up to 10.6.6; the async form leaks even more than the sync
form. Apple has verified this both in my bug, rdar://8734968 (opened
against 10.6.5) and another unspecified one opened earlier in 2010. I've
verified both s
On Jan 19, 2011, at 12:28 PM, Eric Gorr wrote:
> I believe my situation is a bit different and my stack trace is not the same.
>
> What I see in my stack trace is:
>
> #00x978f8edb in objc_msgSend
> #10x00516f60 in ??
> #20x98fbb3ea in -[NSTableView preparedCellAtColumn:row:]
> #3
On Jan 19, 2011, at 12:15 PM, Lee Ann Rucker wrote:
> Sounds like a radar bug I filed a while back. It was marked as a duplicate of
> 6728942
>
>> From my bug:
>
> Snow leopard throws a doesNotRecognizeSelector in NSTableView.
>
> Regression:
> Works on Leopard.
>
> 6 com.apple.ExceptionHa
Well you shouldn't be using this synchronous API for long-running copy
operations, since it can't be cancelled or give progress.
Instead use FSCopyObjectAsync().
On 19 Jan 2011, at 21:42, Leonardo wrote:
> Hi,
> I have checked, the Finder, takes only 7 seconds to copy a 500MB dmg file.
> The co
Hi,
I have checked, the Finder, takes only 7 seconds to copy a 500MB dmg file.
The copyItemAtPath API takes 18 seconds to copy the same file.
Why? Is a way to make copyItemAtPath run at the same Finder speed?
If not, which API should I use to get the same performance?
I use:
[[NSFileManager de
I believe my situation is a bit different and my stack trace is not the same.
What I see in my stack trace is:
#0 0x978f8edb in objc_msgSend
#1 0x00516f60 in ??
#2 0x98fbb3ea in -[NSTableView preparedCellAtColumn:row:]
#3 0x98fd58bc in -[NSTableView _drawContentsAtRow:column:w
Sounds like a radar bug I filed a while back. It was marked as a duplicate of
6728942
>From my bug:
Snow leopard throws a doesNotRecognizeSelector in NSTableView.
Regression:
Works on Leopard.
6 com.apple.ExceptionHandling 0x976b1ebb -[NSExceptionHandler
_handleException:mask:] + 33
If anyone is interested, this odd crash turns out to be the same issue I was
struggling with in the 'Window Controllers & Window Deallocation' (
http://bit.ly/gzd1LI ) thread.
If in the dealloc method of the table controller, I set the table's dataSource
and delegate to nil, it will no longer c
18 matches
Mail list logo
