An easy way to let the WIMP update?

[Gavin]

Is there an easy way to let the WIMP and other tasks update their
windows etc, in between my app doing some processing?

I have a simple application that processes a file when it dropped over
it's icon. During the processing there is no multi-tasking going on as
my simple BASIC program hogs the machine until it's finished, and I
next call Wimp_Poll. That's fine, and I don't want to go to the effort
of re-writing it to process in the background or use a taskwindow etc.

But what I would like, if there is a simple way of doing it, is allow
the WIMP and the Filer to update between each file being processed,
when there is a selection of files all dragged in at the same time to
my app. I wondered if calling Wimp_PollIdle after processing a file
was the way to do it, to sort of force a null poll for other apps to
receive, but my app is receiving a sequence of data load messages that
have been queued up from the selection being dragged in, so I
immediately start processing the next file.

I'm wondering if a better approach is to build a list of all the files
to be processed when they are first dragged in, then work through that
list (and only start the processing) on the next null poll I receive.

Any thoughts?

--
Gavin

[John Williams (News)]

In article <2cdb947852.Dentrassis@mail>,

Gavin <g...@dentrassis.com> wrote:

> I'm wondering if a better approach is to build a list of all the files
> to be processed when they are first dragged in, then work through that
> list (and only start the processing) on the next null poll I receive.

Do it as a task in a 'taskwindow'? Let the WIMP do the work.

John

--
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

[Martin Wuerthner]

In message <2cdb947852.Dentrassis@mail>
Gavin <g...@dentrassis.com> wrote:

> [...]

> But what I would like, if there is a simple way of doing it, is allow
> the WIMP and the Filer to update between each file being processed,
> when there is a selection of files all dragged in at the same time to
> my app. I wondered if calling Wimp_PollIdle after processing a file
> was the way to do it, to sort of force a null poll for other apps to
> receive, but my app is receiving a sequence of data load messages that
> have been queued up from the selection being dragged in, so I
> immediately start processing the next file.

> I'm wondering if a better approach is to build a list of all the files
> to be processed when they are first dragged in, then work through that
> list (and only start the processing) on the next null poll I receive.

Yes, that looks like a good approach.

--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[Paul Sprangers]

In article <2cdb947852.Dentrassis@mail>,
Gavin <g...@dentrassis.com> wrote:

> During the processing there is no multi-tasking going on as
> my simple BASIC program hogs the machine until it's finished, and I
> next call Wimp_Poll. That's fine, and I don't want to go to the effort
> of re-writing it to process in the background or use a taskwindow etc.

You probably don't need to thoroughly re-write your program, in order to
let it multi-task. Often, the only thing that should be added is SYS
"Wimp_Poll" call at a strategic position.

For example, if your program processes a file during a loop, say a FOR -
NEXT loop, you may want to try something like this:

FOR i%=1 TO 1000
REM Do all sort of things
IF i% MOD100 = 0, THEN SYS"Wimp_Poll",&xxxx,block%
NEXT i%

... where &xxxx is the mask that you defined in your original poll call,
and block% is the memory block that you defined during setup.

Of course, there will be a slight speed penalty, but I think that's a very
small sacrifice compared to all the benefits of multi tasking.

Kind regards,
Paul Sprangers

[Steve Fryatt]

On 31 Mar, Paul Sprangers wrote in message
<527907d...@sprie.nl>:

> You probably don't need to thoroughly re-write your program, in order to
> let it multi-task. Often, the only thing that should be added is SYS
> "Wimp_Poll" call at a strategic position.
>
> For example, if your program processes a file during a loop, say a FOR -
> NEXT loop, you may want to try something like this:
>
> FOR i%=1 TO 1000
> REM Do all sort of things
> IF i% MOD100 = 0, THEN SYS"Wimp_Poll",&xxxx,block%
> NEXT i%
>
> ... where &xxxx is the mask that you defined in your original poll call,
> and block% is the memory block that you defined during setup.

Not quite, because if you do this, you must make sure that you can handle
all of the returned reason codes which require immediate attention: for
example, fail to react to a redraw event with an immediate call to
Wimp_RedrawWindow and watch things fall over into a messy heap.

One way to do this, of course, is to wrap your Wimp_Poll call and event
handler up into a suitable procedure and then do

FOR i%=1 TO 1000
REM Do all sort of things

