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

I’m trying to drag some text (typed into a writable gadget) to a filer window using a SaveAs template from a window menu.

There are two event-handlers (EH) – a Window and SaveAs.

1. The Window EH simply returns the text string showing in the writable icon with… PROCWritableField_GetValue(object,0,Text$)
This enables the string to be ‘written’ into another gadget (eg. display). This works fine.

2. I need code to get this text string to be recognised by the SaveAs handler. I’m sure it could be done with something like OPENIN/BGET# or is OPENOUT/BPUT#- I always get them confused.

Could someone help me out of my misery please?

Largely off the top of my head, if I have understood the problem, I think you need to put the string in a data block and pass the address and size to the SaveAs object with PROCSaveAs_SetDataAddress.

It depends on how you want to save the data. If you want the Toolbox to handle everything then you do as Steve suggests and call PROCSaveAs_SetDataAddress(object,buffer,size) when you receive the SaveAs_AboutToBeShown event (be sure to enable the event in ResEd).

If you want to use OPENOUT/BPUT# then you’ll need to set the Client participates option in ResEd. Then add the code to perform the save to the SaveAs_SaveToFile event handler. Something like this:

   PROCSaveAs_GetFileName(SaveAs%,filename$)
   PROCWritableField_GetValue(Window%,0,Text$)
   fh% = OPENOUT filename$
   BPUT#fh%,Text$
   CLOSE#fh%
   PROCSaveAs_FileSaveCompleted(SaveAs%,filename$)

Thank you Steve and Fred. Fred using the Client participates option (set in Res file) and your example code does enable me to save the writable icon text to a filer window – I’m making slow progress. Strangely though, to do this I must set…
PROCWritableField_GetValue(Window%,0,Text$)
in a separate event-handler. If I keep it in the SaveAs E-H as per your example I get an error…

“Bad call of ‘PROCWritableField_GetValue’: MiscOp Method, 0×201, not recognised”

The Save as icon is shown as a text file (set in SaveAs template) but comes out as data when saved to a filer window – any ideas why?

If nothing is typed into the writable icon and a SaveAs is attempted I get an “Unknown or missing variable” error because it can’t recognise Text$. OK this is obvious but I don’t suppose and I’m being cheeky here, you could provide an error tracking routine to stop this happening?

“Bad call of ‘PROCWritableField_GetValue’: MiscOp Method, 0×201, not recognised”

My guess is that one of the parameters passed to the underlying SWI has not been given its correct value at the time you respond to the SaveAs event, perhaps Window%. AppBasic generates an identical error when the SWI call fails, for whatever reason, which is not helpful in this case.

The Save as icon is shown as a text file (set in SaveAs template) but comes out as data when saved to a filer window – any ideas why?

Because you are doing the save operation yourself, you have to set the filetype yourself. Only if you leave it up to the Toolbox is the type set from the icon.

If nothing is typed into the writable icon and a SaveAs is attempted I get an “Unknown or missing variable” error because it can’t recognise Text$. OK this is obvious

It is not obvious to me, because an empty string is still a string and the variable Text$ should still be created. Are you sure Text$ is the missing variable?

Strangely though, to do this I must set… PROCWritableField_GetValue(Window%,0,Text$) in a separate event-handler.

Sorry, my fault for taking things out of context. The code came from a quick test applet I created and it had a Toolbox event handler.

 DEF PROCDealWith_ToolboxEvent(event%,object%,component%)
   CASE event% OF
     WHEN Toolbox_Error         : PROCUtils_Alert(FNToolbox_Error)
     WHEN Toolbox_ObjectDeleted
     WHEN Toolbox_ObjectAutoCreated
       CASE FNUtils_Object(object%) OF
         WHEN "Window" : Window% = object%
         WHEN "SaveAs" : SaveAs% = object%
       ENDCASE
   ENDCASE
 ENDPROC

The advantage of this is that you can access objects from anywhere, and not just their event handlers. Also, if you don’t do this then things get difficult if you have multiple window objects.

