World: r3wp

Yes would like to get around to using it (RebGui) but would like 
to understand the background mechanics a bit more sorry about the 
laymans terminolgy but know very little about programming

Sorry, right from the REBOL console >> source inform

I think I will need to approach this from a different angle will 
try out some other scenario's

but many thanks for the help

Anytime

Graham, 

	panel1: view layout [ ]  

*is* defining the layout.


It's also opening it as a window and waiting for events, of course.
Remember VIEW just returns the face that it was given.

Yes, DavidR, it's important to post simple examples. The bugs are 
laid bare when the irrelevant stuff is not in the code. The images 
and timer stuff is not essential, for instance - you didn't need 
to post that. Anyway, we expect that you try with the non-essential 
stuff removed before posting. Often, then we can just glance at it 
and tell you what's wrong immediately.

Looking at the code, I think you would have been confused by the 
fact that the first VIEW waits for events. You have a button in there 
that does SHOW PANEL1, but PANEL1 could not have been set yet in 
this invocation of the program. That means, if you start this program 
in a fresh console it will fail, complaining about panel1 not having 
a value, or, if you had earlier managed to do the panel1 definition 
code in an earlier version of the code (but still in the same console 
session), then you would be shown that earlier panel1 version, of 
course!

I have the habit of occasionally throwing away the console session 
and starting fresh, to see if I've accumulated any bugs of this nature. 
It's easier to fix them when you notice them earlier.

DavidR, here is your program, with the irrelevant stuff removed.

rebol [Title: "SOS-XP"]

view layout [
	button "START" [show panel1]
]
  
panel1: view layout [

  area {You use this program & batch files entirely at your own risk}
  button "Agree" [show panel2]
  button "Disagree" [quit]
]
do-events

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

So now it's clear as day that everything is out of order.

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...