IF i% MOD100 = 0, THEN PROCpoll_wimp
NEXT i%

The other way (which is arguably nicer, but often more difficult to
implement) is to make your processing code yield after a given time, and
repeatedly call it from null events until it's done what it needs to do.

However, you then need to make sure that all of your code is happy to be
called re-entrantly, or that it actively doesn't let the user do things that
would lead to such a situation. For example, if you're processing a batch
of files, what do you do if the user drags some more to the iconbar (eg, do
you add them to your queue, or do you grey out the iconbar icon)?

Doing this reliably requires some thought, and ideally a program structure
that makes it simple to apply suitable checks and/or disable the applicable
parts of the GUI.

> Of course, there will be a slight speed penalty, but I think that's a very
> small sacrifice compared to all the benefits of multi tasking.

Agreed. It's well worth the effort, but isn't as simple as it might seem at
first (not much is with RISC OS).

:-)

--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 28 April 2012
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/

[Paul Sprangers]

In article <mpro.m1r1kn05...@stevefryatt.org.uk>,

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

> > IF i% MOD100 = 0, THEN SYS"Wimp_Poll",&xxxx,block%

> IF i% MOD100 = 0, THEN PROCpoll_wimp

I fully agree that calling the poll routine is much better and certainly
more flexible than just a calling SYS"Wimp_Poll". However, if there's no
need for the program to react on reason codes while processing a certain
task, such as the one in the example, you may as well just return control
to other applications.

> For example, if you're processing a batch of files, what do you do if
> the user drags some more to the iconbar (eg, do you add them to your
> queue, or do you grey out the iconbar icon)?

Since the program won't react on reason codes at all (at least, when using
the straight SYS"Wimp_Poll" call), the extra drag will simply be ignored.
That's at least what I'm experiencing in a similar case.
Meanwhile, you can still get access to other applications.

So, as far as I can see (agreed, not very far), there's not always a need
for calling the entire poll routine. A simple SYS"Wimp_Poll" can sometimes
do the trick as well - although I do feel that this might be a way of dirty
programming.

Kind regards,
Paul Sprangers

[Gerph]

On Mar 31, 2:14 pm, Paul Sprangers <P...@sprie.nl> wrote:
> In article <mpro.m1r1kn05pejpc01nm.n...@stevefryatt.org.uk>,

>    Steve Fryatt <n...@stevefryatt.org.uk> wrote:
>
> > >    IF i% MOD100 = 0, THEN SYS"Wimp_Poll",&xxxx,block%
> >   IF i% MOD100 = 0, THEN PROCpoll_wimp
>
> I fully agree that calling the poll routine is much better and certainly
> more flexible than just a calling SYS"Wimp_Poll". However, if there's no
> need for the program to react on reason codes while processing a certain
> task, such as the one in the example, you may as well just return control
> to other applications.

[slight aside]

Doing things based on a number of iterations doesn't help the user
interface that much. It may be more sensible to limit the processing
time that you run for, rather than by a number of iterations. For
example, on a given system, 100 iterations may make for a smooth
desktop, whereas on a slower system 100 iterations may take longer and
so make the desktop sluggish to use. On a faster system, 100
iterations may be fast but the overhead of switching in and out
becomes more significant and so the application doesn't run
proportionally as fast as the machine. Limitations may exist in the
operations you perform, such as FS operations may be very slow on some
systems, so you cannot do (say) 100 of them in the same time as you
expect, resulting in a sluggish system.

It's not always right to use iterations as your limiting factor -
adding a time factor in there may also help, eg:
IF processed_this_iteration > 100 OR time_elapsed_this_iteration >
15 THEN
yield to desktop
ENDIF
(or similar - doing the yield inside the loop is against my better
judgement albeit simpler)

> > For example, if you're processing a batch of files, what do you do if
> > the user drags some more to the iconbar (eg, do you add them to your
> > queue, or do you grey out the iconbar icon)?
>
> Since the program won't react on reason codes at all (at least, when using
> the straight SYS"Wimp_Poll" call), the extra drag will simply be ignored.
> That's at least what I'm experiencing in a similar case.
> Meanwhile, you can still get access to other applications.
>
> So, as far as I can see (agreed, not very far), there's not always a need
> for calling the entire poll routine. A simple SYS"Wimp_Poll" can sometimes
> do the trick as well - although I do feel that this might be a way of dirty
> programming.

