Using TaskWindow command

I have a problem with running InfoZip’s zip command in a TaskWindow. I’m not talking about opening a TaskWindow with Ctrl-F12, but running via the TaskWindow module from my own Wimp task.

What I am doing from within my Wimp application is using Wimp_StartTask to kick off a command of the following general form:

TaskWindow “zip -i dir.file1 dir.file2 dir.subdir.* -r SCSI::HardDisc4.$.output/zip dir” -quit -ctrl -wimpslot 2000K -task &XXXXXXXX -txt &YYYYYYYY

XXXXXXXX is my task handle, and YYYYYYYY is my private handle for the child task to pass back to me.

(The current working directory has been set to the directory containing “dir” and all the named components are present.)

On the Raspberry Pi running RISC OS 5.29 (19-Sep-21) I get a single-tasking error box popping up saying “Buffer overflow”, but no task name is given. The zip command does not execute. The task handle returned in R0 by Wimp_StartTask is zero. I don’t think my task receives any Wimp messages from the TaskWindow.

If I pass a simpler command to Wimp_StartTask, of the form:

TaskWindow “zip SCSI::HardDisc4.$.output/zip file” -quit -ctrl -wimpslot 2000K -task &XXXXXXXX -txt &YYYYYYYY

then it works, and the zip file is created. The task handle returned bin R0 is still zero, but that’s probably because the zip command completed very quickly and so the TaskWindow never had to interrupt it and poll the Wimp.

I have found that if I start Zap before testing the application, then it all works as I would expect, and with the more complex example I get a non-zero task handle in R0, and the expected TaskWindow messages (TW_Ego, TW_Output, TW_Morio).

After starting Zap the following additional modules are in memory:

ZapRedraw
Zap
ZapButtons
ZapTaskWindow
LineEditor

I am not sure what is going on here. I don’t think it is necessary to have an editor running already in order to run a task in a TaskWindow when my application is prepared to handle all the I/O. But perhaps I am mistaken. Is the “Buffer overflow” error comming from !Edit, which might be involved if Zap has not yet been run?

I have examined the Zip binary and it does not contain the string “Buffer overflow”. Nor does the TaskWindow module on GitLab. I was wondering, based on a search for the string, whether it might be an error from OS_GBPB, and perhaps expanding the dir.subdir.* argument was causing trouble?

Does anyone have any ideas, either as to the cause or what to try next?!

I don’t know if it’s your problem here, but…

If Zap is the registered task window handler and isn’t running, an intermediate task is launched called “Start Zap”, which then passes control on somehow to the actual TaskWindow task that does the work you’re wanting to do. The problem is that in this case, the handle you get back from Wimp_StartTask is for the “Start Zap” task, not the handle of the eventual TaskWindow task. Once Zap has started, the next time you launch a TaskWindow, there’s no “Start Zap” task and you get the real task handle back immediately.

This may or may not be anything to do with your problem here, but I remember it causing me a lot of pain with PrintPDF until I spotted it. In that case, I was cleaning up the temporary files when the “Start Zap” task was reported as exiting, which meant that they had gone when the real TaskWindow got going – so that GhostScript tried to convert a now-deleted PS file into a PDF.

I don’t think it is necessary to have an editor running already in order to run a task in a TaskWindow when my application is prepared to handle all the I/O. But perhaps I am mistaken. Is the “Buffer overflow” error comming from !Edit, which might be involved if Zap has not yet been run?

Put a % before TaskWindow to stop it going through Zap. No other editors need be involved, you are the editor here.

@Steve: yes, I remembered that problem, and I tracked down our email correspondence about it from eight years ago! But I wasn’t actually relying on the handle returned by Wimp_StartTask, so I thought it wasn’t my problem.

@Julie: Thank you, the Alias$TaskWindow set by Zap was the key to my problems, and if I’d thought about the correspondence with Steve a bit harder, I might have got there, though I am really bad about the CLI and I don’t think I knew that use of %

After adding a % before the TaskWindow in my command string, I tested again and there was no improvement, but unsetting Alias$TaskWindow manually proved that was the problem. After a bit more head-scratching I realised I needed to put %%TaskWindow because it was part of the format string for a C printf.

Phew! All working. Now I just need to tidy up the code and remove the debugging.

Thank you, both.

It was one of those perplexing problems: when developing the code a year or two ago it had all worked fine (because Zap was running already for editing the source code) but subsequently it was very unreliable, and we couldn’t work out why!

I am going to make a pencil note on PRM page 3-326.