World: r3wp

if you  added data and it works, sounds like something memory-related. 
changed memory-layout, other part is hit.

Maybe that guy where it always fails could be interesting for RT?

do you have any ports in the wait-list, with an awake function that 
is not returning false? note that if you return none it does not 
work, only with false wait will continue waiting.

I use Ashley's SQLite stuff, but don't expect it to use any ports. 
Than I use RebGUI (don't know if this uses any ports).


I used Volker's snippet and while it spits our messages, the app 
works. As soon as I remove the code, it fails again.

I add the probe do-events and here is the result:
probe do-events

make port! [
    scheme: 'event
    host: none
    port-id: none
    user: none
    pass: none
    target: "events"
    path: none
    proxy: none
    access: none
    allow: none
    buffer-size: none
    limit: none
    handler: none
    status: none
    size: none
    date: none
    url: none
    sub-port: none
    locals: none
    state: make object! [
        flags: 4719107
        misc: none
        tail: 0
        num: 1
        with: "^/"
        custom: none
        index: 0
        func: 12
        fpos: 0
        inBuffer: none
        outBuffer: none
    ]
    timeout: none
    local-ip: none
    local-service: none
    remote-service: none
    last-remote-service: none
    direction: none
    key: none
    strength: none
    algorithm: none
    block-chaining: none
    init-vector: none
    padding: none
    async-modes: none
    remote-ip: none
    local-port: none
    remote-port: none
    backlog: none
    device: none
    speed: none
    data-bits: none
    parity: none
    stop-bits: none
    rts-cts: true
    user-data: none
    awake: func [port][wake-event port]
]

does this help in any way?

Can I probe the wait-list?

scheme: 'event

that is the event-port

seems the wake-eventreally returns something wrong.

for tracing, can you change the prints to appends to some log-block? 
so that the printing does not interfere?

What happens if you call do-events again? if that works, something 
like
  while[same? system/view/event-port do-events][]
as workaround?

Looks like we (Cyphre and I) found it. Seems to be a problem in combination 
with RebGUI and Anamonitor in that the event system is somehow patched. 
I will test it further and let you know.

There are problems with TOG: When pressing a TOG, sometimes the outline 
doesn't disappear like it should, making the TOG appear to only darken 
and not be pressed. This has confused some of my users a lot. I haven't 
been able to find it in RAMBO. Should I create a ticket?

I don't use tog .. but different buttons images for button instead 
:)

well, I kind of use it everywhere and since it's a standard VID it 
should behave somewhat correctly. :-)

Example?

Ok I see it. Click and drag away from the tog and the gold outline 
remains.

yes

it should probably respond to 'drag as well as 'up

(damn! I knew that frivolous stuff would cause trouble.)

I think all the supporters of hover effects should get together now 
and fix this bug. I'm not touching it.

it's that dangerous? :-)

I should probably chill out a bit. Been working too hard lately.

hmm... are there circumstances where function! will become undefined 
when using stylize/master? I'm doing a bit of optimization by replacing 
DOES, HAS and FUNC with MAKE FUNCTION!

and when I define the third face, FUNCTION! is suddently undefined.

....
    data: 0
    row: 0
    source function! ;<--- defined
  ]
  list-view: BOX with [
    source function! ; <--- undefined
    hdr: hdr-btn: hdr-fill-btn: hdr-corner-btn:
    lst: lst-fld: scr: edt: pup: pdn: none
....

This works nice in a fresh console :

l: layout [ box with [source 'function!]]

tried that here too and works. what about 3-4 different faces in 
the same block?

the funny thing is that it's rendered undefined at the same point 
every time the code is loaded.

faces or facets ?

from the same console

l: layout [field text "toto" text-list  box with [source function!]]]
; works too

I guess a typo somewhere in your code, search for "function" in all.

>> do %/c/rebol/list-view.r
Script: "VID LIST-VIEW Face" (19-May-2006)
function!: function!
function!: undefined
** Script Error: function! has no value
** Where: stylize

** Near: color: make function! [] [select colors either fill ['even] 
['background]]
>> source function!
function!: function!
>>

found it

thanks

typo?

acquire-func: [] was turned into acquire-make function!: []

the joys of search and replace :-)

:-)

it was not where I expected it though. the make function! that came 
immediately after it seemed to work. oh, whatever :-)

make function! is an optimization compared to has, does and function, 
but not so much so compared to func. For now (REBOL 2) func is a 
simple wrapper around make function! that does nothing to its arguments 
- the only overhead added is that of a single function call.


You should also keep in mind that the syntax of make function! will 
be changing in REBOL 3, so all code that uses it will require some 
changes. The syntax of func, has, does and function will remain the 
same.

thanks, I'll keep that in mind

Hmmm. I thought they were basically the same. Good info.

Yes, I think it is not worth to use make function! as the 'speedup' 
could be noticable only if you are creating many functions in a loop 
at runtime. The functions are usu created only during loading of 
your script  so I don't see any optimization gain here.

usu=usually

I usually use func because it has the least overhead.

REBOL 2:
    make function! [args /local locals] [code]
REBOL 3:
    make function! [[args /local locals] [code]]

Not much of a change, really, but code using func will still work.