Re: preparation behaviour of group

Klaus Hofrichter (hofrichter@fokus.gmd.de)
Fri, 30 May 1997 10:41:50 +0200

Wataru KAMEYAMA wrote:
>
> Klaus,
>
> First of all, I don't think we need the amendment process on the issue
> you raised.
>
> > There are some "legal" workarounds:
> > * Use of the Preload action: The intention of this actuin is related to
> > content. As a sideeffect, it calls the "preparation behaviour". But,
> > preload is only a "hint".
>
> Preload() is exactly included for this purpose. If you look at the
> requested actions by Preload(), you can find that applying preparation
> behavior is mandatory for the engine as the first action. The "hint"
> here is related to the second action, with which you may retrieve
> or/and decode the content.

So, when I want to change "offscreen" the position of a initially false
bitmap, I have to perform the "preload", right?

This is of course simple. I understood that preload is more related to
content data. The sideeffect of the delayed "preparation" is that the
attributes of the object such as the original/current position are not
legally available as well, but they are surely somewhere existing in the
engine, since it has already done the decoding.
Therefore, the example of "setData" is a very specific one.
But in the first place, I can live with that.

In this case the Provisions of use of "Ingredient::preload" has to be
changed:

"The Content attribute of the target Ingredient shall be different from
Null".

This would not allow preload (and therefore direct preparation) for
Rectangles. (ha!)

Anyway, Wataru, thanks for the fast reply.

- Klaus

-- 
GMD FOKUS    German National Research Center for Information Technology
Klaus Hofrichter     Hardenbergplatz 2      D-10623 Berlin      Germany
mailto:hofrichter@fokus.gmd.de   http://www.fokus.gmd.de/usr/hofrichter
Tel +49 30 25499-211 Fax -202  There is a reexamination, but no reparty