World: r3wp

probe first system/view 
probe get in system/view/event-port 'awake 
make system/view [source wake-event] 
system/view/wake-event: func [port /local event no-btn] bind [
    event: pick port 1 
print remold [event/type event/offset event/key] 
    if none? event [

        if debug [print "Event port awoke, but no event was present."] 
        return false
    ] 
    either pop-face [

        if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
        pop 
            -face event
        ] 
        do event 
        found? all [
            pop-face <> pick pop-list length? pop-list 
            (pop-face: pick pop-list length? pop-list true)
        ]
    ] [
        do event 
        empty? screen-face/pane
    ]
] system/view 
echo on 
print "con" 
view layout [button "test" [probe "test"]]

For tracking.

Thx. So I just add this code before my app and see what's spit out?

Yes.

This is called from system/view/event-port/awake. when it returns 
false, the do-events should terminate.

so i guess it returns false on some occasions. maybe something triggers 
a none-event, that would trigger it.

then we patch it to check for a face in system/view/screen-face/pane

would be my guess. maybe he has some tool which sends something unusual 
to windows, which wakes rebol but  is not recognised, so none.

Here is what I get:
[time 73x39 none]
[time 73x39 none]
[time 73x39 none]
[down 73x39 none]
company-selected
[time 73x39 none]
[time 73x39 none]
[time 73x39 none]
[time 73x39 none]
[up 73x39 none]
>>

So, where company-selected is printed, my code is executed.

Hmm. i made a bug, the 
  print remold [event/type event/offset event/key]
only works if 'event is not none ..
But you get no error, do-events simply returns?

can you probe do-events? as it is a 'wait, maybe it returns someweird 
port.

yep

print[type? event]
if event! = type? event[ 
print remold [event/type event/offset event/key] 
]

when i close the window here, do-events returns the event-port

(above as fix for thewake-event)

can you please post the complete snippet?

system/view/wake-event: func [port /local event no-btn] bind [
    event: pick port 1
print[type? event]
if event! = type? event[ 
print remold [event/type event/offset event/key] 
]
    if none? event [

        if debug [print "Event port awoke, but no event was present."] 
        return false
    ] 
    either pop-face [

        if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
        pop 
            -face event
        ] 
        do event 
        found? all [
            pop-face <> pick pop-list length? pop-list 
            (pop-face: pick pop-list length? pop-list true)
        ]
    ] [
        do event 
        empty? screen-face/pane
    ]
] system/view 
echo on 
print "con" 
view/new layout [button "test" [probe "test"]]

probe do-events

Hmm... I now have added to records to my app and since then it works. 
What could cause do-events to exit?

usually some port returning false

claiming to be closed. seems to happen sometimes even is the port 
is not in the wait-list.

IIRC. but did not investigate further.

thats why the probe of do-eents would be interesting.

or some internal bug..

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!