Re: Outline View not retaining objects it uses. Why?
On Jul 20, 2008, at 5:25 AM, Paul Sargent wrote: wasn't really expecting the view to keep a cache at all. I was expecting it to request the item each time it wanted information about it (in which case an returning an autoreleased object seemed reasonable). It may not have been your intention, but you are expecting it to cache your objects. You created a dictionary and returned it to the view and did not maintain ownership of the object yourself. Then, in outlineView:objectValueForTableColumn:byItem:, you retrieved values from that dictionary and you relied on the view to return a reference to that object, and you even stated you thought the view would retain the object. So, effectively, you expected the view to cache it. Aaron ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: large documents with doc based app
True, the usefulness is reduced to being a performance optimization in certain circumstances. On Mar 6, 2008, at 11:53 AM, Alastair Houghton wrote: On 6 Mar 2008, at 16:34, Aaron Burghardt wrote: If you don't mind working with the POSIX APIs (e.g., Unix system calls), there is mmap(). Unlike NData, it lets you specify a "window" onto the file so that you can control how much of your address space is mapped to the file at a given time. That's true, though it's equivalent (in approach) to loading the file in pieces, in that you can only see a small piece of the file's data in memory at any time. Again, it depends on the application domain as to whether using mmap(), [p]read()/[p]write()/NSFileHandle or even fread()/fwrite() will be the most efficient. Also, you'll need to concern yourself with the system page size if you use mmap(), which is easy enough, it's just something you don't normally need to worry about with higher level routines or the non-memory-mapped I/O routines. Kind regards, Alastair. -- http://alastairs-place.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Calculating file size
Others have answered with good suggestions for other APIs, but I will
point out for the record that you can do it in Cocoa, too, because the
file system has a path-based mechanism in which "..namedfork/rsrc" is
appended to the path. For example, in Terminal:
$ ls -li Documents//Example.doc
108 -rw-r--r--@ 1 aburgh aburgh 23552 Apr 27 2006 Documents/
Example.doc
$ ls -li Documents/Example.doc/..namedfork/rsrc
108 -rw-r--r-- 1 aburgh aburgh 286 Apr 27 2006 Documents/
Example.doc/..namedfork/rsrc
Notice that the "inode" is the same (the Catalog Node ID on HFS+), but
size reflects the different forks. You can use this technique from
any program that lets you specify a path, such as command line
utilities, and you can even read and write the contents of the forks
this way. This is documented in the Mac OS X system documentation.
In your case, you would need to construct the path and use
NSFileManager's fileAttributesAtPath to get the attributes for the
resource fork.
Aaron
On Apr 26, 2008, at 9:50 PM, Cocoa Dev wrote:
Hello,
I was wondering what was the best way to calucate folder size with
cocoa? I
was able to do this but it does not include resource forks:
#import
int main() {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *path = [@"/Folder" stringByExpandingTildeInPath];
NSDirectoryEnumerator *e = [[NSFileManager defaultManager]
enumeratorAtPath
:path];
NSString *file;
unsigned long long totalSize = 0;
while ((file = [e nextObject])) {
NSDictionary *attributes = [e fileAttributes];
NSNumber *fileSize = [attributes objectForKey:NSFileSize];
totalSize += [fileSize longLongValue];
}
printf("Total size: %lld\n", totalSize);
[pool release];
}
or from the example in documentation
- (IBAction)calculateSize:(id)sender { NSFileManager *fileManager =
[NSFileManager defaultManager]; NSString *path = @"/Folder";
NSDictionary
*fileAttributes = [fileManager fileAttributesAtPath:path
traverseLink:YES];
if (fileAttributes != nil) { NSNumber *fileSize; if (fileSize =
[fileAttributes objectForKey:NSFileSize]) { NSLog(@"File size: %qi\n",
[fileSize unsignedLongLongValue]); [label setIntValue:[fileSize
unsignedLongLongValue]]; } }
But I was unsure on how to traverse the entire file tree within that
directory, and give the same size results as the finder.
Thanks,
-Mike
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/ajb.lists%40mac.com
This email sent to [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Calculating file size
I dug up some code that might help. This uses a category to replace
NSFileManager's fileAttributesAtPath: traverseLink and provides more
attributes than the standard implementation. With this category
method, you can continue to use the directory enumerator, so your
calculation becomes:
NSNumber *dataSize = [attributes objectForKey:NSFileDataSize];
NSNumber *rsrcSize = [attributes objectForKey:NSFileRsrcSize];
totalSize += [dataSize longLongValue] + [rsrcSize longLongValue];
Not the most efficient, but one approach. I am curious to hear
comments on the code, too. It worked for my needs, but I may have
overlooked some things.
Aaron
NSFileManagerAddtions:
//
// NSFileManagerAdditions.h
//
extern NSString const *NSFileAccessDate;
extern NSString const *NSFileBackupDate;
extern NSString const *NSFileAttributeModificationDate;
extern NSString const *NSFileDataSize;
extern NSString const *NSFileRsrcSize;
extern NSString *NSFileTypePipe;
NSFileManagerAdditions.m:
#import "NSFileManagerAdditions.h"
#include
#include
@implementation NSFileManager (NSFileManagerAdditions)
- (NSDictionary *)fileAttributesAtPath:(NSString *)fullPath
traverseLink:(BOOL)flag
{
OSErr err;
OSStatus status;
FSRef ref;
Boolean isDirectory;
FSCatalogInfo info;
const char *fullPathRepresentation = [fullPath
fileSystemRepresentation];
int statResult;
struct stat statBuf;
if (flag)
statResult = stat( fullPathRepresentation, &statBuf);
else
statResult = lstat( fullPathRepresentation, &statBuf);
if (statResult) return nil;
status = FSPathMakeRef( (const unsigned char*)fullPathRepresentation,
&ref, &isDirectory);
FSPermissionInfo *permissions = (FSPermissionInfo *) &info.permissions;
err = FSGetCatalogInfo( &ref, kFSCatInfoGettableInfo, &info, NULL,
NULL, NULL);
if (err) {
if ( !(err == nsvErr || err == fnfErr) )
NSLog(@"Error getting file attributes: %hd path: %@", err,
fullPath);
return nil;
}
// File type
NSString *fileType = NSFileTypeUnknown;
UInt16 type = statBuf.st_mode & S_IFMT;
if (type == S_IFREG) fileType = NSFileTypeRegular;
else if (type == S_IFDIR) fileType = NSFileTypeDirectory;
else if (type == S_IFLNK) fileType = NSFileTypeSymbolicLink;
else if (type == S_IFIFO) fileType = NSFileTypePipe;
else if (type == S_IFCHR) fileType = NSFileTypeCharacterSpecial;
else if (type == S_IFBLK) fileType = NSFileTypeBlockSpecial;
else if (type == S_IFSOCK)fileType = NSFileTypeSocket;
// Dates
NSTimeInterval creationDateInterval =
(double)info.createDate.lowSeconds;
if (info.createDate.highSeconds) creationDateInterval +=
info.createDate.highSeconds * 4294967296.0;
if (info.createDate.fraction) creationDateInterval +=
info.createDate.fraction / 65536.0;
NSTimeInterval modDateInterval =
(double)info.contentModDate.lowSeconds;
if (info.contentModDate.highSeconds) modDateInterval +=
info.contentModDate.highSeconds * 4294967296.0;
if (info.contentModDate.fraction) modDateInterval +=
info.contentModDate.fraction / 65536.0;
NSTimeInterval accessDateInterval = (double)info.accessDate.lowSeconds;
if (info.accessDate.highSeconds) accessDateInterval +=
info.accessDate.highSeconds * 4294967296.0;
if (info.accessDate.fraction) accessDateInterval +=
info.accessDate.fraction / 65536.0;
NSTimeInterval backupDateInterval = (double)info.backupDate.lowSeconds;
if (info.backupDate.highSeconds) backupDateInterval +=
info.backupDate.highSeconds * 4294967296.0;
if (info.backupDate.fraction) backupDateInterval +=
info.backupDate.fraction / 65536.0;
NSTimeInterval attributeModDateInterval =
(double)info.attributeModDate.lowSeconds;
if (info.attributeModDate.highSeconds) attributeModDateInterval +=
info.attributeModDate.highSeconds * 4294967296.0;
if (info.attributeModDate.fraction) attributeModDateInterval +=
info.attributeModDate.fraction / 65536.0;
// Sizes
NSNumber *dataSize = [NSNumber
numberWithUnsignedLongLong:info.dataLogicalSize];
NSNumber *rsrcSize = [NSNumber
numberWithUnsignedLongLong:info.rsrcLogicalSize];
// HFS Type & Creator
NSNumber *fileHFSType, *fileCreator;
if (isDirectory) {
FileInfo *fileInfo = (FileInfo *) &info.finderInfo;
fileHFSType = [NSNumber
numberWithUnsignedLong:fileInfo->fileType];
fileCreator = [NSNumber
numberWithUnsignedLong:fileInfo->fileCreator];
}
else {
fileHFSType = [NSNumber numberWithUnsignedLong:0];
fileCreator = [NSNumber numberWithUnsignedLong:0];
}
Fwd: Report writer for Cocoa?
Did you search the archives? There is a package that is much closer to what you are asking for then the suggestions so far. I've mentioned it before, but happy to do so again: http://reportwell.com/main.php?siteName=DrawWellTech&lang=us&name=home The reporting engine is called ReportWell, and there is a user app, DrawWell, for designing reports. The user loads the data model, then drag entities and attributes onto the page. If you are using CoreData, they can import a model directly; if not, you can define your data model in an EOModeler-style text format. The user can define criteria for selecting and sorting records, etc. It's probably not as flexible as Crystal Reports, but it's a step in the direction. You can download a trial to try it out. They have data model support for AddressBook and iTunes, too, so you can experiment without building an app. FYI, I have no affiliation with the company. HTH, Aaron Burghardt abu...@mac.com On Jan 16, 2009, at 9:09 AM, Jon C. Munson II wrote: Thanks Gary! I've been a DB developer for many years, albeit on the PC side. Report writing was usually part of the tools, or, something easily found elsewhere in the PC world. Not so easily found on the Mac side though, hence my original question. I know that writing reports is a total *, so I'm looking for a better way - hopefully one that doesn't mean re-inventing the wheel. There is both a personal and developmental time interest involved in finding a tool with which I could work. Products can't sell if they aren't available and any unnecessary delay can be a deal killer! For Chris' benefit: a report writing tool is one that allows a developer/end-user to construct reports using WYSIWYG controls (like the IB widgets), some sort of macro language (from simple sums/page counts, to extensive page formatting), and can either be called from within or externally linked. This is a parallel to IB, though a wee bit more advanced yet specialized. Programs like FileMaker and Microsoft Access are two examples of such things (though they are also capable of quite a bit more). Crystal Reports is also another example. If one isn't familiar with them, Googling them will yield relevant results. Those types of products are easy to find for the PC, but I started running into walls trying to find something similar for the Mac. I should think that if the Mac is to be better positioned in "line-of-business" (as you state it), these tools should be/have been more readily available. However, that doesn't seem to be the case. Doesn't mean there isn't anything out there, just means they're harder to find or highly specialized. Thanks, guys, for all the answers so far - I appreciate it! Peace, Love, and Light, /s/ Jon C. Munson II P.S. Regarding an Access port to the Mac: my personal opinion is that the disk-based technology that FoxPro used which got bundled in MS Access (after MS purchased FoxPro) is the sole reason it isn't ported. I could be quite wrong on that note though since it really isn't all that important to me other than I wish Access were ported over. -Original Message- From: cocoa-dev-bounces+jmunson=his@lists.apple.com [mailto:cocoa-dev-bounces+jmunson=his@lists.apple.com] On Behalf Of Gary L. Wade Sent: Friday, January 16, 2009 2:03 AM To: cocoa-dev@lists.apple.com Subject: Re: Report writer for Cocoa? In defense of the original poster, I understood perfectly what he was asking, and the responses he received showed others did, too. Pretty much everyone who has heard of FileMaker and Microsoft Office, two extremely well-known products each available on the Macintosh for well over a decade, as well as heard of them in the same sentence, has most likely heard comparisons between Access and FileMaker (as well as heard comments about why Microsoft hasn't ported Access to the Mac), and can probably surmise they operate similarly. In case you're still not informed about what a report writer tool is, it's typically a subsystem of a software product or a standalone product that allows an end-user to develop reports to be used in an application. Comments by others on the forum have given suggestions that an end- user might just as effectively develop an HTML template (a technology many people on the list understand and may even have used) that the original poster could utilize to produce such a report, while others have suggested utilizing Interface Builder to design one (a technology that people on the list typically get maligned if they don't use). If you are still confused about what a report writer is, try Google. And, getting back to Microsoft Office, keep in mind that a number of its components, which are line-of-business applications, originated on the Macintosh. On 01/15/2009 6:50 PM, "Chris Hanson" wrote: On Jan 14, 2009, at 12:01 PM, Jon C. Munson II wrote:
Re: NSXMLNode and NSXMLElement
On Jan 20, 2009, at 10:33 PM, Martijn van Exel wrote:
Hi all,
Consider this small bit of (OpenStreetMap) XML:
user='mvexel'
osmxapi:users='mvexel' timestamp='2008-12-11T13:11:41Z'>
I got this (and its peers) in an array of NSXMLNodes using the
nodesForXPath
method on my NSXMLDocument object.
Now I need to get to the attribute KVPs. It seems that I must get the
individual nodes into NSXMLElement objects and then traverse the
array that
the attributes method of NSXMLElement yields. This somehow does not
feel
right. Is there a better way, given this bit of XML inside an
NSXMLNode, to
deserialize the attribute values in the different nodes?
KVC has a slick feature such that you can send valueForKey: or
valueForKeyPath: to an array and you will get back an array containing
the objects returned by sending the message to each member of the
array. In your case, if you send [nodes valueForKey:@"attributes"],
you will get a new array, but each member is now an array attributes
for the corresponding node in the original array. However, there
isn't a way to get the individual attributes using KVC. You could try
to work around this by using a category for NSXMLElement with a custom
valueForUndefinedKey:. For example:
@implementation NSXMLElement (Private)
- (id)valueForUndefinedKey:(NSString *)key
{
return [self attributeForName:key];
}
@end
I ran this in the debugger, where I had an array of two nodes like
your example:
(gdb) po [nodes valueForKey:@"lat"]
(
lat="52.3506393",
lat="52.3506393"
)
Note that the members of the array are NSXMLNode objects of the
attribute kind (movie title???), so you still need to extract the
values, such as:
(gdb) po [nodes valueForKeyPath:@"lat.stringValue"]
(
52.3506393,
52.3506393
)
Some might consider this an abuse of KVC, so I'm curious to hear
opinions...
Cheers,
Aaron Burghardt
abu...@mac.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
