Ok - I fixed most of this. The one thing I didn't fix yet was have the
save dialog allow more than 31 characters in a file name. But the rest
of this turned out to be a pretty straightforward fix. I traced many
of the problems I was having to the same thing - the CFileX_AC class is
a subclass of TFile_AC, but does not set the fFileSpec field of
TFile_AC. Because of this, many CFile_AC functions have been
overridden to throw an exception, functions like SetCatInfo,
GetCatInfo, etc.
What I did was the following
in
void CFileX_AC::Specify(const CFSRef_AC& theFile)
I added the following
CFSSpec_AC theFileSpec(theFile.GetFSSpec());
CreateParentRef(theFileSpec);
in
This both ensures the ParentRef is initialized and ensures the FSSpec
is initialized. The parentref is important because that gets used if
you delete and then create a TFile. There is a potential hole here,
though - the recreated file will be limited to a 31 character filename.
And then removing the overrides for the functions that required the
FSSpec, most of the problems I was having went away. I did have to do
a couple of minor bug fixes that I discovered while working on this.
In both of these functions
Finally, in UFileDocument.cpp, I made the following changes, the first
of which which may no longer be needed but which does eliminate an
unneeded call. In
The other change is a bug fix that should be in all builds. In
void TFileBasedDocument::SaveOver()
I added a call to
fFile->CloseFile();
before setting the permissions to read/write. Otherwise a file that
has been kept open will not be writable.
After all of these changes, with the switch qUseCFileX_AC turned on, I
can open files with long filenames, edit them, and save the file and
the file correctly saves retaining the long filename in the process.
Setting the fFileSpec field of CFile_AC makes much of the transition to
FSRefs transparent.
Should I check these changes in?
Alan
On Sep 14, 2004, at 1:38 AM, Steve Graesser wrote:
Hi Alan,
I'm the one who wrote the CFileX_AC class. As you have noted below, the
class was written to support the use of FSRefs. However, due to time
constraints, I was unable to change the TFileBasedDocument and
TApplication classes to be fully compatible with the CFileX_AC
changes. I
can give you some ideas on what needs to be fixed for your questions.
On Mon, Sep 13, 2004, Alan Dail wrote
I noticed that TFile now has the qUseCFileX_AC to FSRef based
CFileX_AC
class. I tried turning on this switch in MacApp in an attempt to
support long filenames in my app. Initially after making a couple of
mods to my code to be compatible with the new switch, things looked
good. Files opened that had long filenames displayed just fine in the
document title bar. Before setting the switch, the names were mangled
and the mangled name would get used when the file was saved. However,
I ran into a couple of problems when I tried to use my app after the
switch.
1 - save does not work for save via temp. It appears the temporary
TFile* is created incorrectly.
The SaveViaTemp method creates a new TFile (this should be ok)
The SaveInPlace method probably calls the SaveTo method.
The SaveTo method is probably where the problems lie. I would look at
the
calls to the GetSaveInfo and SetCatInfo methods. The GetSaveInfo calls
GetCatInfo which is not supported by the CFileX_AC class. You should
see
a warning message that states that GetCatInfo and SetCatInfo are not
supported.
I would add another GetSaveInfo method for use with the CFileX_AC
class.
The GetSaveInfo method would call GetCatalogInfo and store the data in
a
FSCatalogInfo struct. The call to SetCatInfo would also need to be
changed to SetCatalogInfo.
2 - I switched to save in place and after doing so, save works, but it
truncates any long filenames to 31 characters.
My guess is an FSSpec is used to specify the file. A FSSpec file name
is
limited to 31 characters.
3 - The save dialog for save as limits you to 31 characters in the
filenames you type
The save dialog (NavPutFile) returns a FSSpec. A FSSpec file name is
limited to 31 characters.
A FSRef compatible solution would be to re-write TFileBasedDocument:
:RequestFileNameByNavSvcs to use NavCreatePutFileDialog, NavDialogRun
and
NavDialogDispose instead of NavPutFile. Also, the NavGetFile function
calls would need to be re-written as well.
4 - my estimated block size for my document comes back wrong even
though it is right with qUseCFileX_AC set to 0. This may be an error
in my app, though, I haven't researched it yet.
My guess is the problem involves the calls to GetFreeBlocks,
GetBlockSize
and GetPhysicalSize. Those are the only methods that are used by the
CheckDiskSpace and DebugCheckEstimate methods which have a CFile_AC and
CFileX_AC implementation.
Has anyone else tried the qUseCFileX_AC switch for adding long
filename
support? I haven't dug too deep into the MacApp sources for these
issues. I'm guessing the 2nd problem has a simple solution, but am
not
sure about the first and 3rd. and the 4th may be something wrong in my
code, I'm not sure yet.
Steve Graesser White Lab Consulting LLC
PGP Fingerprint: 8AA4 6514 A87C FD26 A135 DBA0 F8AF 3E1B 41C5 4B5C
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macapp-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
