comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: point_lun question
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: point_lun question [message #17585 is a reply to message #17582] Tue, 02 November 1999 00:00 Go to previous message
Wayne Landsman is currently offline  Wayne Landsman
Messages: 117
Registered: January 1997
Senior Member
Frank wrote:

> Hi,
> I have a data file with several measurements separated by some header
> lines followed by data points. The whole file containes many
> measurements. So I want to write a procedure, that reads the header and
> the position of the file pointer at the end of the header and returns
> this in a structure for further data processing.
> Actually the routine finds the header, however, point_lun returns the
> 'correct' value only for the first header. If I check the second
> position of the pointer using an hexditor the positions are not correct.
> Whats wrong ? Do I use the wrong data type
>

Are you running under Windows? If so, then you may need to add a /BINARY
(or /NOAUTOMODE) switch to your openr statement.-- otherwise your use of
the EOF() function can corrupt the file pointer. It has something to
do with whether the file is being read in text mode or binary mode, as
discussed in the Windows-specific documentation for openr. (However, the
way that the EOF() function can corrupt the file pointer without these
keywords present still feels like a bug to me.)

Peter Mason wrote a note on this problem to comp.lang.idl-pvwave last
March.

--Wayne
Landsman
landsman@mpb.gsfc.nasa.gov
[Message index]
 
Read Message
Read Message
Previous Topic: Re: plot (x,y,z) triplets as a surface?
Next Topic: Re: change widget slider maximum dynamically?

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 11:00:18 PDT 2025

Total time taken to generate the page: 0.00403 seconds