World: r3wp

ok, thanks guys ..

Put your glasses Izkata : it's the link I just gave ;-)

again :-) two questions:

1. if I use word-browser and evaluate an example, a rebol command 
promt will open (usually) and show the example .... shouldn't it 
be possible to close this example prompt window without closing the 
word-browser as well .... maybe this is just a problem on my system 
- I don't know

2. certain programs on viewtop close immediately after starting them 
or some part - eg. Canvas.r or also under viewtop in the Rebol Tools 
folder Rebol Logo, DL or Icon Maker .... on the command prompt with 
canvas.r one can see that the programs return immediately instead 
of staying in the event-loop and when typing again 'do-events it 
returns immediately as well


I tried now the current view 1.3.1d and there happens the same in 
my system. Has anybody an idea ?

What is your OS ?

DideC - I slept through my alarm this morning.  Me so tired...  =^.^=

My OS is WinXP Pro.

1. No the console window can not be claused without quitting the 
application

2. If you click on "Rebol Logo maker" in Viewtop, do you see the 
text window. What hapens exactly ?

I see the note what I can do with the logo maker and then should 
appear the logomaker window. I used to see this (maybe in an older 
version, don't know any more).

@1. this is what I would have thought too, but on the other side 
that's kind of bad, because evaluating an example might be frequent 
and the word-browser window shouldn't close - so maybe it has to 
be done differently then. Maybe I should post this also to another 
group, just wanted to know whether this happens everywhere.

This is not an "only" word-browser problem. Anytime you use 'print 
or 'probe, console apear and stay untill you quit.

2. Look very strange. Have a look to your %user.r and %rebol.r file 
to see if there is not something hiden there.

Yes, I understand that, I just haven't been sure about it - and it's 
bad useability - where do you think should it be noted (Rambo ?, 
Carl only ? ... )

2. I check this .... there is indeed some stuff which might interfere

You deal with code here. isnt the console-window your friend anyway?

2. do/args %tools/anamonitor.r false
I had this inside - and without it it works ... ?

Volker: what I think it should be like is, that you have during coding 
always the word-browser open and if we have the option to evaluate 
the examples by mouse-click we do so .... but do this a couple of 
times and you have a window mess, so closing them seams natural, 
doesn't it ? :-)

i understood the console-window pops open, and there is only one. 
sho i misunderstood something.

i have only the console open and all examples print there. how did 
you made multiple windows, is there some vid-example?

ääähmm :-) I was too fast with the many windows, there is just one, 
you're right in this case (i apologize for the wrong comment)

nevertheless closing it shouldn't close the wordbrowser - at least 
would be nice without it

without it = without closing it

2. just to end this question: with anamonitor 3 it's working

no, it must. its the "rescue the programmer"-window. if something 
goes mad, close this window, phew. thats why debug-scripts have always 
a print "console" on top.

(my debug-scripts)

but maybe it would be something for an article, placed there, for 
newbies. its prominently placed. people who try /desktop first time 
will click there too, and then your arguments are right.

btw word-browser could also be linked from documentation.

well, I still don't like it as somehow this is a kind of hidden connection 
which one doesn't expect - kind of "if something is on the screen 
it should be obvious what's going to happen if I do this or that" 
:-)

maybe popping the console up immediate, with some note in it? "this 
is the rebol-console. here you see results of examples"?

might make sense, at least according to the principle I meant above


actually I think it really wouldn't be that simple, because it is 
only one process and as you mentioned above it's a console-window 
and the only windows I know which would be closeable easily are view 
windows and the console seams to be none in this sense

The ability to evaluate code examples in the word browser was done 
without inserting a "proxy" print statement, or probe, or others, 
and the code examples were not updated either. It's a bad solution 
for now; just a first step.

It's good to hear complaints like this though. Thanks!

*smackme* how about using Cyphres view-console? That should be good 
enough for examples.

then print etc are catched quite nicely.

Yes, that might work Volker. The first thing to do is make all the 
code examples consistent and define the standard for how to write 
them, so we know which "output channels" we need to handle. e.g. 
Carl put in a proxy for the VIEW function, so examples that use it 
would do a VIEW/NEW automatically.

another idea: we have launch now in reblets. its no problem to write 
examples to files and run them standalone now.

another thing to add would be: a shortcut to get always quick back 
into the search field (like just press #"s") - if it's not yet there

Yes, but we don't want every example popping up a new window. I think 
it's better to limit examples to using PRINT and catch that to display 
in an output field of some kind, probably along with the code that 
generated it; a simulated, read-only, console.

best way to get the active window if more View windows are open?

hmmmm... IIRC you get an de/activation-event and could track that? 
others may have better ideas.

was thinking about that, but maybe there would be something like 
focal-face?

i don't know. but i am no full guru in that details.

No better idea here.

If anyone wants to know how DO EVENT works in WAKE-EVENT, then they 
might find this script interesting:
http://www.lexicon.net/antonr/rebol/gui/mimic-do-event.r

You can see it working here:
do http://www.lexicon.net/antonr/rebol/gui/demo-mimic-do-event.r

Purpose: {Mimic DO EVENT (which is called in wake-event) with a mezzanine 
function of our own.
	The mimicry is good for two things:
	1) as a document of how DO EVENT works inside

 2) as a way of achieving crazy magical tricks not otherwise possible, 
 like 
	   - faces transparent to events

    - restoring and saving facets of iterated faces before and after 
    events are sent to them 
	     (see shell-list.r)
}

Currently shell-list, with the help of mimic-do-event, is iterating 
buttons and toggles, and they operate just like standalone buttons 
and toggles. If you've tried putting buttons and toggles in a list 
you know it is not easy to achieve.

I've just submitted a patch to RAMBO which should allow progress, 
slider and scroller to also be iterated without problems.

Anton, I saw what looked like buggy behaviour in the very bottom 
gui elements in your example, the iterated slider's I guess.   Pressing 
in various slider areas in random sequences I had redraw problems 
and movement of the upper slider when pressing in lower sliders.

Anyone here use Ammon's drop-down.r?

No. Does it have an advantage over the one in VID?