Marcel Kilgus writes:

> P Witte wrote:
> >> But I can change everything....
> > Oh yes? ;))
>
> "Can", not "will" ;-)

I knew I must be dreaming.. ;)

> > One "very" "simple" "improvement" that could be made to MAWDRAW
> > would be to allow it to take an address instead of an array. The address
> > would point to a data area with the following structure - which you will
> > recognise as the last part of a Menu Application Window Definition:
>
> Well, MAWDRAW are 1000 lines of code that are not exactly easy to
> understand, I'd rather not dig too deep in there. And quite frankly, I
> guess nobody except you would know how to use it.

You know best. Its just if it were easy to do.. Youre probably right that it
is not very useful.

> Plus if one really needs it, it could probably just be done by a few
> POKEs, MWDEF does return the working definition after all. This would
> be the equivalent to MAWSETUP, the menu can then be drawn using
> MAWDRAW. Just speaking freely, no idea whether it really works, of
> course.

I agree it should be possible.

> > This would allow extra flexibility when needed to produce 1)
2-dimensional
> > lists with the exact number of elements (not rounded up as now)
>
> Rounded up?

For example, if you have 10 items to display with three items per line, you
have to supply the data in a two-dimensional array, eg DIM arr$(3, 2, 10).
arr$ has 12 elements, not 10, so you get two unwanted places tacked on the
end. This is not a feature of Wman but of EP having to use arrays. Not a big
deal, but it has just that whiff of mickey mouse technology to it.

> > 2) Mixed object type lists,
>
> MAWDRAW can do this, can't it?

Sort of. I forgot you could also specify string objects using the '@»' & adr
construct.

The latter is an unfortunate scheme though. It may have been ok-ish in the
sub 16Mb days, but with more than 16Mb memory you get rounding errors on the
addresses! (unless suitable precautions are taken). Why didnt Albin just use
floating point arrays for this, I wonder?

> > 4) Turbo-compatible lists with DIY slicing,
>
> As a workaround for this, how about a command that somehow explicitly
> creates a header for an array that has sliced indexes? Just a thought.

But how would you pass that descriptor to a command? Its possible if the
relevant commands that take array parameters could simply take the
descriptor instead, but they dont. Ive used a similar idea for a different
reason, so Im pretty sure the concept is sound.

Per

_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to