You might want to have a look at ExifEdit or Transient, both written using AppBasic, to see how they are constructed.

I think I will let Fred take any further queries – he actually uses AppBasic. ;-)

I rely on some fairly extensive investigations I did when it was first released, many years back, and a pretty good knowledge of the Toolbox derived from writing Basalt.

Later versions of Basalt automatically create object variables from object names and do not require a special routine like the one Fred uses above, but it does make things a lot easier if they do exist from the start.

My guess is that one of the parameters passed to the underlying SWI has not been given its correct value at the time you respond to the SaveAs event, perhaps Window%. AppBasic generates an identical error when the SWI call fails, for whatever reason, which is not helpful in this case.

The error reporting can be misleading for the reasons you’ve stated. Using Fred’s ToolboxEvent code and a SaveAs E-H I’ve got the program to work. The beauty of this is as Fred points out that objects can be accessed from anywhere. I wonder if I’ve missed this in the AppBasic Manuals.

Because you are doing the save operation yourself, you have to set the filetype yourself. Only if you leave it up to the Toolbox is the type set from the icon.

Of course and quite obvious – it didn’t occur to me at the time. Thanks. I’m now able to set the filetype with good old OSCLI. I couldn’t get PROCSaveAs_SetFileType(object%,Text) to work – keep’s reporting “Unknown or missing variable”. It’s not always obvious what one has done to cause it.

Sorry, my fault for taking things out of context. The code came from a quick test applet I created and it had a Toolbox event handler.

I’m only grateful to you and Steve who have responded to someone who finds programming a fog most of the time. I was so impressed discovering AppBasic when I could double-click on a !BasicApp icon and a window popped-up with some text in it, without a single line of programming. I decide to look further into this superb package. Lacking are more examples and an inability to deal with common foreign file formats but is excellent in what it can do. A shame Joe Taylor no longer develops it.

The advantage of this is that you can access objects from anywhere, and not just their event handlers. Also, if you don’t do this then things get difficult if you have multiple window objects.

I’ve been able to dispense with the Window E-H dealing with the gadget. I’m using your Toolbox E-H with a SaveAs E-H. This enables me to link the SaveAs template and call the writable gadget code in the same handler. I didn’t know this could be done – I can’t see anything in the manual that indicates this – conceivable I’ve missed it. The only minor thing – I expected to be able to use SaveAs_GetFileType(object,FileType). It didn’t work but an OSCLI command alternative did.

You might want to have a look at ExifEdit or Transient, both written using AppBasic, to see how they are constructed.

Certainly will.

Why havn’t more programmers used AppBasic? Once the basics are grasped (I’m still doing that mind you) it would seem a brilliant way of programming in the desktop.

Why havn’t more programmers used AppBasic?

Very good question :)

I expected to be able to use SaveAs_GetFileType(object,FileType) It didn’t work but an OSCLI command alternative did.

I’m now able to set the filetype with good old OSCLI. I couldn’t get PROCSaveAs_SetFileType(object%,Text) to work – keep’s reporting “Unknown or missing variable”.

Hmm. Despite what I said, I think this needs comment. ;-)

The AppBasic procedures you are quoting are for getting and setting the filetype icon shown in the SaveAs dialogue – they have nothing to do with the file you are saving – and hence they are completely unrelated to any OSCLI statements. The FileType parameter is a number, usually given in hexadecimal, and Text is &FFF. That may be where the unknown variable comes from.

Why havn’t more programmers used AppBasic?

Not necessarily AppBasic, but the Toolbox in general. I can think of a couple of reasons.

First, it requires a change of outlook to an Object Oriented approach to programming. Not everyone is comfortable with that.

Second, the RISC OS Toolbox development is a bit of a mess, which must put off people who have otherwise got well-established systems for programming in the desktop.

I have much respect for AppBasic itself, especially the documentary and tuturial material, but I have some quibbles with the way it does things. My own old BASIC – not Basalt – Toolbox libraries are much closer to OOP, but the Toolbox part of Basalt itself goes the whole hog. It is, maybe, a steeper learning curve than AppBasic. ;-)