The gain you make from creating a separate, subset, of the poll entry
points is massively outweighed by the maintenance and testing costs,
and the variation in user experience that you will see from doing so.
In short, you're going to regret it.

Firstly you have to identify the calls which you can safely handle in
your limited entry point. This may not be difficult initially as you
probably only handle a few poll reasons, but will become increasingly
so as you add functionality. Someone else has already mentioned the
redraw handling which must be performed. By having a subset of your
poll codes duplicated, you find you need to test more - whilst a
process is being run, and whilst a process is not being run.

Of course you could implement your poll routine conditionally, such
that every poll reason, or message, checks whether the system is
active or not and changes its behaviour accordingly, eg
WHEN reason_mouseclick
IF processing THEN
...
ELSE
...
ENDIF
This is probably reasonable, and however you implemented things you
might need to do the same thing, but it does add a maintenance burden.

Particular things you need to ensure that you get right if you're
going to handle your polls in separate places:
* Does Quit from the TaskManager work properly?
There are two messages - the PreQuit query, and the final Quit.
You should not
assume you will receive a query, but if you're in the middle of
processing,
you need to react and probably ask the user.
Remember - you cannot just exit when you receive the Quit message;
you'll
need to set a flag to indicate that you're exiting. You probably
do this anyhow,
in order to clean up resources, but now you're in the middle of a
call to the
processing routine. You will need to check that flag inside your
loop that is
performing the processing so that you can finish the it tidily,
close files,
release resources, and return to its caller properly, so that you
exit cleanly.

* Does quit from the iconbar menu (or similar) work properly?
Does the menu even work - you have to handle the mouseclicks to
open the menu
in the first place, and the menu selection to act on it.
Of course, you will have already had to ensure that menu items
that are not
selectable are greyed out whilst whatever operation is being
performed is
happening. And that should be *just* those that don't make sense -
for example
a 'start processing' option would make no sense whilst you're
already running,
and clicking it would be confusing
(Windows XP has a Zip decompress window which, during the
decompress leaves
the 'Next' button available after you've started the
decompressing, which can
let you press it twice - possibly this restarts the decompression,
or maybe
it starts a second thread that continues decompression whilst the
first is still
running... whatever is the case, there's poor logic there that
someone hasn't
considered - it's good that it doesn't crash when it's put into
that state, but
maybe that's luck, and its better to consider the problem than to
leave the
confusion to the user).

* Does user redraw still work ?
Already been mentioned - this is always an issue.

* Does moving windows work ?
Equally important, as it is frustrating for a user to find that
windows are stuck
on the screen in fixed positions because the author never
considered that whilst
one application was running you might want to work with another.
Remember that
'moving' includes placing the windows in the foreground and
background.
There is a secondary to this in that any panes attached to windows
have to move
as well - if you're using the nested wimp, this happens for free,
but if you're
doing it old-school (because the nested wimp doesn't offer exactly
the features
you need, or because you're working on an OS that's more than 12
years old) you
have to worry about that.

* Does closing the windows work ?
Not only work, but make sense. If you close the window that is
showing the
processing status, you need to be sure that that window can be
opened again, or
whether that cancels the operation. If your processing was to
import into a
document window and closing that window will remove the document,
you need to
be sure that the document is closed and the processing stops
(obviously safely!)

* Window/Icon entering/leaving must still be honoured.
If you're changing pointer, or performing user redraw based on
pointer positions
tracked by the window/icon enter/leave reasons you need to keep
these working,
as otherwise you're going to find that the pointer is stuck in the
wrong shape.

* Do !Help messages still work?
If they don't then you've got an inconsistent interface to users
that might be
confusing.

