FreeFile ?

[Adrian Verkuil]

local Fnum as LONG

Fnum=FREEFILE


SEEK(#Fnum) ' compile error SEEK(Fnum) works

PUT$ or GET$ #FNUM works and also with just Fnum

So is it save to only use Fnum and is it save I declare it as long instead off integer?

[Cliff Nichols]

Think of it this way

Integer

with a range of -32,768 to +32,767

Long

they span a much greater range, from -2,147,483,648 to +2,147,483,647

Word

with a range of 0 to 65535

DWord

with a range of 0 to 4,294,967,295

[Michael Mattias]

With any of the PB/Windows compilers, always use a long integer for a PB file handle. For that matter, you should use a long integer whenever you need an 'integer' variable, as the compilers are optimized for this data type.

As far as SEEK not accepting the "#" sign in the syntax (if that is what you are saying), that's something you should send to PB as a new feature suggestion: "Make SEEK sytnax's use of # sign preceding the handle an option just like it is for all the other file access functions."

[Adrian Verkuil]

Hi MM,

Yes that what I mean it's a bit confusing things,

Better to make this like use #Fnum always so also for the seek I think.
Most programmers are used to #1, so maybe PB can make it so that the #Fnum works also with the SEEK.

Bob and his guys also read the forums so they will pick it up I guess, it's not to important anyway, but every bit helps to make a rock stable product even better.

[Kev Peel]

The # sign with file numbers is for backwards compatibility. I don't think it works with functions such as LOF() and EOF() because the DOS version didn't either.

[Michael Mattias]

# sign with file numbers is for backwards compatibility. I don't think it works with functions such as LOF() and EOF() because the DOS version didn't either.

Doesn't mean it's not a good idea... that ALL the functions which utilize a PB file handle accept that value using the same syntax.

I have never used the "#" so I never noticed before that "#" doesn't work with all the file functions.

Call me crazy or overly optimistic but my default assumption would have been "if this function using a PB handle accepts "#, then all of the functions should accept that handle the same way."

Doing it otherwise would be like using "F1" for help on some screens and "F2" on others.

[Adrian Verkuil]

MM,

That would be #F1 and F1 on others

[Kev Peel]

Yes, I agree it is a good idea. The amount of times I have to change the code because I used EOF(#nFile) instead of EOF(nFile). My mistake, it does work with LOF(), just not EOF(). It works with SEEK as well.

[Michael Mattias]

Well, if you REALLY want it, you will care enough to invest the 30 seconds it will take you to send a New Feature Suggestion to [email protected]

[Rodney Hicks]

And if you really want it NOW you could create a macro or two or ....
eg:

MACRO SEEK# = SEEK

Rod

[Adrian Verkuil]

Ok guys, I have send a mail to PB with the request to look at this thread.

[Peter Lameijn]

I always wondered why freefile doesn't just return the windows file handle. It would make things easier. PB doesn't have to have an extra layer of it's own file numbers anymore, and no PB filenumer to Windows filenumber translation anymore...
It would break some bad written existing code (with hard-coded filenumbers), but I think that's acceptable...

[Kev Peel]

Nice idea, but how would FREEFILE know the file handle before it is opened?

[Michael Mattias]

Also, if the PB handle were controlled by the O/S, it would be backward-incompatible with any code which uses...

  OPEN "myfile" for somemode [b]AS #123[/b]

Windows don't know "123" is in use, do it?

MCM

[Peter Lameijn]

Nice idea, but how would FREEFILE know the file handle before it is opened?"

You're right about that . But maybe then extend 'Open' to directly return a Windows handle... You then wouldn't need freefile anymore.

"Windows don't know "123" is in use, do it? "

That's true, but as I said before, I think those hard-coded filenumbers are bad practise anyway that should be avoided...

[Michael Mattias]

That's true, but as I said before, I think those hard-coded filenumbers are bad practise anyway that should be avoided...

I think a lot of stuff the compiler supports is bad practice; eg single-line IF..THEN.

But I like backward-compatability a heck of lot more than I dislike support for what I consider inferior or poor programming practice.

MCM

[Michael Mattias]

Besides, is it really that hard to type ..

Syshandle = [b]FILEATTR(hFile, 2)[/b]

.. when you need a system handle?

[Donald Darden]

"Hard coded file numbers are a bad idea"?

What does that mean? Using Freefile and a variable, you don't have to even know what the file number is. But you still need a "hard coded" variable to work with a given file, and that is a whole lot more convenient than having to use the file name and path repeatedly thoughout your code. I have no idea where you are coming from on this. It isn't even important what reference that Windows is using to work with the file, because you can code it and let PoweBasic manage all the details. Just what added benefit are you striving for that you want to see this change?

Freefile is just an option. PowerBasic also allows you to assign your own file numbers, such as 1 could be hard coded for an input file, 2 might be assigned to an output file, 4 might be used for a database file, 18 could be a log file, whatever. You can even use constants to represent file numbers, and that means you can use a name like %log = 18 as a rememberance tool, such as PRINT# %log, "error found."

I think that PowerBasic gives you a lot of freedom in how you manage files, and it does not require you to learn mastery of Windows at the same time. The obscure cases that you seem to be making reference to are a thin reason to revamp PowerBasic and force people to learn something else, or forced to adapt existing code for future compatibility.

Sorry for sounding a bit harsh here, but this cup's got no bottom to it.

[Cliff Nichols]

I always wondered why freefile doesn't just return the windows file handle. It would make things easier. PB doesn't have to have an extra layer of it's own file numbers anymore, and no PB filenumer to Windows filenumber translation anymore...
It would break some bad written existing code (with hard-coded filenumbers), but I think that's acceptable...

I think PB returns freefile as an "Ease of Use" number (since lets face it, many of us are VB refugees and are used to the ease, and unless used to messing with windows API, a harder syntax makes one give up too easy)

At least they give a way out with "OPEN HANDLE" to get the handle of the file as Windows sees it.

Nice idea, but how would FREEFILE know the file handle before it is opened?

FreeFile is basically hidden from us, but one way to know is to track the numbers yourself, and get the windows handle to that number. I do this to a minor level, but have yet to add in if the handle is still valid? or invalid?

That's true, but as I said before, I think those hard-coded filenumbers are bad practise anyway that should be avoided...

Heree, Heere Any Hardcoded value like that can easily be out of scope, and be an invalid value. (And not as hard as most to track down "Bug-Wise" if you know to look for it)

***** THE REST OF THE BELOW IS IN RESPONSE TO WHAT WAS POSTED
***** AFTER LOGGING IN AND PRESSING REPLY, BUT WAS NOT SEEN WHEN
***** READING REPLIES (small bug in the website I think since some says
***** what I said above, and I have been noticing this lately)

*** For PB Monitors (last I saw was Peter with

Nice idea, but how would FREEFILE know the file handle before it is opened?"

at 3:10 posting...and here it is 7:05 on my reply (so magically 3 more posts were made that I did not see, until I hit reply)

MCM made the same point I made above with

Syshandle = FILEATTR(hFile, 2)

Donald with

"Hard coded file numbers are a bad idea"?

What does that mean?

Ummmmm yeahhhhh....hard coding a file number is a bad idea if you do not watch if the the number you see is a handle or an invalid handle

Using Freefile and a variable

Yep the way to go, because to me FreeFile is a variable, but gotta watch if that variable is in or out of scope.

Best practice..."Ye Create, Ye Destroy....Ye Handle, Ye watch that Handle"

[Michael Mattias]

FreeFile is basically hidden from us, but one way to know is to track the numbers yourself, and get the windows handle to that number

That's absurd. Windows does not document how it assigns file handles, therefore there is no way for you to know it.

Besides, I would not be surprised if Windows' handle tables include ALL handles for a process.... depending on in what order they are requested by that process, a handle value of "X" might be a window handle, a file handle, a device context handle, a thread handle...

Of course FREEFILE is hidden from you: it's a proprietary function. (Even though it does not take a rocket scientist to figure out how it's done.... which reminds me... the specific way FREEFILE assigns numbers was changed one or two releases ago... and that change was documented by PowerBASIC).

I'm glad I checked in here before the hockey game. I needed a 'silly' break.


MCM