Hi Alan,
I'm sorry this wasn't better documented in the CFileX_AC class, but the
CFileX_AC class is not supposed to use the fFileSpec field. The CFileX_AC
class is designed to use only the fFileRef field. The reason for this is
the FSSpec struct is being phased out. See technotes tn2022 and tn2078.
In order to provide backwards compatibility, the CFileX_AC was made a
sub-class of CFile_AC. This made it easier to switch between using
CFile_AC and CFileX_AC without affecting the TFile class.
What I would suggest doing is to track down where the fFileSpec field is
still being used and create new CFileX_AC methods which only use the
fFileRef field.
As I wrote previously, there are going to methods that can not be replace
because they take incompatible parameters or return values.
In regards to the change to OSErr TFileBasedDocument::FileChanged(bool
checkType), the call to
err = fFile->GetFileInfo(pb);
should be changed to
OSType fileType
err = fFile->GetFileType(fileType);
which means the following line should be changed to
if (checkType && (pb.fileParam.ioFlFndrInfo.fdType != fFile-
>GetCachedFileType()))
should be changed to
if (checkType && (fileType != fFile->GetCachedFileType()))
Steve
On Fri, Sep 17, 2004, Alan Dail wrote
>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
>
>void CFileX_AC::CreateParentRef(const CFSSpec_AC& theFSSpec)
>
>I added
>
> CFile_AC::Specify(theFSSpec);
>
>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
>
>OSErr CFileX_AC::DeleteCFile()
>OSErr CFileX_AC::GetFinderInfo(FInfo& fndrInfo, FXInfo& itsFXInfo,
>bool& isDirectory) const
>
>I added a test for Exists, and return fnfErr if the file doesn't exist.
>
>And in
>
>bool CFileX_AC::IsSameFile(const CFileX_AC* aFile)
>
>I changed
>
> if (aFile->Exists())
>
>to
>
> if (Exists() && aFile->Exists())
>
>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
>
>OSErr TFileBasedDocument::FileChanged(bool checkType)
>
>I added a test
>
> if (checkType)
>
>before the call to
>
> err = fFile->GetFileInfo(pb);
>
>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