* Data transfer operations should be honoured.
This is the more fun one that you'll have to handle for the case
stated in the
OP. If 5 files are dropped on the application, the first one will
be delivered
and will start the processing. The processing loop then calls the
poll, which
then delivers the second of the 5 files. At this point if the poll
just blindly
invokes its processor you'll be processing two files
simultaneously and have
to worry about the second process affecting any global variables
in use by the
first (obviously this problem can be avoided by not using global
variables in
your processing code). After each of the files is received you'll
invoke a
further layer of processing, until you are processing 5 files at
once, with the
5th file at the outermost layer. It will complete and then file 4
will continue,
and then it finishes and file 3 continues, and so on. You need to
ensure that you
have enough stack and that this really is what you want to do.
With this scheme
you have the sequence:
start 1, start 2, start 3, start 4, start 5, end 5, end 4, end
3, end 2, end 1.
This might be more of a problem if you were to hold limited
resources for each
of the file operations (eg fixed length arrays, limited numbers of
file handles,
etc). Similarly, this may not make sense to the user if you're
reporting that the
last file is being processed, then the penultimate, and so on back
to the first.
This also has implications for the shutdown and error handling -
if there is a
problem in file 5 then the errors need to stop just it (but you
may decide you
want to cancel all the operations, without requiring the user to
click 'cancel'
for every file that's to be processed). If the user wants to quit
the
application, you need to stop every one of those processes from
running, in a
timely manner - if it takes 1 second to stop processing a file,
then it will be
5 seconds before your application quits - is that a problem ?
Implementing a queue of 'files to be processed' is the usual way
to handle this,
adding files as each dataload is received and starting their
processing on the
next null poll when you observe the queue to be non-empty. This
was suggested by
the original poster and would be my preferred solution.
This way the files are processed in order and only a single file
is processed at
a time.
Of course, there is the option to just ignore the DataLoad
operations, or report
an error to the user. Neither of which are particularly friendly.
Remember the system is multitasking. Forcing the user to serialise
their
operations defeats the purpose.

* Iconisation effects should still work.
If you support the iconisation messages, they should be consistent
between the
different ways that the system works.

* Pollwords must be processed - especially the high priority ones -
otherwise
you'll be busy-waiting all the time.

* Does error handling work as you expect?
If you get an error in the poll, will this repeat the next time it
is called
because the state isn't updated as it might be in the 'idle' (non-
processing)
state. If you're nesting operations, is the correct error handler
even called?
If your nested poll call causes an error, it isn't a problem with
the processing
of the file, so shouldn't trigger the error handler for the file
processing.
This is just the same as handling of exceptions in higher level
languages - they
should be processed at the level to which they relate and not left
to propagate
up to higher levels where they will have greater impact.

* Other protocol operations need to be checked.
I can't remember any other system-like operations which might be
present, but the
non-system protocols like External Edit, OLE, Newsbase, etc, need
to be checked
to see that they're doing the right thing if triggered whilst the
application is
in its 'processing' and 'idle' modes.

Most of these you need to check anyhow, but doing so for a separate
subset function that provides polls is an extra burden. Anywhere that
the UI performs differently under some circumstances is a bad design,
and if your application forces that state then the application is
badly designed.

In many cases, restructuring the code such that the processing can
take place in chunks helps. It isn't always the right solution, as in
itself it gives a maintenance (and initial development) cost. You do
gain other advantages in allowing chunked processing, although many
are related to reconsidering what data your are processing,
modularising your processing and creating simpler processing steps.

In essence, doing it properly (allowing multitasking, and ensuring
your application still functions as without problems for the user)
requires that you rethink what you're processing. There are no ways
around that for any non-trivial processing.

Summary:

* Just shoving in a SYS "Wimp_Poll" will work very badly.
* Inserting a special poll handler for certain codes will 'work' but
may give a
very poor experience for the user and requires greater
maintenance.
* Inserting a call to your main poll handler needs consideration for
recursion.
* In all of the above cases, your application and processing code
will need
changes to the UI to indicate available/unavailable operations,
and to handle
the termination in clean manner.

My response to the OP is that their initial feeling is right - set up
a queue of files to be processed, and process them on null polls.
Either process them to completion (which means that your UI needs less
changes, although you may need to modify your exit handler to say that
there is still pending work), or process them in chunks with a call to
your main poll function at intervals (and again you'll need to update
your exit handler to handle the processing of a file being cancelled
part way through). The queueing of files already added will take care
of new files being added to the queue.

However, I would suggest considering splitting up the processing so
that it can handle processing in chunks (if appropriate) as this may
be more flexible in any case. Of course, if the code is written nicely
in a modular fashion then changing the code so that it can be run in a
TaskWindow would merely be a matter of changing the way that it is
called and invoking the processing library differently. It seems
unlikely that this is the case - probably you've got UI code mixed in
with processing logic, which will preclude such an easy change.