The Toolbox came much too late for the show, and the first versions were buggy and it was unclear how to distribute the bug fixes in a consistent way (and for some time it was unclear if bug fixes will really happen). Nowadays these problems could be fixed. But it is still unclear whether the Toolbox is really “the way to go” – I remember a very good critical summary by Straylight from around 1997. Building what is essentially a library into modules has many conceptual problems.

Before the Toolbox, it was RISCOS_Lib, so understandably everybody built their own library. It is really a shame because of the multi-wheel-reinventing that happened, but that is just typical RISC OS.

One obvious reason to avoid AppBasic is if you don’t want to use BASIC.

Just to redress the balance back in favour of toolbox. I don’t use appbasic but I always use toolbox when programming a wimp app. In basic I code with the toolbox swis. Very easy to code just give a button press/ menuevent your own event code and you don’t have to remember the default ones. If you use restest you can just design the interface and see the events you get when you click on it. Can’t see why anyone wouldn’t prefer toolbox.

It is really a shame because of the multi-wheel-reinventing that happened, but that is just typical RISC OS.

In an educational setting wheel-reinvention is the way to go. If you present students with stuff that just works all you are doing is teaching them to accept magic, without asking them to understand why it works. Remember that Joe Taylor was primarily involved in using microcomputers for teaching; teaching mathematics and teaching programming. Indeed he was the first person, certainly in Europe, to do this. It is no accident that he spent so much effort on the documentation and tutorials of AppBasic. He also revised his approach several times, so that there was a steady evolution from DrawBasic to AppBasic.

One obvious reason to avoid AppBasic is if you don’t want to use BASIC.

Quite so. BASIC is an excellent tool, but it is the fate of many tools to be pushed beyond their limits. I still believe that RiscLua is better suited for making wimp programming easier. Look at WxLua, for Windows, for example. But by the time RiscLua had evolved, certainly after 2002, there were few people around capable of taking advantage of it. I held off development of RiscLua libraries because I was hoping that somebody with more expertise than myself would take up such a project, and I did not want to start driving a road into a blind alley. That is not to say there have not been some impressive uses: Stephan Kleinert’s Mitosis game, and Michael Gerbracht’s LuaFox application. But I feel that RiscLua presents future opportunities.

Building what is essentially a library into modules has many conceptual problems.

I agree with the ‘conceptual problems’ bit, but the opening paragraphs of the Toolbox manual go some way to justifying the use of SWIs – it makes the system accessible to any programming language. If it were a library, C or otherwise, that would not be possible.

It is clear to me that the design of the Toolbox is genuinely OO, but the SWI interface subverts that – hence the conceptual leap required. AFAICT the C veneers do not make the OO aspects implicit, and it was always my aim to do that with Basalt.

It is really a shame because of the multi-wheel-reinventing that happened, but that is just typical RISC OS.

