World: r3wp

next time :)

so according to btiffin I am working back to front (panel3 then panel2 
then panel1 then the main layout)

doesn't matter the order

remove the do-events

panel1 ... 3 are objects, which are returned by layout

you must define them before you use them

panel1: view layout [ ] is not defining the layout

EEK! If I remove the do-events the buttons do not work then, this 
item was suggested by Henrik & it fixed the broken buttons

Yeah DavidR;  the order doesn't really matter as long as the definitions 
come before REBOL has to reduce the value.  REBOL will let you make 
and load values (simply word! at that stage), but these words have 
to have a value when evaluation (reduce, do, ... or show in this 
case) is required.

Next...

Then change the show panel1 to view panel1  after   panel1: layout 
[ ... ] is used to create the face object.

And you still need view on the main   ...  so I take back what I 
just said ... the main view sets up the do-event event handler for 
all the faces.  (not tested so just rambling now)

You may need view/new  etc...   there are a few options for sub-windows.

see hide-popup  for a way of closing sub windows

Tell ya what without all the code clonk inbetween & as a structure 
can you provide a simple layout. Yes tried view /new for opening 
another window with the previous set behind I think it will go up 
to 8 windows deep?

according to the readme help files

source inform  and source request  for a sample of how this can all 
fit together

Or ... for an easier professional look to an app, I suggest RebGUI. 
 http://www.dobeash.com/rebgui.htmlAshley has done a wonderful 
job of taking the REBOL view engine one step up (imho).  Some may 
disagree; but RebGUI is my main REBOL graphical app tool.

source inform  and source request - Is this a different forum

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