--
Justin Fletcher

[Steve Fryatt]

On 31 Mar, Paul Sprangers wrote in message

<527916a...@sprie.nl>:

> In article <mpro.m1r1kn05...@stevefryatt.org.uk>,
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > > IF i% MOD100 = 0, THEN SYS"Wimp_Poll",&xxxx,block%
>
> > IF i% MOD100 = 0, THEN PROCpoll_wimp
>
> I fully agree that calling the poll routine is much better and certainly
> more flexible than just a calling SYS"Wimp_Poll". However, if there's no
> need for the program to react on reason codes while processing a certain
> task, such as the one in the example, you may as well just return control
> to other applications.

It isn't as simple as that. The example I gave was just one event that
requires immediate attention; there are others.

In addition, you can't just assume that because you're busy you can ignore
information returned from Wimp_Poll. What if the information returned was
Message_Quit, Message_PreQuit, or another informational broadcast that
requires attention? Supposing it's an F12 hotkey press that you
subsequently don't pass on via Wimp_ProcessKey?

If you call Wimp_Poll(Idle), you *must* fully process the returned event.
You can then choose to ignore the information, *if* it is safe to ignore.

[snip]

> So, as far as I can see (agreed, not very far), there's not always a need
> for calling the entire poll routine. A simple SYS"Wimp_Poll" can sometimes
> do the trick as well - although I do feel that this might be a way of
> dirty programming.

It's very dirty -- please don't encourage others to do it.

[Rick Murray]

On Sat, 31 Mar 2012 13:34:01 +0100, Steve Fryatt
<ne...@stevefryatt.org.uk> wrote:

> example, fail to react to a redraw event with an immediate call to
> Wimp_RedrawWindow and watch things fall over into a messy heap.

Depends... An auto-redraw capable window, or no window at all,
shouldn't generate such events. There's quite a lot you can just
ignore. For instance, when I cobble together something like this, at
the start I run a Wimp_Poll in a loop until I get reason code zero.
The Wimp attempts to talk to your program at the start, I just ignore
it.

MoreKeys, for instance, PollIdles awaiting a task Quit message or a
poll word. The Wimp has been told not to bother me with anything
else, and other stuff is simply ignored. The window stuff opens,
redraws, and closes the window within the same poll cycle (in effect,
it is only there so far as getting the Wimp to deal with redrawing
the background). Interaction with the Wimp is minimal. It was planned
that way.

Of course, if the program in question only polls without opening
windows and such, it's possible to pretty much ignore everything. ;-)


Best wishes,

Rick.

[Rick Murray]

On Sat, 31 Mar 2012 16:04:45 +0100, Steve Fryatt
<ne...@stevefryatt.org.uk> wrote:

> requires attention? Supposing it's an F12 hotkey press that you
> subsequently don't pass on via Wimp_ProcessKey?

Valid point.

I would *hope* that anybody doing "nasty" stuff would RTFM and set
the poll mask to inform the Wimp *not* to return in all the unwanted
cases. That, plus your application probably shouldn't even receive
such events as Key_Pressed in the first place if your application has
neither input focus nor a hotkey grabber, mean that in theory a
correctly set up application can be free to ignore such things as it
should never even receive them!
How many people correctly use the pollmask, I wonder?


Best wishes,

Rick.

[Paul Sprangers]

In article <mpro.m1r8jv07...@stevefryatt.org.uk>,

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

> > So, as far as I can see (agreed, not very far), there's not always a
> > need for calling the entire poll routine. A simple SYS"Wimp_Poll" can
> > sometimes do the trick as well - although I do feel that this might be
> > a way of dirty programming.

> It's very dirty -- please don't encourage others to do it.

I thought so. Please, forget what I've written.

Kind regards,
Paul Sprangers

[Steve Fryatt]

On 31 Mar, Rick Murray wrote in message
<almarsoft.9963...@news.orange.fr>:

> I would *hope* that anybody doing "nasty" stuff would RTFM and set the
> poll mask to inform the Wimp *not* to return in all the unwanted cases.
> That, plus your application probably shouldn't even receive such events as
> Key_Pressed in the first place if your application has neither input focus
> nor a hotkey grabber, mean that in theory a correctly set up application
> can be free to ignore such things as it should never even receive them!
> How many people correctly use the pollmask, I wonder?