I am as guilty as anyone. I said I had quibbles with AppBasic and ended up writing a different system. ;-(

I remember when I had to decide what to base CDBurn on (prototype was BBC BASIC but it was obvious that writing an ISO9660 formatter in BASIC was just madness) – Toolbox, existing C library with auto-generated Ada binding, or “roll my own”. In 1997, the state of the Toolbox was unclear – Acorn failed to instill trust wrt long term support, and the available gadgets were so simple that recreating them in Ada going against a thin SWI layer was trivial.

So it became “roll my own”. Obviously I had much better excuses than anyone else to reinvent the wheel – I needed an Ada wheel!

In 1997, the state of the Toolbox was unclear – Acorn failed to instill trust wrt long term support

It also appeared prohibitively expensive for the casual programmer. The main way to get RedEd etc was the full Development tools. It was probably little known, but you could also get them with David Pilling’s Charm package for a fraction of the price. I do not think Acorn looked like promoting the Toolbox as the standard way to program the desktop. ;-(

I do not think Acorn looked like promoting the Toolbox as the standard way to program the desktop. ;-(

Back then, people were still using older machines, and the Toolbox was onerous at best on a 4MiB setup. I wrote QuickVoy precisely because things that claimed huge amounts of memory were not useful on the likes of an A5000.

A distribution list is dead easy to create in Pluto because it can be done simply in a text file. I wanted to do the same in AppBasic for no other reason but to see if it can be done. I have an app that has two writable gadgets – ‘Name’ and another below called ‘Email address’. As usual the coding is causing problems. Using your example, Fred:

PROCSaveAs_GetFileName(SaveAs%,filename$)
PROCWritableField_GetValue(Window%,0,Text1$)
PROCWritableField_GetValue(Window%,2,Text2$)
Total$ = Text1$ + Text2$ : PROC_Add2File
PROCSaveAs_FileSaveCompleted(object%,filename$)
:
DEF PROC_Add2File
fh% = OPENOUT filename$
BPUT#fh%,Total$
CLOSE#fh%
ENDPROC

Typing any text into their respective writable gadgets and saving the result gives the correct text output as expected when saved. Typing new text into both gadgets and saving it simply overwrites the existing text. How do I stop this happening please?

I’ve tried adding line feed and return with CHR$(10)/CHR$(13) to Total$ but I can’t seem to find a way of forcing the text to save on the next line.

Also how do I get the cursor into the first gadget without clicking on it? Ideally the cursor needs to be placed in the next writable gadget as soon as Return is pressed. This may only be possible with the Button gadget and associated WindowButtonKeypress Event-handler.

Sorry for so many questions.

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 :-) I will try and work through some of your Event-handlers but they do look rather sophisticated.

Typing new text into both gadgets and saving it simply overwrites the existing text. How do I stop this happening please?

Change

DEF PROC_Add2File
fh% = OPENOUT filename$
BPUT#fh%,Total$
CLOSE#fh%
ENDPROC

to

DEF PROC_Add2File
fh% = OPENUP filename$
IF fh% = 0 fh% = OPENOUT filename$
PTR#fh%=EXT#fh%
BPUT#fh%,Total$
CLOSE#fh%
ENDPROC

Also how do I get the cursor into the first gadget without clicking on it?

In resed, drag the gadget to the ‘Main window properties→Default input focus→in gadget’ icon

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

In resed drag the writable icons to the writablefield’s ‘main properties→link to gadgets→before/after’ icons and you get a nice style guide compliant TAB to move between writable fields.

This can all be tested in ResTest without writing any code.

DEF PROC_Add2File
fh% = OPENUP filename$
IF fh% = 0 fh% = OPENOUT filename$
PTR#fh%=EXT#fh%
BPUT#fh%,Total$
CLOSE#fh%
ENDPROC

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

In resed, drag the gadget to the ‘Main window properties→Default input focus→in gadget’ icon

Of course – I missed that. Unfortunately it only works for writable gadgets.

In resed drag the writable icons to the writablefield’s ‘main properties→link to gadgets→before/after’ icons and you get a nice style guide compliant TAB to move between writable fields.

Only works with writable gadgets. I’ll have to use them instead of the Button gadget. The Button gadget allows a powerful validation string which the Writable one doesn’t.

What’s the latest version of ResTest? Does it work with ARMv7 machines?

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

Then you are deleting the file somewhere. Just put

filename$ = "$.XXXX"
Total$ = "Hello"
PROC_Add2File
PROC_Add2File
END
DEF PROC_Add2File
fh% = OPENUP filename$
IF fh% = 0 fh% = OPENOUT filename$
PTR#fh%=EXT#fh%
BPUT#fh%,Total$
CLOSE#fh%
ENDPROC

in a BASIC file and run it twice and $.XXXX will contain

Hello
Hello
Hello
Hello

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

Give an example validation string I’ll tell you if you can do it in the writable gadget. The writable gadget is deliberately limited so as to force style guide compliance.

I’ll have to use them instead of the Button gadget

Your problem could be using writablefield methods on a button gadget. A button gadget doesn’t have writablefield methods