AppBasic: Saving text in a writable gadget to a filer window

Hi Colin – many thanks for your help – sorry something’s come up. I’ll get back to you – Monday at the earliest. Blame U3A!!!

Ideally the cursor needs to be placed in the next writable gadget as soon as Return is pressed.

The Return key should activate the default action button (if there is one) according to the style guide. The cursor should be moved with (shift-) Tab or the up/down cursor keys. Colin has already shown you how to link writable gadgets.

Sorry – Code changes still result in the first line being overwritten. Grhhh!

The changes worked for me so you must be doing something wrong. Time to do some debugging, which can be lots of fun. :-)

The Button gadget allows a powerful validation string which the Writable one doesn’t.

What kind of validation string do you need? The writable gadget allows you to control what characters are accepted which is all that it needs.

Fred, what amazing work you’ve done on ExifEdit and Transient. I’ve not used ExifEdit before but I didn’t know you could drag jpeg files directly into AppBasic. Wow :-)

Thanks. The jpeg plotting has little to do with AppBasic, with regular BASIC the code would be pretty much the same. It’s just a matter of finding the scale factors to use and then rendering the jpeg to the sprite inside the image frame.

I will try and work through some of your Event-handlers but they do look rather sophisticated.

It’s not that difficult once you’ve grasped how things are structured. Each window has its own source file containing its event handler and associated code. The DealWith_Window procedure is used to dispatch events to the various window event handlers.

Colin I have tested the code preventing text overwrites as a stand-alone program and it works perfectly. Whenever I used it in my AppBasic app. with writable gadgets it always appeared to overwrite the text. I’ve created another duplicate app. from scratch and integrated your code into it – no overwrites. So it had to be a mistake in the original ‘SaveAs’ handler. So after carefully going through what looked like identical lines of code I discovered using Martin Avison’s excellent utility… Compare that I had written OPENOUT instead of OPENUP. I couldn’t see it for looking – how very frustrating :-((

What a shame the BASIC programming team didn’t use another keyword to make a clear distinction between the two.

Ref: Style-compliant TAB to move between writable fields. Brilliant that works as do your instructions on the default input focus. Many thanks :-)

Ref: Validation string equivalent in Writable gadget

This is such a minor thing but could the Writable gadget have a border around it?

This is such a minor thing but could the Writable gadget have a border around it?

No because it isn’t style guide compliant and the toolbox is designed to produce style guide compliant apps.

From my own personal viewpoint slabbed writeable fields should have been strangled at birth along with lots of other nasty slabbing on riscos and don’t get me started on that horrible slabbed line that appears above Cancel and OK buttons in some apps yuk. I spend ages removing slabs on applications I use. But it’s all personal preference.

What a shame the BASIC programming team didn’t use another keyword to make a clear distinction between the two [OPENOUT OPENUP]

I am amused by your reference to the ‘BASIC programming team’. The BBC BASIC we use is derived directly from that written for the BBC Micro at the start of the ’80s. There were more than just Sophie Wilson involved in the design, but it was essentially her work alone. Originally there were just OPENIN and OPENOUT, which did just what they say. With the ARM version, OPENOUT was extended to allow both in and out operations on a new file and a new keyword was added to allow out operations to existing files: OPENUP was chosen. Perhaps it would be done differently if written now, but we have what we have.

OPENIN = open for input
OPENOUT = open for output
OPENUP = open for update, so you can change the contents of the file without replacing it completely. Most commonly used for adding to an existing file.

Bearing in mind what they are abbreviations for, it’s hard to imagine more obvious choices for keywords.

BASIC I on the BBC Computer had OPENOUT and OPENIN only. My Beeb (an issue 4) had BASIC II, which had added OPENUP. This used the token used by OPENIN on BASIC I, with the new OPENIN getting a new token.

That’s as I remember it anyway! :)

Originally there were just OPENIN and OPENOUT, which did just what they say. With the ARM version, OPENOUT was extended to allow both in and out operations on a new file and a new keyword was added to allow out operations to existing files: OPENUP was chosen.

Are you sure about that history?

IIRC, BASIC I (on the BBC Micro) had OPENIN and OPENOUT, where OPENIN actually opened files for reading and writing. As a result, when the bug-fixed BASIC II came out as an update for the Beeb, OPENOUT remained the same, the token for OPENIN was switched to display as the more accurate OPENUP, and a new token was added to represent an OPENIN which now did what its name implied.

Those tokens then remained the same all the way through the rest of the 8-bit era and on to the present day.

Colin:

…slabbed writeable fields should have been strangled at birth along with lots of other nasty…

I wonder how much we have to thank CC for this? ;-)

Steve (D):

With the ARM version, OPENOUT was extended to allow both in and out operations on a new file and a new keyword was added to allow out operations to existing files: OPENUP was chosen.

Utterly wrong. ;-) Take a look at the BBC B user guide on page 282 (actual page 294 in the PDF).

The critical difference isn’t that OPENUP allows read/write access in the file, the critical difference is that OPENOUT first deletes the original file. Plus, an inability to support random access in files might not be a biggie for a tape-only system, but it is quite a hindrance for a disc/network capable machine.

Utterly wrong. ;-)

Interesting. ;-)

In my paper User Guide (Issue 1 May 1984) there are only OPENIN opens a file so that it can be read and OPENOUT open a new (empty) file for writing. That will be BASIC I, which was the original. I only read the File handling chapter, and I was wrong about OPENIN also being used to write to existing files. I then skipped the changes in BASIC II to what is in the ARM version, which was confusing. Steve F’s explanation is the clearest.

However, was I right about “OPENOUT was extended to allow both in and out” being different from the BBC version?

Beeb OS v1 (and BASIC 1) were quickly replaced. ;-)

However, was I right about “OPENOUT was extended to allow both in and out” being different from the BBC version?

I have not checked the Master User Guide, but I don’t remember that behaviour from back then, so I would imagine it came with the ARM version.

Bah. They should have used just a single token to represent OPEN, and had a parameter to represent either read, write or read/write.

OTOH, knowing Acorn, if they’d done that then in order to keep BASIC programs as compact as possible, rather than some clear text (“read”, “write” or “update”) for the parameter, it would have been a single byte with bit 0 set for reading and bit 1 set for writing, or something like that, so much less readable than OPENIN/OPENOUT/OPENUP.

(Readability easily solved with some well named constants, of course – which would have been more practical once we had more memory to play with.)

it would have been a single byte with bit 0 set for reading and bit 1 set for writing, or something like that

Nods slowly.