It's still not that simple. It's a while since I tried this, but as I
recall the Wimp sulks in a big way if you -- say -- mask out the Mouse Click
event and then someone clicks on your iconbar icon.

Poll Masks are fine for things like Null events, and things like Mouse
Entering/ Leaving, but if you mask out an event that the Wimp thinks you
need to know about, it still won't work.

(I know this lot, because the old version of Locate does pretty much what I
advised at the head of this thread: a PROCpoll, and careful avoidance of
reentrance. While writing it, I can remember discovering a lot of pitfalls
that the PRMs didn't seem to explicitly mention. As a result of the pain
involved, the partially-written Locate 2 will go for the second option: a
single poll loop and a search routine that yields after a given time has
elapsed).

[Gerph]

On Apr 1, 2:25 pm, Bob Latham <b...@sick-of-spam.invalid> wrote:
> In article <mpro.m1r1kn05pejpc01nm.n...@stevefryatt.org.uk>,
>    Steve Fryatt <n...@stevefryatt.org.uk> wrote:
>

> > The other way (which is arguably nicer, but often more difficult to
> > implement) is to make your processing code yield after a given time, and
> > repeatedly call it from null events until it's done what it needs to do.
>

> As a amateur RO software writer who dos it for pleasure I have always
> written applications that require background processing in the same way.
> I'm unsure if the method is valid or has serious drawbacks that I've never
> noticed. I'm sure it will be laughed at for its crudity.
>
> All my progs have 1 call to wimp_poll and when i get a reason code 0 I
> then pick up a job number word and jump on a table to correct piece of
> code for the number. It then does the job and then changes the job number
> for the next return or, if all is done, sets a flag so that subsequent
> wimp_polls have the return zero code switched off.
>
> Is this truly awful by any chance?

Sounds like a round-robin job scheduling, with the ability to suspend
and continue incomplete jobs. As long as the incomplete jobs only
affect global variables in a way that is controlled, and your exit
handling takes account of the incomplete/pending jobs, it's not a bad
solution.

