World: r3wp

In a fresh console, does


>> do http://www.rebol.org/download-a-script.r?script-name=clipboard.r
write clipboard:// "Test" read-clip
connecting to: www.rebol.org
Script: "Clipboard" (10-Dec-2008)
== "Test"

work? Which Rebol version do you use?

REBOL/View 2.7.6.3.1 14-Mar-2008

Just to be sure I'm using it right...
 do %clipboard.r
>> clip: read-clip
** Script Error: h.desktop-window has no value
** Where: read-clip
** Near: require h.desktop-dc: get-dc h.desktop-window
require

Write-clip works

read-clip with text works

can't read-clip on bitmaps

it never worked with bitmaps

Doh. Silly typo introduced by refactoring. Updated script. Works 
with bitmaps again, now.

Hopefully, for you, too now, that is.

Nope...same error!

rebol does not use the vista default browser... can anyone tell me 
what I must do for it to work?


even altme is using explorer, although every thing is set to firefox... 
even mime types.

it works everywhere except in rebol-related apps  :-(

Strange.  Rebol is using the default browser for me running on Vista.

damn, graham told me it worked for him too!

my install is very standard on top of it.  i don't play a lot with 
the os... it just breaks everything.

Funny, I tweak EVERYTHING... =D

If you just look at my desktop you'd think I was running 2K not Vista...

Alan, what I did was updating the script on rebol.org, so if you 
get the exact same error message that's likely turning into a caching 
problem now. The script doesn't even contain the word H.DESKTOP-WINDOW 
anymore, so, if your original error (which is confirmed) persists, 
it should at least lead to different error message. Of course, I'd 
rather see it being gone. Would you mind ching the script you're 
using for version 0.3.1, dated 18-12-2008?

ching = checking

Maxim, if Vista has a registry too, then you might have the same 
problem, Graham had, and that he just fixed. See group DevCon2008 
and this:

http://newoldthing.wordpress.com/2007/03/23/how-does-your-browsers-know-that-its-not-the-default-browser/

ChristianE, I downloaded again and it works! This is great! I had 
use of this for a few apps in the past but had given up. I love it!

Thanks a lot.

John, Vista does have a registry.

Thanks, Alan, good to know it works for you.

A View problem:

rebol []
  unview/all
  view layout [button "butt" [request-list "req" [1 2 3]]]
  
Sequence:
1. run the above code

2. click "butt" to get the pop-up request list. Do not interact with 
it! instead:
3. return to the console window and hit esc
4. run the coee again

Result:
 a stuck window
 

Any ideas what I need to do in addition to the unview/all to disable 
whatever the request-list is waiting for?

does hide-popup work?

Sadly, not -- at least not when used like this:

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

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.