World: r3wp

Here are some ways to use VIEW and DO-EVENTS.

1)
	view window

2)
	view/new window1
	view/new window2
	do-events

3)
	window: layout [
		button "open child window" [
			window2: layout [text "child window"]
			view/new window2
		]
	]
	view window

The thing to note is: VIEW without the /NEW refinement, waits for 
events. If you don't wait for events this way, then you have to wait 
for events yourself, using DO-EVENTS. Usually you put DO-EVENTS at 
the end of your script.

DavidR, it looks to me like you're unclear about the best way to 
order your windows. I would probably only bother the user with the 
license agreement once, the first time the program is run. Thereafter, 
jump straight into the main application window.

if not exists? %SOS-XP-user-agreed [ ; File does not exist yet ?

	view layout [
		text "You use this software entirely at your own risk."
		button "I Agree" [
			write %SOS-XP-user-agreed ""  ; Create file.
			unview
		]
		button "I Disagree" [
			print "I Disagree"
			;quit
			unview halt
		]
	]

]

view center-face layout [
	h1 "Main application window"
]

David -- you seem to have moved away from using panels of the type 
in Carl's example (sub structures in one main window) to having separate, 
independent windows that pop up when requested.

That could get confusing, as they'd all be running at once. And, 
without some positionin, they'd overlay each other.

And, as others had said, your code example has some items in the 
wrong order -- using words before they are defined.

The code below, I think, fixed those problems. It is based on Anton's 
stripped down example:

unview/all

main: layout [
    banner "main"
	button "START" [unview/only main view panel1]
]
  
  panel1: l  ayout [
  banner "panel1"

  area {You use this program & batch files entirely at your own risk}
  button "Agree" [unview/only panel1 view panel2]
  button "Disagree" [quit]
]


panel2: layout [
    banner "panel2"
	button "START" [view panel3]
]

view main

Oops -- typo in that code:
 bad::: panel1: l  ayout
 good:  panel1: layout

Anton/Sunanda many thanks for your extensive attempts to help me 
out  it is greately appreciated!  Yes Sunanda you are right I was 
not having much success in respect  of panels & was looking for an 
alternative method as there is usually more ways than one of skinning 
a cat. However your last example Sunanda, I have found it quite enlightening. 
I have a confession I have basically built the code  from snippets 
of code I have found on various rebol sites, where possible I have 
tweaked the code to adapt it to what I am trying to achieve glued 
or bolted them together in the hope it would work. This is ok up 
to a point  but I am falling down in the structure of the overall 
code/programming

hence getting things in the wrong order!

Cutting and pasting code gives you exponential problems - but of 
course you've got to start somewhere. Just getting the commonly used 
words into your head is a valuable step.

If you can get it to work as separate windows,  you have all your 
logic flow in place. It's then comparatively trivial to:
** add a panel to the main layout

** change the "unview ... view" lines into show/hides for the panels.

In fact, with very few lines of code, you could have it working either 
way according to a user preference.....I have one application that 
does that: the main panels are eiher in one window, or float free 
as separate ones.

But focus on getting it working first!

Since you are new to programming:


Beginning with an existing program like this may not be optimal for 
understanding how things work, because there are tens of things going 
on in that example. It's the understanding of the underlying principles 
that allow you to build your own programs, and beginning with a big 
example like this throws all principles in your face at once. That 
can be very confusing, like being asked to fly a jumbo jet without 
training. This is why it's so difficult for you to get this example 
to work.


What I would do: Put the program away for now and start using the 
console intensively. Write single commands or a single line of code. 
The immediate feedback from the console lets you learn quickly. The 
console is not simply a service to let you run programs: It's a powerful 
tool that allows you to LEARN. I use it every time I'm in doubt over 
what a specific command will do. The console is your friend. Don't 
be afraid of it. :-)


When you've written enough VID programs in the console, you can start 
looking at the example again, or even better: Write it from scratch 
yourself. That's the best approach.

I am havng some problem that I can't and can't understand or even 
recreate:

sample-tests2: copy [
	[ 	n "hello true"
		f [ 1 == 1	 ]
		r true
	]
	[ 	n "hello not false"
		f [ not false ]
		r true
	]
]


unit-test: func [ tests ] [ 
	foreach test tests [ 

  prin rejoin [ "===================" newline "TEST " test/n ": " ]
		print (do test/f)
		print test/r
		print (  equal? (do test/f) test/r )
		print if/else ( (do test/f) == test/r ) [ 
			" passed"	
		] [

   rejoin [ " **FAILED**" newline " expected: " mold test/r " | got: 
   " mold do test/f ]   
		]
		print ""
	]
]

I run: unit-test sample-tests2 and get

===================
TEST hello true: true
true
false
 **FAILED**
 expected: true | got: true

===================
TEST hello not false: true
true
false
 **FAILED**
 expected: true | got: true

those aditional prints are there for debugging, bot values are true 
(and before I had same problem with false) but the ( equal? ... ) 
is false .. I tried with == too

if I try anything similar in console like >> ( (do [ 1 == 1 ] ) == 
true )
== true
>> ( equal? (do [ 1 == 1 ] ) true )
== true
>> ( equal? (do [ not false ] ) true )
== true
>> ( equal? (do [ true ] ) true )
== true

I get true, but I get false in all these cases using the unit-test 
function

even the sample sample-tests3: copy [
	[ 	n "true test"
		f [ true ]
		r true	]
]

fails:

>> unit-test sample-tests3
===================
TEST true test: true
true
false
 **FAILED**
 expected: true | got: true

Difference is between 
  true --  a logic value
  'true --  a word.

Try this:

sample-tests2: copy compose/deep[
	 [ 	n "hello true"
		f [ 1 == 1	 ]
		r (true)
	]
	[ 	n "hello not false"
		f [ not (false) ]
		r (true)
	]
]

I have been looking into this for for more than an hour

hi, Sunanda.. I will try

That forces the string t.r.u.e. into being a logic value, not the 
word 'true

hm.. now it works!!

words are complicated things in rebol, they are symbols, variables 
and litterals... the problem is that two of those forms share the 
same lexical syntax.  :-(

The root problem is here:
true = [true]

so the problem is that if I write [ true ] inro block and that doesn't 
get reduced/evaluated it's a word not a logic value?

Sorry, I meant:
  true = first [true]

Compare with
  true = first reduce [true]

what kind of tool are you using ? a unit test framework ? Can you 
give me the reference ?

Then  use compose/deep as a way of effecting a reduce/deep which 
is what you need.

aha, now I get it >> do [ true ] == first [ true ]
== false

That's it!
It's a subtle REBOL gotcha.

thanks for this, I was banging my head for more than an hour...

:) well at least now I know somethinh more

janko, you are now officially starting to be an advanced rebol user 
 ;-)   congratulations  :-)

there is a tool called runit ... designed by a guy i know, if you 
can get it maybe it can help

run

not runit sorry

Maxim : wow, then this hour was totally worth it ;)

Several of us have mortar dust in our hair from such issues :-)


Run unit is available here: (Peter Wood is an expert in using it):
http://www.rebol.org/view-script.r?script=run.r

xavier, Sunanda: thanks I will look at it... I need just simple unit 
testing for now , but I will look at it to see what a bigger solution 
might be

its very easy to use :) and quite powerfull

is there any simple example of use somewhere?

i still have some sample on my laptop

i send them to you