Enrico,EnricoMaria wrote:Badara Thiam wrote:Evans,
Did you try to create CON.BMP from Explorer? If not, please do it and you will find that Windows doesn't allow to create a file with that name.
EMG
We are probably making an issue here for no apparent reason.
The question is not if Windows allows creating a file with the name "CON.*", but rather searching why Function FILE(...) does not behave the same way in the 16-bit and 32-bit.
The 16-bit returns .F. and the 32-bit returns .T.., so why is this happening and my next question is who's function is FILE() ? I didn't find anything in the provided source code that comes with FW/FWH for this function.
Therefore, perhaps some of the big gurus can tell us how this function is called, and where it belongs (xHarbour or FWH) ?.
It doesn't matter if I/we use a windows' reserved name, but it's the return value that matters. It would be more appropriate to return the same value as the equivalent 16-bit, and DOS-Clipper, rather than giving me this surprise, realizing that this function was the mother of a nice "crash" of my program, which was trying to resize a bitmap to fit inside a box on a paycheck! The program fell in an endless loop just because the function FILE() returned .T. for a non existing file....
Who would even expect that this function would not function properly (when it did in Clipper/FW), and check this specific return value, instead of spending several hours checking the rest of the code, to find where it fails... So this was my problem, that I didn't even suspect that FILE() caused the problem.
Thank You All for spending so many hours to reply to this email. I still think that I did not get the proper reply to this post though.... My question once again is why is this difference between 16-32 bit ?
Kind reagards to all
Evans