home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-08-13 | 37.3 KB | 1,591 lines |
-
- $VER: SuperView_Ref_ENG.doc V8.1 (13.8.94)
-
- © 1994 by Andreas R. Kleinert. All rights reserved.
-
- - Feel free to translate this Doc-File into other languages. -
-
- Andreas R. Kleinert,
- Grube Hohe Grethe 23,
- D-57074 Siegen,
- Germany. email : Fido 2:2457/345.10
- (checked weekly)
-
-
- Please note the version-dependencies :
-
- superview.library SVObjects SVDrivers SVOperators
-
- Version 1 - - -
- Version 2 Version 1 - -
- Version 3-8 Version 1,2 Version 1 -
-
-
- Request at least : V2+ for SVObjects
- V3+ for SVDrivers
- V4+ for bug-fixed ClipBoard-Support
- with the supplied SVObjects
- V5+ for bug-fixed GfxBuffer-Functions
- V6+ for working GfxBuffer-Writing
- with the supplied SVObjects
- V7+ for adding/removing single SVObjects/SVDrivers
-
-
- Here is a listing of all currently available functions of the
- superview.library in an Autodoc-like style of description :
-
- SVL_AllocHandle ; since Version 1
- SVL_FreeHandle
- SVL_CloseDisplay
- SVL_FreeResources
- SVL_SuperView
- SVL_SuperWrite
- SVL_InitHandleAsDOS
- SVL_InitHandleAsClip
- SVL_SetWriteType
- SVL_SetWindowIDCMP
- SVL_SetWindowFlags
- SVL_SetScreenType
- SVL_GetWindowAddress
- SVL_GetScreenAddress
- SVL_GetErrorString
- SVL_SetWriteScreen
- SVL_SetWriteName
- SVL_FileInfoRequest
- ; no functions added in Version 2
- SVL_GetGlobalDriver ; since Version 3
- SVL_SetGlobalDriver
- SVL_ReadToGfxBuffer
- SVL_GetGfxBuffer
- SVL_SetGfxBuffer
- SVL_DisplayGfxBuffer
- ; no functions added in Version 4
- ; no functions added in Version 5
- SVL_GetSVObjectList ; since Version 6
- SVL_GetSVDriverList
- SVL_FreeSVObjectList
- SVL_FreeSVDriverList
- SVL_RemoveSVObject ; since Version 7
- SVL_RemoveSVDriver
- SVL_AddSVObject
- SVL_AddSVDriver
-
- -----------------------------------------------------------------------------
- Functions available since Version 1 - 2 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_AllocHandle
-
- SYNOPSIS
-
- APTR SVL_AllocHandle(APTR future)
- D0 -$1e A1
-
- FUNCTION
-
- Allocates a handle for accessing a Graphic via SVObjects.
-
- INPUT(S)
-
- future - always NULL yet
-
- RESULT
-
- A pointer to a new allocated Handle or NULL, if allocation failed.
-
- WARNING
-
- Test, if the result was NULL, or not !
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_FreeResources, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeHandle
-
- SYNOPSIS
-
- VOID SVL_FreeHandle(APTR handle)
- D0 -$24 A1
-
- FUNCTION
-
- Stops showing, frees all Resources and delocates a Handle, which has
- been allocated with SVL_AllocHandle before.
-
-
- For programmers of SVObjects :
-
- Note, that this functions calls
-
- SVL_CloseDisplay(SVHandle);
- SVL_FreeResources(SVHandle);
-
- for internal SVObjects and
-
- SVO_FreeHandle(SVHandle->ah_SVHandle);
-
- CloseLibrary((APTR) SVObjectBase);
-
- for external SVObjects.
- So do not forget to do the SVO_CloseDisplay() and SVO_FreeResources()
- calls inside SVO_FreeHandle().
- Otherwise memory might be lost.
-
- INPUT(S)
-
- handle - a valid handle
-
- RESULT
-
- -
-
- BUGS
-
- This function was buggy for external SVObjects (never closed, memory
- loss) upto V2.4.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle, SVL_CloseDisplay, SVL_FreeResources
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_CloseDisplay
-
- SYNOPSIS
-
- VOID SVL_CloseDisplay(APTR handle)
- D0 -$2a A1
-
- FUNCTION
-
- Stops showing the Graphic, indentified by the handle.
- The Display-Screen is closed, but no Resources are given free.
-
- INPUT(S)
-
- handle - a valid handle
-
- RESULT
-
- -
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_FreeResources, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeResources
-
- SYNOPSIS
-
- VOID SVL_FreeResources(APTR handle)
- D0 -$30 A1
-
- FUNCTION
-
- Frees all resources belonging to the specific Graphic,
- indentified by the handle, which are not needed to just show it.
- The Display will not be closed.
-
- Note, that SVL_FileInfoRequest() will no longer work, then
- ("No file loaded" or similar request appears).
-
- INPUT(S)
-
- handle - a valid handle
-
- RESULT
-
- -
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle, SVL_CloseDisplay, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SuperView
-
- SYNOPSIS
-
- ULONG SVL_SuperView(APTR handle, char *filename)
- D0 -$36 A1 A2
-
- FUNCTION
-
- Loads and shows the Graphic described by FileName.
- The handle is initialized and the fitting SVObject is opened
- and accessed for showing the Graphic.
-
- Showing can be stopped either via full delocation of the handle
- or via Closing the Display with SVL_CloseDisplay.
-
- INPUT(S)
-
- handle - a valid handle
- filename - a valid AmigaDOS FilePath and -Name
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle, SVL_CloseDisplay, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SuperWrite
-
- SYNOPSIS
-
- ULONG SVL_SuperWrite(APTR handle, APTR source_handle)
- D0 -$3c A1 A2
-
- FUNCTION
-
- Before Version 3 a Graphic had to be loaded AND showed via
- SVL_SuperView : No separate reading and showing calls were done.
- For writing - that means : converting - a Graphic, you at first
- have to display, then to save it. Use the following order :
-
- (But check the "result" value AFTER EACH function call, like this
- has been done in the example SourceCodes ...)
-
- source_handle = SVL_AllocHandle(N);
- /* result = SVL_InitHandleAsDOS(source_handle, N); */ /* default */
- result = SVL_SetWindowIDCMP(source_handle,
- IDCMP_MOUSEBUTTONS | IDCMP_VANILLAKEY, N)))
- result = SVL_SetScreenType(source_handle, CUSTOMSCREEN, N)))
- result = SVL_SuperView(source_handle, source_filename)))
- result = SVL_GetScreenAddress(source_handle, &sv_screen, N)))
- result = SVL_GetWindowAddress(source_handle, &sv_window, N)))
-
- dest_handle = SVL_AllocHandle(N);
- /* result = SVL_InitHandleAsDOS(dest_handle, N); */ /* default */
- result = SVL_SetWriteType(dest_handle, dest_type, N)))
- result = SVL_SetWriteName(dest_handle, dest_filename, N)))
- result = SVL_SetWriteScreen(dest_handle, sv_screen, N)))
- result = SVL_SuperWrite(dest_handle, source_handle);
- SVL_FreeHandle(dest_handle);
-
- SVL_FreeHandle(source_handle);
-
-
- Since Version 3 it is also possible to save the contents of
- SV_GfxBuffers, so that not necessarily a Screen has to be the
- source for writing to Disk/ClipBoard (or to whatever).
- Not all SVObjects may necessarily support this (return-code
- becomes SVERR_ACTION_NOT_SUPPORTED).
- But since Version 6 all of the supplied SVObjects (those which come
- with superview.library and contain Write-Support) allow this.
- So, if you request at least V6+, the likelihood will be with you ...
-
- All available values for dest_type can be found in the specific
- SVObject-List in SuperViewBase.
- The values WILL change with every re-initialization of
- superview.library, so update them with every new opening
- (read them from the SVObject-List inside SuperViewBase or use the
- new functions, which have been introduced with V6).
- Only ILBM.svobject and ACBM.svobject (and the internal Datatype-
- svobject, which cannot be used for saving, anyway) keep the same
- values for compatibility reasons, but since two of these are now
- external you might not be sure, if they are available
- (which means : actually in "LIBS:svobjects") or not ...
-
- INPUT(S)
-
- handle - a valid handle (used for Write Access)
- source_handle - an other valid handle (used for Read Access)
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
-
-
- SVL_AllocHandle, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_InitHandleAsDOS
-
- SYNOPSIS
-
- ULONG SVL_InitHandleAsDOS(APTR handle, APTR future)
- D0 -$42 A1 A2
-
- FUNCTION
-
- Initializes a Handle for AmigaDOS access, so that the given
- AmigaDOS FileNames are used.
- Another possibility is sometimes to initialize Handles
- for ClipBoard Access (depending on the specific SVObject,
- e.g. IFF-ILBM).
-
- INPUT(S)
-
- handle - a valid handle
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- During V2.4 upto V3.8 this was done automatically ALWAYS.
- This was fixed in V4.1
- See BUGS under SVL_InitHandleAsClip.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
-
-
- SVL_InitHandleAsClip
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_InitHandleAsClip
-
- SYNOPSIS
-
- ULONG SVL_InitHandleAsClip(APTR handle, APTR future)
- D0 -$48 A1 A2
-
- FUNCTION
-
- Initializes a Handle for ClipBoard access, so that the (possibly)
- given AmigaDOS FileNames are ignored.
- The nearly always used possibility is to initialize Handles
- for AmigaDOS Access (supported by ALL SVObjects).
-
- INPUT(S)
-
- handle - a valid handle
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- From 2.4 to 3.8 this function-call was useless, since
- superview.library blocked all medias other than
- AKO_MEDIUM_DISK for external SVObjects :
- For reading calls, this resulted in a "file not found" message
- from superview.library, for writing calls, this resulted in an
- empty filename string, which caused the SVObject to reject the
- disk access (other accesses were not set correctly).
- This was fixed in 4.1, by using the SVO_SetAccessMode() function
- with the right parameters now and by using the "future" parameter
- of SVO_CheckFileType() - only when using other media than
- AKO_MEDIUM_DISK - as a pointer to an additional SVOCheckFileInfo
- structure now.
- This is 100% compatible, since superview.library has always set
- this value to NULL, so that older SVObjects will simply ignore
- this pointer and newer versions will only interpret it, if it's
- not NULL.
-
- SINCE
-
- ... version 1 of the superview.library. (request V4+)
-
- SEE ALSO
-
- SVL_InitHandleAsDOS
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWriteType
-
- SYNOPSIS
-
- ULONG SVL_SetWriteType(APTR handle, ULONG write_type, APTR future)
- D0 -$4e A1 A2 A3
-
- FUNCTION
-
- Sets the write_type for a SVL_SuperWrite() call.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- write_type - a valid temporary SubTypeCode from the SVObject-List
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWindowIDCMP
-
- SYNOPSIS
-
- ULONG SVL_SetWindowIDCMP(APTR handle, ULONG idcmp, APTR future)
- D0 -$54 A1 A2 A3
-
- FUNCTION
-
- Sets the default IDCMP-Flags for a SVL_SuperView() call.
- While displaying, the Address of the Window can be get via the
- SVL_GetWindowAddress() function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- idcmp - a valid number of IDCMP-Flags
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperView
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWindowFlags
-
- SYNOPSIS
-
- ULONG SVL_SetWindowFlags(APTR handle, ULONG flags, APTR future)
- D0 -$5a A1 A2 A3
-
- FUNCTION
-
- Sets the default Window-Flags for a SVL_SuperView() call.
- While displaying, the Address of the Window can be get via the
- SVL_GetWindowAddress() function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- flags - a valid number of Window-Flags
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperView
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetScreenType
-
- SYNOPSIS
-
- ULONG SVL_SetScreenType(APTR handle, ULONG type, APTR future)
- D0 -$60 A1 A2 A3
-
- FUNCTION
-
- Sets the default Screen-Type for a SVL_SuperView() call.
- While displaying, the Address of the Screen can be get via the
- SVL_GetScreenAddress() function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- type - a valid ScreenType value (e.g. CUSTOMSCREEN)
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperView
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetWindowAddress
-
- SYNOPSIS
-
- ULONG SVL_GetWindowAddress(APTR handle, struct Window **window,
- D0 -$66 A1 A2
-
- APTR future)
- A3
-
- FUNCTION
-
- While displaying, the Address of the DisplayWindow can be get
- via this function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- window - a valid address of a Window-Pointer
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetScreenAddress
-
- SYNOPSIS
-
- ULONG SVL_GetScreenAddress(APTR handle, struct Screen **screen,
- D0 -$66 A1 A2
-
- APTR future)
- A3
-
- FUNCTION
-
- While displaying, the Address of the DisplayScreen can be get
- via this function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- screen - a valid address of a Screen-Pointer
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetErrorString
-
- SYNOPSIS
-
- char * SVL_GetErrorString(ULONG error_code)
- D0 -$72 A1
-
- FUNCTION
-
- Returns the Error Message for a specific Error Code, returned
- by any function of the superview.library.
-
- INPUT(S)
-
- error_code - any SVERR Error Code
-
- RESULT
-
- read-only pointer to a SVERR Error String
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- -
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWriteScreen
-
- SYNOPSIS
-
- ULONG SVL_SetWriteScreen(APTR handle, struct Screen *screen,
- D0 -$78 A1 A2
-
- APTR future)
- A3
-
- FUNCTION
-
- Sets the Source Screen for a SVL_SuperWrite() call.
- See description there and example SourceCodes for more and
- detailed information.
-
- This will overwrite a previously done SVL_SetGfxBuffer() call.
-
- INPUT(S)
-
- handle - a valid handle
- screen - a valid pointer to an opened Screen
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWriteName
-
- SYNOPSIS
-
- ULONG SVL_SetWriteName(APTR handle, ULONG write_name, APTR future)
- D0 -$7e A1 A2 A3
-
- FUNCTION
-
- Sets the write_name for a SVL_SuperWrite() call.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- write_name - a valid AmigaDOS FilePath and -Name description
- future - always NULL yet
-
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FileInfoRequest
-
- SYNOPSIS
-
- ULONG SVL_FileInfoRequest(APTR handle, struct Window *window,
- D0 -$84 A1 A2
-
- APTR future)
- A3
-
- FUNCTION
-
- Pops up an Info-Requester with more or less detailed information
- on the currently loaded Graphic.
- A window pointer may be given to select the place to pop it up.
-
- Note, that this function will fail, if you already called
- SVL_FreeResources() (might result in a "No file loaded" message) !
-
- INPUT(S)
-
- handle - a valid handle
- window - a valid Window Pointer or NULL
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- None known, but :
- For non-internal SVObjects SVO_FileInfoRequest() is called, thus
- if this one is buggy, ...
-
- The Easy-Requester (or whatever else it is) will usually be attached
- to IntuitionBase->ActiveWindow, if window is NULL.
- This may cause problems sometimes, so always specify a WindowPtr,
- if possible !
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- -
-
- -----------------------------------------------------------------------------
- Functions added with Version 3 - 5 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetGlobalDriver
-
- SYNOPSIS
-
- ULONG SVL_GetGlobalDriver(struct SVD_DriverNode **driver,
- D0 -$8a A1
-
- ULONG future)
- A2
-
- FUNCTION
-
- Gets the Global Default ScreenDriver (SVDriver) from the
- specific field of SuperViewBase.
-
- Always use this function. Do not access SuperViewBase directly !
-
- INPUT(S)
-
- driver - a pointer to a SVD_DriverNode pointer
- future - always NULL yet
-
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 3 of the superview.library.
-
- SEE ALSO
-
- SVL_SetGlobalDriver()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetGlobalDriver
-
- SYNOPSIS
-
- ULONG SVL_SetGlobalDriver(struct SVD_DriverNode *driver,
- D0 -$90 A1
-
- ULONG future)
- A2
-
- FUNCTION
-
- Sets a new Global Default ScreenDriver (SVDriver) in the
- specific field of SuperViewBase.
-
- Always use this function. Do not access SuperViewBase directly !
-
- INPUT(S)
-
- driver - a pointer to a SVD_DriverNode
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 3 of the superview.library.
-
- SEE ALSO
-
- SVL_GetGlobalDriver()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_ReadToGfxBuffer
-
- SYNOPSIS
-
- ULONG SVL_ReadToGfxBuffer(APTR handle, char *filename)
- D0 -$96 A1 A2
-
- FUNCTION
-
- Reads the graphic file - specified with filename - into
- a SV_GfxBuffer structure.
-
- Access to this structure can be managed via SVL_GetGfxBuffer().
-
- The combination SVL_ReadToGfxBuffer() and SVL_DisplayGfxBuffer()
- has the same effect as a call to SVL_SuperView().
- But note, that GfxBuffer-functions only work with Version 2
- SVObjects, while SVL_SuperView() also fits to Version 1 SVObjects.
- Internally, the result is the same, anyway.
-
- INPUT(S)
-
- handle - a valid handle
- filename - a valid AmigaDOS FilePath and -Name
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- This function was broken from V3.x to V4.x !
-
- SINCE
-
- ... version 3 of the superview.library. (request V5+)
-
- SEE ALSO
-
- SVL_GetGfxBuffer(), SVL_DisplayGfxBuffer()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetGfxBuffer
-
- SYNOPSIS
-
- ULONG SVL_GetGfxBuffer(APTR handle, struct SV_GfxBuffer **buffer,
- D0 -$9c A1 A2
-
- ULONG future)
- A3
-
-
- FUNCTION
-
- For READ accessing the SV_GfxBuffer structure, which has been
- created with SVL_ReadGfxBuffer() before.
-
- Do not change, write to or free this structure by hand.
- Nevertheless you may create your own structures.
-
- INPUT(S)
-
- handle - a valid handle
- buffer - a pointer to a valid SV_GfxBuffer pointer
- future - always NULL yet
-
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- This function was broken from V3.x to V4.x !
-
- SINCE
-
- ... version 3 of the superview.library. (request V5+)
-
- SEE ALSO
-
- SVL_ReadGfxBuffer(), SVL_DisplayGfxBuffer()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetGfxBuffer
-
- SYNOPSIS
-
- ULONG SVL_SetGfxBuffer(APTR handle, struct SV_GfxBuffer *buffer,
- D0 -$a2 A1 A2
-
- ULONG future)
- A3
-
-
- FUNCTION
-
- This functions allows you to pass your own, self-created
- SV_GfxBuffer structures or also structures accessed via
- SVL_GetGfxBuffer() to the library.
-
- This will overwrite a previously done SVL_SetWriteScreen() call.
-
- The next SVL_SuperWrite() call will use the supplied SV_GfxBuffer
- as the source for creating the destinaion graphics file.
-
- The structures still have to be freed the way they have been
- allocated : - self-created : ...
- - SVL_GetGfxBuffer() : SVL_FreeResources(),
- SVL_FreeHandle()
-
- INPUT(S)
-
- handle - a valid handle
- buffer - a valid SV_GfxBuffer pointer
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- WARNING
-
- Before V6 the documentation said under FUNCTION :
- "If also a valid Screen Pointer is supplied, the SV_GfxBuffer
- is ignored".
-
- There's no guarantee for that AND you never should supply
- TWO Sources for ONE Destination.
-
- GfxBuffer-Writing works since V6 with the supplied SVObjects
- and they do prefer GfxBuffers, NOT Screens.
- Screens have to be converted into GfxBuffers internally, before
- they can written, so GfxBuffers should take less memory ...
- Last not least : This function was broken upto V5, anyway.
-
- BUGS
-
- This function was broken from V3.x to V5.x !
-
- SINCE
-
- ... version 3 of the superview.library. (request V6+)
-
- SEE ALSO
-
- SVL_ReadGfxBuffer(), SVL_SuperWrite()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_DisplayGfxBuffer
-
- SYNOPSIS
-
- ULONG SVL_DisplayGfxBuffer(APTR handle, struct SV_GfxBuffer *buffer,
- D0 -$a8 A1 A2
-
- ULONG future)
- A3
-
-
- FUNCTION
-
- The combination SVL_ReadToGfxBuffer() and SVL_DisplayGfxBuffer()
- has the same effect as a call to SVL_SuperView().
- But note, that GfxBuffer-functions only work with Version 2
- SVObjects, while SVL_SuperView() also fits to Version 1 SVObjects.
- Internally, the result is the same, anyway.
-
- The difference is : Multiple displaying is possible
- (SVL_DisplayGfxBuffer(), SVL_CloseDisplay(), SVL_DisplayGfxBuffer(),
- ... and so on).
-
- The SV_GfxBuffer still has to be freed the way it has been
- allocated : - self-created : ...
- - SVL_GetGfxBuffer() : SVL_FreeResources(),
- SVL_FreeHandle()
-
- INPUT(S)
-
- handle - a valid handle
- buffer - a valid SV_GfxBuffer pointer
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- WARNING
-
- Only pass the ORIGINAL SV_GfxBuffer pointer to this function
- (get it via SVL_GetGfxBuffer()) !
- Currently this Buffer-pointer is not really passed through
- to the SVObjects : They always use the pointer, which they
- initialized while loading the picture.
-
- So if you would pass a pointer to an other GfxBuffer, it would be
- be simply ignored and the internal pointer would be used, if valid.
- On the other hand, do NEVER set this pointer simply to NULL
- (thinking : it'll be ignored, anyway), because this may change
- in future versions !
-
- BUGS
-
- -
-
- SINCE
-
- ... version 3 of the superview.library.
-
- SEE ALSO
-
- SVL_ReadGfxBuffer(), SVL_SuperWrite()
-
- -----------------------------------------------------------------------------
- Functions added with Version 6 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetSVObjectList
-
- SYNOPSIS
-
- ULONG SVL_GetSVObjectList(struct SVObjectInfo **listhead)
- D0 -$ae A1
-
- FUNCTION
-
- Creates a simplified list of all SVObjects (SubTypes), which
- may be used for read-only purposes until it has been freed
- via SVL_FreeSVObjectList.
-
- INPUT(S)
-
- listhead - a pointer to a SVObjectInfo structure pointer
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- This functions was slightly buggy in V6.x versions.
- The List was not chained right, so that only the last
- SubType of each SVObject was linked to the list and the rest
- went to Nirwana, so that there also was a (small) memory loss.
- This bug has been fixed in V7.1.
-
- SINCE
-
- ... version 6 of the superview.library. (request V7+)
-
- SEE ALSO
-
- SVL_FreeSVObjectList
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetSVDriverList
-
- SYNOPSIS
-
- ULONG SVL_GetSVDriverList(struct SVDriverInfo **listhead)
- D0 -$b4 A1
-
- FUNCTION
-
- Creates a simplified list of all SVDrivers, which
- may be used for read-only purposes until it has been freed
- via SVL_FreeSVDriverList.
-
- INPUT(S)
-
- listhead - a pointer to a SVDriverInfo structure pointer
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 6 of the superview.library.
-
- SEE ALSO
-
- SVL_FreeSVDriverList
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeSVObjectList
-
- SYNOPSIS
-
- ULONG SVL_FreeSVObjectList(struct SVObjectInfo *listhead)
- D0 -$ba A1
-
- FUNCTION
-
- Frees a list returned by SVL_GetSVObjectList.
-
- Pass the List-Header, not an entry !
-
- INPUT(S)
-
- listhead - a pointer to a SVObjectInfo structure
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 6 of the superview.library.
-
- SEE ALSO
-
- SVL_GetSVObjectList
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeSVDriverList
-
- SYNOPSIS
-
- ULONG SVL_FreeSVDriverList(struct SVDriverInfo *listhead)
- D0 -$c0 A1
-
- FUNCTION
-
- Frees a list returned by SVL_GetSVDriverList.
-
- Pass the List-Header, not an entry !
-
- INPUT(S)
-
- listhead - a pointer to a SVDriverInfo structure
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 6 of the superview.library.
-
- SEE ALSO
-
- SVL_GetSVDriverList
-
- -----------------------------------------------------------------------------
- Functions added with Version 7 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_RemoveSVObject
-
- SYNOPSIS
-
- ULONG SVL_RemoveSVObject(struct SVO_ObjectNode *svo_node)
- D0 -$c6 A1
-
- FUNCTION
-
- Removes an SVObject from the internal List of SVObjects and tries
- to remove it from memory.
-
- This does only work, if not more than one programm is accessing
- superview.library and the SVObject.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVOBJECT-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- svo_node - a pointer to a SVO_ObjectNode structure
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVObject-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVObjects again
- (e.g. for Write-Operations).
-
- BUGS
-
- No bugs known yet.
- But this function operates "deep in the system", so that
- there may occur interferences in very special situations
- (but usuallly should not).
-
- SINCE
-
- ... version 7 of the superview.library.
-
- SEE ALSO
-
- SVL_RemoveSVDriver
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_RemoveSVDriver
-
- SYNOPSIS
-
- ULONG SVL_RemoveSVDriver(struct SVD_DriverNode *svd_node)
- D0 -$cc A1
-
- FUNCTION
-
- Removes an SVDriver from the internal List of SVDrivers and tries
- to remove it from memory.
-
- This does only work, if not more than one programm is accessing
- superview.library and the SVDriver.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVDRIVER-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- svd_node - a pointer to a SVD_DriverNode structure
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVDriver-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVDrivers again
- (e.g. for displaying graphics).
-
- BUGS
-
- No bugs known yet.
- But this function operates "deep in the system", so that
- there may occur interferences in very special situations
- (but usuallly should not).
-
- SINCE
-
- ... version 7 of the superview.library.
-
- SEE ALSO
-
- SVL_RemoveSVObject
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_AddSVObject
-
- SYNOPSIS
-
- ULONG SVL_AddSVObject(UBYTE *name)
- D0 -$d2 A1
-
- FUNCTION
-
- Tries to open the specified SVObject (full AmigaDOS-Path) and
- attempts to add it to the internal Lists.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVOBJECT-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- name - full AmigaDOS-Path of the SVObject to add to the lists
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVObject-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVObjects again
- (e.g. for Write-Operations).
-
- Secondly, it is not checked, whether the added Library is
- _really_ a SVObject.
- Adding other libraries may result in a damaged internal
- SVObject-List in superview.library.
-
- SINCE
-
- ... version 7 of the superview.library.
-
- SEE ALSO
-
- SVL_AddSVDriver
-
- -----------------------------------------------------------------------------
- NAME
- SVL_AddSVDriver
-
- SYNOPSIS
-
- ULONG SVL_AddSVDriver(UBYTE *name)
- D0 -$d8 A1
-
- FUNCTION
-
- Tries to open the specified SVDriver (full AmigaDOS-Path) and
- attempts to add it to the internal Lists.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVDRIVER-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- name - full AmigaDOS-Path of the SVDriver to add to the lists
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVDriver-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVDrivers again
- (e.g. for displaying graphics).
-
- Secondly, it is not checked, whether the added Library is
- _really_ a SVDriver.
- Adding other libraries may result in a damaged internal
- SVDriver-List in superview.library.
-
- SINCE
-
- ... version 7 of the superview.library.
-
- SEE ALSO
-
- SVL_AddSVObject
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetFileType
-
- SYNOPSIS
-
- ULONG SVL_GetFileType(APTR handle, char *filename, ULONG *filetype)
- D0 -$de A1 A2 A3
-
- FUNCTION
-
- Finds out superview-specific FileType-Code
- (redefined with every re-initialization of the Library) or
- SV_FILE_TYPE_UNKNOWN (== NULL == FALSE).
-
- Use the following call for a simple check :
-
- handle = SVL_AllocHandle(N);
- sverr = SVL_GetFileType(handle, filename, &filetype);
- SVL_FreeHandle(handle);
-
- This handle should NOT be used for any further operations
- on the file (will be opened and checked twice but only
- closed once, etc).
- Initialization operations are allowed nevertheless
- (e.g. SVL_InitHandleAsClip() ).
-
- Note, that this function fills in FILETYPES, not SUBTYPES.
- For e.g. writing you must specify SUBTYPES
- (ILBM-0, ILBM-1 or GIF87, GIF89a).
-
- FILETYPES are only for short identification and do only
- specify the global file type (ILBM, GIF, PCX).
-
- INPUT(S)
-
- handle - a valid handle
- filename - a valid AmigaDOS FilePath and -Name
- filetype - pointer to ULONG for SV_FILETYPE-Value
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 8 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle(), SVL_FreeHandle()
-
- -----------------------------------------------------------------------------
-