Strange behaviour in Make object?

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?)

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.

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

> objects in a low level way and order of the fields could be important.

> better to follow the convention. > > Brett. >

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, > Holger Kruse > [holger--rebol--com]

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