World: r3wp

unview/all must go

(did not test, but hide-popup replaces unview)

Does not seem to work either :-(

then perhaps we have a bug?

hide-popup first, then unview/all; but it is an unsupported thing 
you are doing, so you may actually need to reset the internal state. 
I can hunt it down for you if you need me to.

Thanks....But that still hangs for me under 2.7.6.

  rebol []
  hide-popup
  unview/all
  view layout [button "butt" [request-list "req" [1 2 3]]]


I'm actually tracking down a bug report from a live application .... 
I know it's an unlikely sequence of events, but someone out there 
tried it. It'd be good to have the magic to make it work when they 
try again :-)

I got it ! (this old $#%& of a bug.)

WAKE-EVENT DO EVENT is normally expected (via some GUI action) to 
do HIDE-POPUP, and WAKE-EVENT usually

straight afterwards fixes up SYSTEM/VIEW/POP-FACE (ie. setting it 
to NONE when all requestors are closed).

However, when this process is interrupted in DO EVENT (by pressing 
Escape in the console),
then this fix-up is skipped, and POP-FACE remains set.

So HIDE-POPUP, issued at the console, will not fix POP-FACE (eg. 
set it to NONE).

This means the next VIEW -> WAKE-EVENT will act as if there is a 
requestor open, and return the wrong

result (FALSE, because the incorrect POP-FACE is not found in the 
correctly empty POP-LIST),
and therefore WAIT will return immediately.


The one-line solution seems to be to patch WAKE-EVENT to fix POP-FACE 
when it's not found in POP-LIST,
just before POP-FACE is checked.


 if all [pop-face not find pop-list pop-face][pop-face: none] ; <--- 
 Added by Anton. Fix POP-FACE when it's not found in POP-LIST (eg. 
 HIDE-POPUP was done at the escaped console, not by WAKE-EVENT DO 
 EVENT, as usual, here).
	either pop-face [ ...

Here is the magic patch. Please test and see if it works for you. 
I've only tested it lightly.

system/view/wake-event: func [port /local event no-btn] bind [
    event: pick port 1
    if none? event [

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

 if all [pop-face not find pop-list pop-face][pop-face: none] ; <--- 
 Added by Anton. Fix POP-FACE when it's not found in POP-LIST (eg. 
 HIDE-POPUP was done at the escaped console, not by WAKE-EVENT DO 
 EVENT, as usual, here).
    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

A little bit of dancing is required here.

Dancing complete. I am now in a state of expectation of the thunderous 
rain of blessings to be cast upon me.

That works!

Thanks Anton, and Gabriele and Henrik for the help....Especially 
Anton for the fix!
I think the honor is yours in entering it into RAMBO :-)

That's hardly the "thunderous rain" I was expecting, now, is it ? 
;)

Seriously, it needs more testing, especially with nested popups. 
Anyone got a nested popup example handy they want to try it on ?

Thunderous rain.....It's impossible to get the kudos you need from 
just debugging :-)

Which one of us has  not worked all night to solve a critical problem; 
and the only real reward is to see that no one even notices when 
they come to work in the morning?

This is really valuable, so make sure it gets posted somewhere that 
it won't scroll off an be lost.


It's fantastic stuff Anton, but only a few people can appreciate 
it. :-\

The problem is, it just looks so simple at the end, as you can see 
in this one-line workaround, used after HIDE-POPUP:

	hide-popup
	system/view/pop-face: none

It just took me ~3 hours to find it, whilst entertaining all sorts 
of other hypotheses.

Gregg, I have it saved in a file, and this group is web-public, at 
least.

I spent nearly as long reducing the problem to my 3-line bug report 
:-) It could have been any one of several other issues in the actual 
application.

Anton, it could and should also live on in RAMBO and the code base 
for REBOL3.
Do you want to RAMBO it, or will I?

the pop-face: none was what I meant for "resetting the internal state", 
but I would have needed to look at the code to find out what was 
necessary to do.

Anton, did you look at the commented SDK source, or probed around? 
The former could have been faster (not that that code is very readable...)

Sunanda, Ok, I'll submit it to RAMBO as is. (I don't think it has 
much relevance with R3, though.)

Gabriele, Ah.. I forgot to look at the SDK, actually. I'm not in 
the habit of it.

To track it down, I patched all functions (and relevant, nested helper 
functions) involved in Sunanda's example code: VIEW REQUEST-LIST 
INFORM SHOW-POPUP HIDE-POPUP and finally WAKE-EVENT. I added 30 print 
statements to all those function bodies (making sure to bind them 
correctly etc), tracking the control flow, then compared the output 
before and after escape was pressed. Eventually I found the difference 
in control flow in wake-event (EITHER POP-FACE ...).

Submitted "wake-event pop-face patch" to RAMBO.

Anton - what about submitting to DevBase?

Done.

Nice timeline widget in dhtml http://simile.mit.edu/timeline/

It is cool, and it seems to get posted about once a year...

So, has anyone attempted rewriting it in View?

Don't know.  
We plan to do a version of it for our Gantt.

timeline is part of MIT's SIMILE project.

Took me ages but I finally managed to get a version of timeline running.

but because of the async calls, the Rebol micro-webserver can't serve 
the pages correctly.

Works fine with Cheyenne though.

Here's an xample of timeline using embedded json data http://www.compkarori.com/timeline/timeline.html

All the samples i saw used external data sources.

can rebol evaluate two user input events at the same time?

all input events are queued.

I'm trying to build an interface similar to the one in Plan 9 OS, 
but I've hit this snag. when the left mouse button is down the system 
doesn't register right mouse button clicks. Can this be worked around 
somehow?

is there any way to handle alt keys?

is there a way to do mouse chording?

Re; keys.   yes?   Play around with something like
rebol []
set-modes system/ports/input [lines: false]
while [
    code: input
    code <> 13
][
    probe code
]
set-modes system/ports/input [lines: true]
print "--"


But I'll admit to being confused.   Ctrl-A returns 1, Ctrl-B returns 
27, 91, 49, 126, Ctrl-C bails, Ctrl-D prints 4

Alt-A 27 27 97, Alt-B 27 27 98    On my Debian GNU/Linux box 2.7.6

Brian, I think he's asking about View, not the console.

Nicolas: the mouse buttons problem may be OS related, but I never 
tested this.

Mouse chording would require the mouse event system to be able to 
express multi-button mouse events. I'm not sure if R2 has such support 
(or R3 either but we can fix that). Windows and Linux's event models 
support chording, though most apps don't use it. Though I don't know, 
I would be surprised if Mac OS X's event system supported chording 
- it barely supports more than one mouse button.

Yep, I was suggesting that as a method to get at the codes that View 
might return, but yeah you are correct and now I'll ask, is it a 
different keyscan engine?  Core vs View?

BT, the codes you see at the console are ANSI escape codes, and that 
has nothing to do with what you get from view, eg. the "home" key 
sends the 'home word in View but an escape sequence on the terminal.

I stand corrected then.  ;)