O$ - FileOps strangeness...

[David Walton]

Reg and Kelly,

Thanks. I got it figured out. This takes a bit of the mystery out of  
it. Don't usually work in windows so I hadn't been seeing the issues.  
Seems that if I want my products to be successful, I'm going to have  
to play nice with those users too...

Funny how over all these years, I've never noticed a fileops object -  
only the fileops commands. I really wish there was better  
documentation about these - and that it wasn't so "all over the place".

Cheers!

David

On Apr 21, 2009, at 3:23 AM, Reg Paling wrote:

> Hi David,
>
> I once spent some time fiddling around in exactly the same situation  
> as you, and realised it's better to just use $readfile and $writefile.
>
> While it looks like a good idea to use $readentirefile, once you  
> think it through, it's not unless you know your application will  
> only ever be Mac-only.
>
> Particularly in the case of a library, you already know what the  
> filetype and creator are so you don't need to read them off the disk.
>
> So I suggest just changing all your $readentirefile to $readfile and  
> all $writeentirefile to $writefile, (you'll need to re-load any  
> library file images you already have in the database), and from  
> there it will work fine on both platforms.
>
> Do lvFileOpsObj.$createfile(lvPath,'OO$A','OO$$')
> Do lvFileOpsObj.$writefile(lvTempBin) Returns lvResult
> If lvResult=1
> Else
>  OK message Couldn't download library (Sound bell) {Error from  
> $writefile - error code: [lvResult]}
> End If
> Do lvFileOpsObj.$closefile()
>
> Cheers,
> Reg
>
>
> David Walton wrote:
>> Kelly,
>>
>> Seems I am now encountering an issue with the 12 byte header -  
>> which isn't being read - or written. Don't know how to get windows  
>> to read it...
>>
>> Any ideas?
>>
>> It gives the message that Omnis can't read the library file (the  
>> one I'm reading and writing).
>>
>>
>> In brief, here's what I'm doing...
>>
>> There's a version update button that , when clicked, prompts for a  
>> library file. The file is read and placed into the database. Then,  
>> when a client logs in, it fetches the most current library file and  
>> replaces their local copy. Then it relaunches the library again.
>>
>> I can look at the binary that is written to the database from  
>> windows and it doesn't have the 12 byte header. I assume that is  
>> causing windows to not understand the file type???
>>
>> Thanks.
>>
>> On Apr 17, 2009, at 7:44 PM, Kelly Burgess wrote:
>>
>>> Hi David,
>>>
>>>> Do FileOps.$readentirefile(ipath,lbinary) returns lstatus
>>>>
>>>> This works fine on OSX but lstatus returns -47 (open file error)  
>>>> on XP.
>>>
>>> I've never used this function on Windows.  Its advantage is that  
>>> on Mac it collects both data and resource forks of a file - if  
>>> they both exist. Even for files that don't contain a resource  
>>> fork, the binary returned will still have a 12-byte header  
>>> containing Mac file type and creator, and an offset to a potential  
>>> resource fork, a.k.a. the size of the data fork following the  
>>> header.
>>>
>>> So on Windows I'd be inclined to use a FileOps object with $open/ 
>>> $read/$close instead.
>>>
>>> Kelly
>>>
>>
>
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
>