World: r3wp

well, it's not hard to implement your own accessors

copy them from another face

correction: "it's not hard" => "it's not hard if you know what you 
are doing" :-)

I know - it is just that View 1.3.2 is regarded being a stable release 
.... but the thing is, you really can't depend upon proper style 
behavior ... it is really tiresome to still "debug" VID ....

there's a million things wrong with VID, but right now there isn't 
much to do but work around it

but that is really painfull .... I think some ppl would give-up VID 
freedom for consistency ....

then your work is turning into debuggin and finding workarounds, 
instead of concentrating upon development .... I am not sure other 
toolkits as Qt are so inconsistent ....

the thing is: what can we do about it right now? not much, other 
than either wait, or come up with sneaky solutions on our own. some 
did a solution and made RebGUI. I made LIST-VIEW, because I needed 
it and that's really the only way forward. Carl can't work on 50 
things simultaneously (or can he?) and designing a new VID, I don't 
think Carl can do that in an afternoon.

This is what we have now, and we better make best use of it, no matter 
the shortcomings

besides: read Announce and see if there are some critical VID bugs 
not in RAMBO

well, but that is new info to me, that accessors are not finished, 
yet they are used internally ...

now to do what? report new bug, or to check all styles?

besides that, I have issues with accessor's design anyway :-)

yep, it's not perfect

Carl is calling for bug to fix and (if possible) the fix for it for 
View 1.3.3.

I f you want it to be solved in next relase, just take some time 
to investigate and implemented missing accessors as you want them 
to work.

I dislike people who just go voting (half an hour) and complain during 
five years against their candidate.
On est jamais mieux servi que par soi même

accessors should not be introduced if not finished, period ....

I really start to wonder how our community does look from the external 
pov. It was my friend who got pissed, not me actually, so ...

go to RAMBO and check for my name and you will see that once I find 
a bug, I report it ... not to mention tonnes of my reports in earlier 
days ....

you should be carefull to your statements, as some ppl simply use 
REBOL as a tool, nothing more. Not like us. And to them your claims 
will become arrogant ...

btw - I have one long-standing bug there which I consider important 
to be solved, I reminded many times about it, I even (with help from 
Ladislav) tracked  down where the problem is, but still nothing, 
so :-) ... yes, the red-icons bug :-)

red icons is about ios, net view... so, you can get it fixed on new 
releases of ios, not on new releases of the sdk ;)

that is of course far from the truth ;-)

it was never fixed and it is still in Core ...

... just look at my ticket and you will find out, where is the problem 
... :-)

petr, the ticket is there and won't be forgotten. there's no problem 
with that. but, to fix the red icon problem you need more than that 
- you also need to release a new version of ios.

I am not sure about that ... we tracked down the source ... there 
is one condition actually involved ... which mistakenly fails because 
of how Core (or it is Windows, dunno), report timezone ...

I just call it "red icons" problem, but I don't relate it to IOS 
itself ......

I mean - I am interested in Core fix ... not IOS new release, that 
can come later ...

is there any other script other than ios that has problems due to 
this bug?

actually - no ... let's wait for new altme :-)

view layout [text "Test" font-color none]

This may sound silly, but doesn't one expect the text to be invisible?

Probably yes. (and doesn't sound silly).

Is there a way to have "invisible" text in a face, i.e. invisible 
text even if ALL [STRING? FACE/TEXT NOT EMPTY? FACE/TEXT] is true?

This seemed to be the natural approach; I can't come up with a solution 
to this question (driven by cure curiosity).

I don't think you can do it in a single face... but so I can understand 
the goal, why do you need it ?

ah just pure curiosity.

Here's a way using DRAW dialect text:

view layout [box navy at 30x30 text 200x30 effect [merge draw [pen 
0.0.0.255 text "hello there"]]]

Actually, my idea was to have a FIELD style with DRAWn text without 
having to write my on CARET-TO-OFFSET and OFFSET-TO-CARET as mezzanines. 
Maybe that's a bit over-the-top, though.

Well, the font color could be the same as the background colour - 
effectively invisible.

You would have to change it when the field was selected/unselected 
though...

Mmm....

Put a feature request in Rambo (if it's not there already). I am 
sure I also wanted to use such a feature before for such things.

Yes, I'll do so, Anton.

But, then, such things may change with the upcoming rich-text support, 
so I think I'll first evalute the possibilities this will bring us.

You dont need to measure in the same face.

measure ?

CARET-TO-OFFSET and OFFSET-TO-CARET

Hi Anton, about the list bug with sqlite. We were both right. It 
_is_ a series copy bug. And it _is_ an sql problem ... sql reuses 
the series it has given as a return value on the next call :-(