Post by MartinPost by DaveAny idea what this means when I try to run it?
VRPC-DL RISC OS 6.20 221Mbytes of Free memory.
08:59:13.99 ** WimpError ** from unknown task
Error : &000001C1
Message: 90800K of free memory is needed before the application
will start. Quit any unwanted applications or see the RISC OS User
Guide for ways to maximise memory.
I had similar problems. I suspect the problem is the alias that is
set for Bound files ...
... so when a Bound file is double-clicked, the !RunImage is run
directly without any WimpSlot settings. I think it should run the !Run
file, with some changes to pass through the file name.
So it may work or not, depending on your current settings.
Leaflet will probably work, but 528Guide probably not.
I fear it also tries to load the whole file into application memory
... which as 528Guide is 141MB will fail on any 26-bit system anyway!
Chris, as your main requirement is for a big block of memory to load the file
into, have you considered grabbing that yourself by manipulating END or using
SYS"Wimp_SlotSize"?
There are various little libraries available to BASIC for efficient
allocation of memory. One which I have used a few times is based on code
from RISC User magazine v. 9, issue 1, p. 17. It provides a shifting heap
manager, which is a little more complicated than you need, but very efficient
for memory use. You can see how I have used it in the !RunImage of
DrawToSprite which is a free download from the Sine Nomine Software website.
Another thing to consider, before you go too far, is the design of the file
format. Without documentation I have had to guess, so apologies if this is
wrong. It looked to me like there were perhaps just a series of Draw files
stuck end to end in the file. But if so, I am not sure where the navigation
tabs come from.
Anyhow, if you want to improve the application so that it only loads the
necessary pages into memory, you will find it helpful to have some sort of
index or directory giving the offsets from the start of the file to the start
of each page. You might then hit the challenge of where to store that
directory. If you store it at the start of the file, then you need to know
how many pages there are before you start writing the file, in order to leave
enough room for the right number of page offsets. If that is going to be a
problem, you could always reserve the first word of the file, write the pages
one after another, and then write the index at the end of the file, finally
changing PTR# to point to the starting word again and writing an offset to
the location of the directory. I would always recommend including a file
format version number at the start of your file, so that you can more easily
change the format later. Your application should check the format version
number and refuse to render (advising the user to upgrade the application) if
the version number is too high.
A few style guide and feature thoughts...
At the moment Select and Adjust determine whether to use animate page turning
or not. I think Adjust ought to turn the page backwards -- that's the
natural action you would expect. See Organizer for an example of this.
Perhaps animation could become a Choice, or use a modifier like Ctrl or
Shift, unless you're planning for Shift to move multiple pages and Ctrl to
move to the next section!
It would be better for most of the things on the iconbar menu to appear
instead in a menu over the main window. The iconbar menu should not have
much more than global choices, help, quit, info, etc.
Would be good if the main window could have the input focus so that Page
Up/Down would work for page turning.
Animation was extremely slow on our Iyonix, and then there was a big redraw
of the whole window after the page had turned which seemed unnecessary. I
expect this is all better on a modern machine. Perhaps the application could
detect the time taken to render and adjust the number of animation steps to
keep it acceptable?
From scrolling through the example Leaflet file in a text editor, it looked
like the Draw files had text rendered as paths. This will ensure it looks
good, but it does mean you wouldn't be able to support a search facility. I
guess this limitation may come from your source materials. If you are
converting from PDF to Draw then you may find that the method you use to
produce the PDF file makes a difference. Are you using the Tytgat/Wuerthner
PostScript 3 drivers, for example?
Or perhaps rendering as paths is needed to support the animation? If so,
then sacrificing the ability to search the text is too high a price to pay,
in my opinion.
It would be good if the application icon and the icon for the filetype could
look more different from each other. Applications should have some
transparency if they are not square, whereas file icons on RISC OS 5 should
have a graduated grey background to fill out the square and a curling bottom
right corner.
Sorry to bombard you with suggestions: they're just a few thoughts that
occurred when exploring your application. It's always hard to know at what
stage to feed these suggestions in! I don't want to discourage anyone from
releasing applications before they are fully polished. The worst software of
all is the software that hasn't been released yet because there are two or
three minor things still to tidy up. I know I've got a few examples like
that lurking on my hard disc, so congratulations on getting the software out
there for people to try.
All the best,
--
Matthew Phillips
Durham