> >>> 3) Application window scroll bar attributes cannot be set or
> >>> changed without specifying a pre-set menu too. Part of the problem
> >>> may be with the toolkit which seems to ignore or overwrite
> >>> attributes added by hand later.
>
> This sounds a bit complicated, especially as all the application menu
> stuff has always been somewhat of a mystery to me ;-)
I think I've ran into this problem too. I gave up, assuming I was doing
something wrong. It was a long time ago, I haven't kept the example.
> Is this all? Nobody else any problems? I won't promise anything, but
> if I don't know what's wrong I certainly cannot change it.
Append sprites to a code file, put those in memory while writing and testing in
SBASIC. You'll find you can't refer to them by name while resident in memory,
only by address. Only tested with mode 4 sprites. So you have to refer to a
sprite called "mysprite" as SPRA("mysprite") instead - in other words, when
sprites are resident appended to an extensions file, you have to refer to them
by address rather than name. Last tested on the pre-Marcel v3.50 Easyptr.
I asked Albin about this a couple of years ago and he said there was an issue
with pointers to names in these situations and although he hadn't looked at the
code at the time he feared it might be a big issue and recommended I stuck to
referring to sprites by address rather than name.
To be fair, referring to sprites by name appended to an extensions file in
memory from interpreted BaSIC is not a situation which occurs often, in my case
it only happened because of the complexity of the use of sprites in Launchpad.
I am so pleased that some work is being done on Easyptr and promise I will be
one of the first in the queue to pay for an update!
I'll look forward to being able to specify system palette colours if nothing
else, although the improved handling of high colour sprites will be a useful
bonus too.
Dilwyn Jones
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
