Strange behaviour in Make object?
[1/5] from: james::mustard::co::nz at: 13-Nov-2001 18:26
Hi, I have been writing some widgets and have noticed some rather puzzling
behaviour in the make spec.
Example1 below draws the object correctly - Example2 is a minor change but
the object no longer displays. Could anyone shed some light on this
behaviour?
Ex1: (BUILDS AND DISPLAYS CORRECTLY)
XScroll: make object! [
type: 'face
offset: 0x0
size: 0x0
span: none
pane: copy []
text: color: image: effect: data: none
max: 100
...
]
Ex2: (BUILDS BUT DOES NOT DISPLAY CORRECTLY)
XScroll: make object! [
type: 'face
offset: 0x0
size: 0x0
pane: copy []
span: text: color: image: effect: data: none
max: 100
...
]
Only one thing was changed - the [span: none] was moved to join the rest of
the none values - yet doing this resulted in the face not displaying when
later added to a window.
James (Puzzled?)
[2/5] from: brett:codeconscious at: 13-Nov-2001 17:11
Hi James,
I can't shed any light on it. But I do suggest that rather using MAKE
OBJECT! directly you use MAKE FACE
so that you are assured of having the correct View fields constructed
properly.
There is some evidence to suggest that the View engine interfaces with these
objects in a low level way and order of the fields could be important. Much
better to follow the convention.
Brett.
[3/5] from: james:mustard at: 13-Nov-2001 22:48
Brett Handley said:
> Hi James,
>
> I can't shed any light on it. But I do suggest that rather using MAKE
> OBJECT! directly you use MAKE FACE
> so that you are assured of having the correct View fields constructed
> properly.
>
> There is some evidence to suggest that the View engine interfaces with
these
> objects in a low level way and order of the fields could be important.
Much
> better to follow the convention.
>
> Brett.
>
Yup - was just curious as to why changing the order was causing issues. I
had a similar problem on another object where a field immediately following
a pair was causing display errors if it was an integer field eg:
Obj1: make object! [
var1: 0x0
var2: 1
var3: make get-style 'face [
...
]
...
]
This would also seem to build correctly but on creating a new object with
make obj1 [] the var3 would be ignored and often weird errors would result -
I had one case where a pair was being assigned to an object, seemingly from
nowhere. I swapped the order of 2 custom variables I had defined and was
surprised to find that it now worked.
Go figure ;-)
James
[4/5] from: nitsch-lists:netcologne at: 13-Nov-2001 11:49
RE: [REBOL] Re: Strange behaviour in Make object?
I think RT handles this somewhat lazy.
when accessing objects from c, its easier and faster to
do this by index instead of searching the object for name
(i think).
with 'port! they have a clean solution.
'port! is like an object, but c can check.
if its a port!, it has the right order.
if no 'port!, its rejected.
so we should have face! and that too,
instead of allowing objects there.
but i expect adding new datatypes! is somewhat expensive
in current implementation, and the only drawback
today is telling "you have to use [make face]. thats by design".
instead of checking it.
so some guis have to figure around instead of getting
a helpfull clean message.
there was
and now i give word to the experts:
[REBOL] Re: view bug (with feel attribute)
[holger--rebol--com] wrote:
> On Tue, Oct 23, 2001 at 01:07:53PM -0400, Media wrote:
> > Hi again,
<<quoted lines omitted: 12>>
> Holger Kruse
> [holger--rebol--com]
-Volker
[james--mustard--co--nz] wrote:
[5/5] from: media:quazart at: 13-Nov-2001 9:10
Exactly,
this applies to ALL objects, not just view. Since view is object built, then
it follows the same rules as any other object...
I think I've understood what happens and it seems as if they store a
vector
list. This is an array of offsets from the base object address
which in turn point to other areas in memory. each position is fixed in
order to make this system speedy. Especially since most
compilers/assemblers have instructions to calculate offset resolution in one
opcode (usually one machine instruction).
The amiga's library system is built almost exactly like this. It would be
consistent with Carl, and why change something that works well and fast!?
In rebol, I guess they build this vector list the first time the object is
defined and then just link to it everytime. Then, when a new object is
cloned and the template changes, I guess they just allocate a new vector
list with new fields APPENDED... this would make any cloned objects
completely safe to use with "parent" objects
this also looks like the Amiga library system which had two modes... the
first one returned the same data segement everytime and thus all
applications SHARED the same data, and another one where every call to open
library returned a NEW data segment but with the same vector jumplist...
this second mode looks almost like a direct translation to rebol objects...
AS usual, these are just my observations... not explicit RT answers...
hope this makes sense to all...
-MAx
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted