HB_FEof() is always .T.

[CMani Sw]

Hello,

I am enthusiast to use MiniGUI, ad thank you for your good  work.

 I am version: Harbour MiniGUI Extended Edition 17.06 (Update 2)

in this code:

    HB_FUse(my_chlst)
    msgbox(HB_FEof())
    WHILE ! HB_FEof()
        c1Line := HB_FReadLN()

        ..................................

         HB_FSkip()
     ENDDO
     HB_FUse()

HB_FEof()

HB_FEof()  remain always .T. , I see it in msgbox, and the while not work.
The file exist, and is not empty.
Have you some suggestion?
Is a my error or a bug?

Thank you

Claudio

[Serge Girard]

Claudio,

This works for me. Check if file exists with FILE function!

Serge

Op zondag 6 augustus 2017 11:38:41 UTC+2 schreef CMani Sw:

[Pete]

On Sunday, 6 August 2017 12:38:41 UTC+3, CMani Sw wrote:

Hello,

I am enthusiast to use MiniGUI, ad thank you for your good  work.

 I am version: Harbour MiniGUI Extended Edition 17.06 (Update 2)

Could you tell which specific distribution of Minigui are you using?
I mean, where you have obtained your minigui version from.  --just post the link here.
It will help to give you a more detailed explanation about the problem.

 

in this code:

    HB_FUse(my_chlst)
    msgbox(HB_FEof())
    WHILE ! HB_FEof()
        c1Line := HB_FReadLN()

        ..................................

         HB_FSkip()
     ENDDO
     HB_FUse()

HB_FEof()

HB_FEof()  remain always .T. , I see it in msgbox, and the while not work.
The file exist, and is not empty.
Have you some suggestion?
Is a my error or a bug?

It is not exactly your fault nor a bug either.
I'm guessing that you're using minigui bundled with hb34.
If this is the case, all what you have to do is  to replace
HB_FEof() for hb_FAtEof()
and your code should work as expected.

regards,
Pete

[CMani Sw]

Ok resolved.

I download hmg-17.06-setup.exe from http://www.hmgextended.com/download.html.
Pete is right , probably is "minigui bundled with hb34".
With  hb_FAtEof() work as aspected.
Thanks to all

Claudio

[vszakats]

It is not exactly your fault nor a bug either.
I'm guessing that you're using minigui bundled with hb34.
If this is the case, all what you have to do is  to replace
HB_FEof() for hb_FAtEof()
and your code should work as expected.

Yes.

It's probably even better to use the original FT_F*() function names

(from hbnf lib). Specifically FT_FEOF() for the above function. This

removes the ambiguity introduced when a simplified and renamed

copy of these functions were copy-pasted into hbmisc (long ago),

and creating a name collision with core HB_FEOF().

In 3.4, the HB_F*() functions are 1-to-1 wrappers to the matching

FT_F*() functions:

  https://github.com/vszakats/harbour-core/blob/master/contrib/hbmisc/hb_f.c

[Pete]

On Sunday, 6 August 2017 17:13:03 UTC+3, vszakats wrote:

Yes.

It's probably even better to use the original FT_F*() function names

(from hbnf lib). Specifically FT_FEOF() for the above function. This

removes the ambiguity introduced when a simplified and renamed

copy of these functions were copy-pasted into hbmisc (long ago),

and creating a name collision with core HB_FEOF().

a by-side note regarding  hb feof() core function:
investigating the source code (hbfeof.c) of this function,
I think that something is wrong  with it, or more precisely,
there is a remarkable degree of untruth in this `.T.` returned
when no file handle has been passed to it.

Conceptually, eof==.T. means that the end of a *certain* file,
(file specified in our case by its handle) has been reached.
Now, returning .T. for an *unspecified* file, when no file handle passed,
is at least arbitrary (it's like conjecturing the cat is dead before
opening/seeing in the box <g>) and certainly misleading.

in my humble opinion, hb_feof() when no file handle is passed, should either
return a NIL (which could interpreted as "don't know" --not much elegant
but better than .T.) or even better raise an RTE.


regards,
Pete

[vszakats]

It was likely committed [1] this way because the rest of F*()

functions behave like that: They return a fallback value of the

normal return value type when called with invalid arguments.

With the exception of FOPEN(), which returns an RTE, but

even that one was undocumented in Cl*pper docs.

The root mixup here is the addition of a function with the same

name, but different arguments/purpose, to hbmisc [2].

It's now too late to change HB_FEOF(). But, few years ago the

HB_V*() API was introduced, which always RTEs on wrong

arguments. It has some useful features and much better

OPEN/CREATE semantics. I recommend to check it out.

(Harbour 3.4 was updated to use this new API internally everywhere.)

[1] https://github.com/vszakats/harbour-core/commit/fea7b1045b001310107cec29a79c2d066ca66b33

[2] https://github.com/vszakats/harbour-core/commit/31ddcf3bb8d209f8cdf4c9e6c128ca9a52e99eba

[Pete]

On Sunday, 6 August 2017 22:26:19 UTC+3, vszakats wrote:

It's now too late to change HB_FEOF().

Unfortunately, it's true.
 

But, few years ago the

HB_V*() API was introduced, which always RTEs on wrong

arguments. It has some useful features and much better

OPEN/CREATE semantics. I recommend to check it out.

yes of course! I'm aware of  hb_vf** family functions --time ago I've created a documentation page 
about them, (still incomplete, but keep enhancing it) in a wiki I maintain for that purpose. 
Indeed they are quite better designed/efficient and preferable compared to the older IO API;
and yes, the hb_vfEof() (the counterpart of hb_FEof() ) triggers an RTE in situations like
that in discussion.
Absolutely recommended for use on new code.
 

(Harbour 3.4 was updated to use this new API internally everywhere.)

Good!

regards,
Pete

[vszakats]

yes of course! I'm aware of  hb_vf** family functions --time ago I've created a documentation page 
about them, (still incomplete, but keep enhancing it) in a wiki I maintain for that purpose. 

That's cool. These would be great candidates for the

Harbour Reference Guide.

In the meantime I've linked your Wiki from the README.

[Pete]

Thanks for your favourable comment and linking.
Much appreciated/encouraging.

regards,
Pete