It could be useful to know the
storage memory's structure.
Optimizes the storage memory without any intermediate dialog.
It is a bit annoying, when an addin recurrently uses storage memory, receives
a memory-low error someday because of deleted wastes and forces the user to do
an optimization manually. Perhaps a program-controlled SMEM-optimization could
come in handy.
Syscall 0x019F cannot be called out of an addin without special precautions,
because most probably the addin's code is elsewhere after optimization. Hence
the addin will crash, when returning from SMEM_Optimization.
But it is possible to call it out of an optimization-proof place (this can be
the stack!(tested), perhaps the main-memory(not tested yet)), call
App_RegisterAddins afterwards and finally restart the addin with App_Start.
All this has to be implemented as
assembler-code (*.SRC).
Additionally the second callback-location, which defaults to OnAppCloseDefault,
has to be accounted for. OnAppCloseDefault is part of the addin, too, and
would crash after optimizaton.
OnAppCloseDefault calls the code according to the first callback-location (if
defined), deinstalls the user-timers, closes the SMEM handles, calls syscall
0x218 (close find-handles) and finally jumps to syscall 0x244 (Bkey_SetAutoRepeatDefault).
Normally the pointer to the second callback-handler can be set to zero.
Retrieves the current position of an opened storage memory file.
xhandle is the Bfile-handle & 0xF0FFFFFF (0..4).
pos should be initialized with -1.
Returns the remaining bytes.
Returns a negative value, if an error occurred.
(19.03.2011 12:42:45)