The Datafile PD-CD 5/DATAFILE_PDCD5.iso/utilities/s1/sprview/!SprView/history

Text File | 1993-08-04 | 8.6 KB | 211 lines

// --------------------------------------------------------------------------
// !SPRITEVIEW HISTORY

!SpriteView is an application I wrote as an introduction to programming in
the Wimp environment using C++: the (very) partial GNU C++ implementation
written by Thomas Aeby (ported down on 27-Apr-93). I've had to write my own
library of functions but I wouldn't wish *them* on anybody!

Any additions/alterations that have come about due to other people's
comments/suggestions have those people's names in brackets next to them. For
example, I started this history file on 28-Jul-93 (Joss Smith).

// --------------------------------------------------------------------------
// VERSION: 0.08a 28-Jul-93

So far, I've written a lot of code. The application is set up to allow only
one window but is written to provide for more.

All info in the program information window is filled in once the application
starts.

The windows in which the sprite reside are customized when the sprite is
loaded.

Memory for sprites is taken from the RMA since I thought the Wimp might need
to be able to find the data for redraw whether the application is paged in or
not. That may not be the case though...

I split up the code last night.

SpriteView:
  • can load a sprite into a (correctly sized) window.
      The window has no system area (even no border). To make redrawing
      faster, the icon and the window have transparent background colours.
  • allows the user to drag the window around the screen
      This entails dragging the sprite with select
  • allows the user to resize the window
      This entails dragging the sprite with adjust
  • is riddled with error checking
      I have made the decision that good error reporting is vital. I'm quite
      happy with the set up although it makes the code a lot more cumbersome.
      There are even mechanisms for reporting non-fatal errors and (in fact)
      if a Sprite is not loaded, the application can continue without any
      problems.

Problems:
  • drag operations
      As yet they are incomplete; more control is needed over the window and
      which part of the sprite is showing. So far, dragging the window means
      it is brought to the front (and there is no back icon) and resizing it
      leaves it where it is on the window stack. This is caused by the use
      of select and adjust.
  • minimum window size
      The window can be made VERY small and this is not really desirable.
      However, I have to allow sprites of any size so I must make the
      minimum size different for different size sprites, with an upper bound
      for the minimum size.

// VERSION: 0.09a 28-Jul-93

The drag operations now work as desired. That is we now have:
  • move sprite
      linked to Drag
  • resize sprite
      linked to Alt-Drag
  • scroll sprite (horizontal, vertical, and bi-directional)
      linked to Shift-Drag
      Adjust and left,right Shift Keys dictate the behaviour of the scroll

I've also implemented
  • put to back
      linked to DoubleClick

I've created a !help file which details all of the behaviour I would like in
the finished product so far.

// VERSION: 0.10a 29-Jul-93

Fixed bugs, now:
  1) windows open on top.
  2) minimum allowed area depends on sprite
  3) sprites with masks have filled backgrounds

Have decided on a policy for having multiple frames on the same sprite. I've
implemented the ideas though have not yet had the courage to allow more than
one window in my compiled code.

Got a preliminary sprite menu up and running. The menu contains:
  • New View
     Not yet implemented.

  • Lock/Unlock
     Allows you to fix the position of the window and disables all drag
     events. It also ignores any OpenWindow block for locked windows
     and substitutes the status of the window when lock was selected
     but I don't think OpenWindow gets generated so the window drifts
     up and down in the stack. I've allowed DoubleClick to remain.

  • Remove
     Works for one Sprite and should work for more.

// VERSION: 0.11a 30-Jul-93

I have now written the scroll drag operations myself rather than relying on
the Wimp so that the drag looks like the sprite is being moved by the pointer
rather than against it. This has a more intuitive feel.

Implemented New View and tested !SpriteView with a maximum of 5 sprite
windows allowed. It worked fine! One problem, though, is that the menu
disappears even if you hold adjust down. It shouldn't but I have a feeling
the sequence of operations I perform in NewView induces this.

The new window opens at the bottom left of the screen.

Have had one unexplainable crash which happened whilst using a different
application. I don't think I can recreate it but have decided it might be
linked to my use of RMA space directly for my sprites.

// VERSION: 0.12a 31-Jul-93

I have written all the allocation and deallocation code for my SpriteWindows
myself and no longer use RMA blocks or mallocs. I was just going to use
mallocs but found that no memory was released from the wimpslot once it was
claimed even if I knew my code had freed the pointers.

The memory management is now written to use a RISC OS2 style Heap structure
with memory being returned automatically when enough free space presents
itself at the end of the heap. Shifting is not yet performed though adjacent
free blocks are merged.

I've included diagnostics which are outputted while the application is
running, into a file called 'DIAGNOSTICS' in the SpriteView directory (if I
set up the code to do so of course).

// VERSION: 0.13a 31-Jul-93

At last I've got my sprite shifting (Shift-Drag = Scroll Window) to work
properly. The initial direction of the drag dictates which way the window can
move. If Adjust is used to start the drag, the window can be shifted in any
direction.

I've taken resizing from the wimp now. You can resize any side/corner and the
picture remains still unless the frame size expands so as to make moving
necessary. Basically, it does the same as the Adjust Size icon but you can
resize in many different ways. Once again, the mouse movement defines the
side (corner if Adjust is used).

I've also added a different way of shifting the sprite: the sprite remains
fixed and the window travels over it. I have put checks in to make sure the
window doesn't disappear off the screen but the upper edge check is not quite
right yet.

Realized that you can at present resize the window so that it disappears off
the screen but fixed it.

Made the pointer disappear while the drags were taking place.

// VERSION: 0.14a 2-Aug-93

I've increased the number of windows allowed to 30.

There were a few bugs in the error trapping concerned with memory allocation
and sprite file loading and so I've got rid of these. I've had to rewrite the
file size check since I wrote it using a standard library function and so the
application crashed when the operation failed.

// VERSION: 0.15a 2-Aug-93

Implemented the stick function (which involved smartening up the poll loop a
little). This is a nice feature (IMO) so I'll dedicate this version to it!

// =========================================================================
// RELEASE 1
// =========================================================================
// VERSION: 0.16 4-Aug-93

Reimplemented file loading so that only the first sprite in the file was read
in rather than the whole file (Ian Fry). I've also moved towards allowing
other sprites in files to be loaded without ever having to read in the whole
file.

Dropped the 'a' from the version number. They are all alphas so far.

Read PageSize instead of assuming it was 32K (Ian Fry).

Updated the !Help file to make it acceptable for a release.

// FUTURE VERSION: 0.17

I may decide to have a submenu for "Remove" so that all copies of a sprite
can be removed. May include option on Iconbar menu to remove all sprites.

May implement loading from applications. This will make things more interesting.

May provide mechanism for grabbing presently cropped section of sprite. To
add to this, I might implement saving a sprite and maybe even an info box for
saying which mode it was defined in and its size, for example.

Maybe I'll allow the user to grab an area of the screen too!

May provide multitasking error reporting (which will entail limiting which
poll messages I'm prepared to receive while the error window remains up, or
having an internal poll loop for error reports).

May (eventually) cater for sprites with masks properly. Hmmm.

May develop a sprite reference window (say, Shift dragging a sprite file onto
the iconbar) so that sprites can be selected from the file and displayed.

// --------------------------------------------------------------------------