From the way that you've described it, I'm unsure as to whether the
'job' is a queue of single operations (eg a list of files to be
processed) or different types of job (eg 'check for files to be
processed', 'check for incoming network data', 'check for expired
files', 'check water pressure', 'check for incoming ICBM attack'). The
difference is that the former is not a priority list, but the later
may need to be prioritised - and therefore blocking jobs due to
incomplete job may matter.

Depending on how you're managing your jobs, you may need to be dealing
with large numbers of queued events so a fixed length array might not
be practical. Similarly, if a list of files is being managed, the
order in which they are processed may be important and so your job
list may need to be ordered to address taht. But these are
implementation details.

--
Justin Fletcher

[Steve Fryatt]

On 1 Apr, Bob Latham wrote in message
<52799b...@sick-of-spam.invalid>:

> In article <mpro.m1r1kn05...@stevefryatt.org.uk>,

> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > The other way (which is arguably nicer, but often more difficult to
> > implement) is to make your processing code yield after a given time, and
> > repeatedly call it from null events until it's done what it needs to do.
>

> As a amateur RO software writer who dos it for pleasure I have always
> written applications that require background processing in the same way.
> I'm unsure if the method is valid or has serious drawbacks that I've never
> noticed. I'm sure it will be laughed at for its crudity.
>
> All my progs have 1 call to wimp_poll and when i get a reason code 0 I
> then pick up a job number word and jump on a table to correct piece of
> code for the number. It then does the job and then changes the job number
> for the next return or, if all is done, sets a flag so that subsequent
> wimp_polls have the return zero code switched off.
>
> Is this truly awful by any chance?

No, that kind of state machine is one specific instance of the more general
idea that I suggested above. For tasks that break down into small,
self-contained blocks, it's an obvious and straight-forward way to implement
it (the problem only being if any one block takes more than the acceptable
inter-poll time).

[Alan Wrigley]

Bob Latham <b...@sick-of-spam.invalid> wrote:

> In article <mpro.m1tk350c...@stevefryatt.org.uk>,

> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> > On 1 Apr, Bob Latham wrote in message
> > <52799b...@sick-of-spam.invalid>:
>

> > > Is this truly awful by any chance?
>
> > No, that kind of state machine is one specific instance of the more
> > general idea that I suggested above. For tasks that break down into
> > small, self-contained blocks, it's an obvious and straight-forward way
> > to implement it (the problem only being if any one block takes more than
> > the acceptable inter-poll time).
>

> Thanks Steve. That's a pleasant surprise, especially as I've never heard
> of it being mentioned anywhere else before.

Pretty much all my apps do something similar, but slightly more complex. Any
object that wants to use null codes registers with a poll manager, giving
the delay it requires before each poll. The poll loop queries the poll
manager which returns a flag that's set if any one wants a null code plus
the shortest delay on its list. The poll loop then cals Poll if the flag is
unset or PollIdle with the returned delay if set. Any nullcode operation
which takes a long time is time-sliced in order to leave the desktop usable.
This is how SafeStore backs up files, or Hermes fetches email etc.

Alan

--
RISC OS - you know it makes cents

[Gavin]

In message <65389e78...@bach.planiverse.com>

Martin Wuerthner <spam...@mw-software.com> wrote:

> In message <2cdb947852.Dentrassis@mail>
> Gavin <g...@dentrassis.com> wrote:

>> [...]
>> But what I would like, if there is a simple way of doing it, is allow
>> the WIMP and the Filer to update between each file being processed,
>> when there is a selection of files all dragged in at the same time to
>> my app. I wondered if calling Wimp_PollIdle after processing a file
>> was the way to do it, to sort of force a null poll for other apps to
>> receive, but my app is receiving a sequence of data load messages that
>> have been queued up from the selection being dragged in, so I
>> immediately start processing the next file.

>> I'm wondering if a better approach is to build a list of all the files
>> to be processed when they are first dragged in, then work through that
>> list (and only start the processing) on the next null poll I receive.

> Yes, that looks like a good approach.

Yes, This is what I ended up doing.

[Gavin]

In message <mpro.m1r1kn05...@stevefryatt.org.uk>

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

> On 31 Mar, Paul Sprangers wrote in message
> <527907d...@sprie.nl>:

>> You probably don't need to thoroughly re-write your program, in order to
>> let it multi-task. Often, the only thing that should be added is SYS
>> "Wimp_Poll" call at a strategic position.
>>
>> For example, if your program processes a file during a loop, say a FOR -
>> NEXT loop, you may want to try something like this:
>>
>> FOR i%=1 TO 1000
>> REM Do all sort of things
>> IF i% MOD100 = 0, THEN SYS"Wimp_Poll",&xxxx,block%
>> NEXT i%
>>
>> ... where &xxxx is the mask that you defined in your original poll call,
>> and block% is the memory block that you defined during setup.

> Not quite, because if you do this, you must make sure that you can handle
> all of the returned reason codes which require immediate attention: for
> example, fail to react to a redraw event with an immediate call to
> Wimp_RedrawWindow and watch things fall over into a messy heap.

> One way to do this, of course, is to wrap your Wimp_Poll call and event
> handler up into a suitable procedure and then do

> FOR i%=1 TO 1000
> REM Do all sort of things
> IF i% MOD100 = 0, THEN PROCpoll_wimp
> NEXT i%

I tried that, but it didn't work in my case. I wanted the Wimp to
allow the Filer to update between each file I was processing (from a
selection that had been dragged in). By calling my wimp poll
procedure, I just received the next DataLoad message that had been
queued up, so didn't allow the wimp to update other tasks.

[Jeremy Nicoll - news posts]

Gavin <g...@dentrassis.com> wrote:

> I tried that, but it didn't work in my case. I wanted the Wimp to allow
> the Filer to update between each file I was processing (from a selection
> that had been dragged in). By calling my wimp poll procedure, I just
> received the next DataLoad message that had been queued up, so didn't
> allow the wimp to update other tasks.

Maybe you should have stored the dataload message parameters and continued
to call Wimp poll, only actually actioning the loads later?

--
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "aaa" by "284".

[Rick Murray]

On Sat, 07 Apr 2012 13:57:52 +0100, Gavin <g...@dentrassis.com> wrote:

> selection that had been dragged in). By calling my wimp poll
> procedure, I just received the next DataLoad message that had been
> queued up, so didn't allow the wimp to update other tasks.

The logical answer is, surely, to read the DataLoads into an array
first... ;-)


Best wishes,

Rick.