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
> objects in a low level way and order of the fields could be important.
> 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
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted