Hi Norman,
I can understand this, up to a point, but there must be some validation
that could be done perhaps, especially now where we all have (ahem) much
faster machines.
Maybe.
My problem was in part caused by my error of having the offset to the
menu item status bytes set to zero - surely it would be a simple matter
to check that this should not have been the case if I had any rows
specified, for example?
What if you wanted to poke this in later?
The things is, we're talking about data structures here. There is
nothing to stop you, for example, from setting up the general framework
first, and then slotting in the pointer to the memory which you might
only want to allocate later.
The problem with error checking is that you then make assumptions about
what would be "reasonable" (e.g. not having a null pointer there) - but
which others might not find reasonable.
Again, defining what is "wrong" in this context is difficult. You might
find it wrong that WM.SETUP doesn't raise an error if the pointer to the
status area is 0,I might not find this wrong since I haven't allocated
the corresponding memory yet.
This is especially so in the case of menu appsub windows, where WM.SETUP
vector itself doesn't setup the appsub window. Rememberfor appsub wdws
the programmer is supposed to supply his/her own setup routine, which
WM.SETUP then just calls. How can it know what the programmer will want
to do in that routine?
Admittedly, most programmers wanting to setup a menu appsub window will
probably use vector WM.SMENU, so the problem is just displaced from
WM.SETUP to wm.smenu - yet, even there, the same comments as above apply.
> Obviously, I'm not asking anyone to do it, but if anyone was making
> changes in this area, it might be a worthwhile exercise to consider
> what, if any (other) validation checks there are that might be of some
> use. A bad parameter return would be better than nothing went wrong?
I'm always open to suggestions of course. However, to my mind this is
not a bug. I don't want to sound unsympathetic to your remarks, I just
don't really agree with them.
What I would suggest, if anybody wanted to make these kinds of changes
is that they do not do it on the original vectors but create new ones,
so as not to break something that works (well, sort of as you'd probably
say...). The new vectors could then be incorporated into SMSQ/E.
HTH
Wolfgang
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
