[Implemented] Reading/Writing Designated File

[oldefoxx]

I find the requirment that all read and write operations to file have to be
to the current file to be a real aggrivation. I'm sure it has been mentioned
before, but commands like ReadString() could be made much more
versitile if you permitted an optional file designation parameter, like
ReadString(f1), where f1 designated which file was to be read from. That
would make it much easier to work with multiple files simultaneously.

FileSeek() should allow a second parameter to designate the specific
file, and there needs to be a companion command that returns the
current file position so that you can tell where you are in the file.

In fact almost every command needs its counterpoint. If you can write to
the screen, you sometimes need to read from the screen. File I/O is
particularly critical, since most information ends up in that form sooner
or later.

[aXend]

I agree that for readibility and consistance that would be the best.

You can switch between files to work with multiple files. Just use

Code: Select all

UseFile(#File)

The #File points to the filehandle of the file you want to use.

[blueznl]

this point is valid for many commands, i'd like to see both, that is support for current syntax

ie. using

Code: Select all

whatever()

refers to the last used file / command / ... and

Code: Select all

whatever( <nr> )

... specifying it

[Dare2]

I agree.

[fweil]

...,

Concerning file commands most languages use a file number as an attribute, also for Read / Write ... so I totally agree with this.

And for some other commands too ... Genralizing such an attribute would make coding far easier.

Rgrds

[thefool]

yes it would be easier to control multible open files.

[blueznl]

but keep both syntaxes as that will allow procedures that don't have to receive the file number... and that wouldn't break old code

[Kazmirzak]

I agree, too!

It shouldn't be too much work for the Pure Basic - developper to add this feature. By the way, the current state is very inconsequent - sometimes you have to use <nr>, in the next command you are not allowed to use <nr>

[Danilo]

You can switch between files to work with multiple files. Just use

Code: Select all

UseFile(#File)

The #File points to the filehandle of the file you want to use.

The way with UseFile(Nr) and other Use...() commands
makes it absolutely impossible to program thread-safe.

1 Thread calls an Use....() function and does some things now.
If another thread calls the same Use....() function now, the
first thread is affected by this too, and things get corrupt and
mixed up.

The Use....() commands set a global number internally, and other
functions rely on this global number. Global stuff isnt good for
thread-safety.
Every Object (Function/Procedure) has to run absolutely standalone
without relying on a global internal number - thread-safety and
callbacks are not safe with this global stuff.

In OOP its much better, because the handle is saved *local*
as data in the object:

Code: Select all

file1.FILE = File()
If file1\Create("c:\xyz.bin")
  file1\WriteByte(12)
  file1\Close()
EndIf

In PB it must be like this to make it safer:

Code: Select all

file2 = CreateFile("c:\xyz.bin")
If file2
  WriteByte(file2,12)
  CloseFile(file2)
EndIf

[Kazmirzak]

I think following (what is real!) is simply stupid:

ActivateGadget(#gadget)
ActivateWindow()

In the case of the gadget, you have to write #gadget, in case of the window, you must not write #window! Please, make following possible:

ActivateGadget([#gadget])
ActivateWindow([#window])

Optional Parameters allow everyone to use the style he prefers...
Jürgen

[freak]

ActivateGadget() (without any parameter) is useless, because there is no
"current gadget". (There is no such thing as UseGadget() as well, because
it would not make much sense.) That's why it needs to be specified all the
time.

I agree with the ActivateWindow([#Window]) thing though.

Timo