AltME groups: search

with that line, you need to know about SHOW and HIDE. If you set 
b/text like that, you need to do a:

show b

afterwards, or the face won't update.

Thanks, I will try to make myself an example to understand that further. 
 I have another small stumbling block here that I would appreciate 
some wisdom on please..

; This works

view layout [a1: area (to-pair rejoin ["80x" random 100]) button 
"ok" [print a1/size]]

; but not this
view layout [
    box effect [
        draw [
            line 20x20 (to-pair rejoin ["80x" random 100])]]
]


Is this because the dialect is different in one place to the other? 
I was heading towards using a slider to manipulate stuff on the screen, 
so this is a first step towards that.

Yes, that works a treat, I suppose I could have found that from the 
documentation within a week. Now I will change the random for a slider. 
 Then I will try to make it show the line every time it moves position. 
(don't tell me the answer yet please, I only learn when my brain 
is a bit overheated). 

Would it be fair to say that Rebol is a linguist's language in that 
there are a lot of words, phrases & idioms to learn, rather than 
a smaller number of concepts that apply to everything but in a cryptic 
way?

I think it's fair to say that VID and VIEW are built on top of the 
REBOL Core. They are not intimately part of REBOL itself, and may 
not always have had the same care lavished on them as the core of 
the language.

So they tend to be a bit messier and fragmented. More of a work in 
progress than an attempt at the state of the art.

remember that you can have a very different syntax in dialects, so 
if you are not separating dialects from rebol code, you will be confused, 
because of seemingly conflicting syntax.

but IMHO, it's not as bad as having to combine HTML/JS/SQL/PHP/CSS 
in a 20 line code block.

I can't remember being so excited about learning a new thing for 
ages. It is a great privilege to have access to such well informed 
teachers as yourselves. I feel like I have stumbled into first class 
helicopter travel when I only paid for a slow bus.

Well, I modified the code from draw-controls.r in the script library 
to get this. It is more complex than I expected, 

Is it a reasonable way to do this sort of thing please?

pos1: 20x20  pos2: 80x0
view layout [
	scrn: box rate 0:0:0.1 feel [
		engage: func [face action event] [
			if action = 'time [
				scrn/effect/draw: copy []
				append scrn/effect/draw [line pos1 pos2]
				show scrn
			]
		]
	] effect [ draw [] ]
	s1: slider [
		ss1: to-integer (100 * get-face s1)
		pos2: (as-pair 80 ss1)
	]
]


Next step is to work out how to make the thing that moves leave a 
trail.

To leave a trail, you could append to the draw block (without setting 
it to a new block each time, as you've done above), but that would 
mean your draw block would get very big over time.

So a better thing to do is to draw onto an image!, which serves as 
a cache of your previous draw commands. For this, you can use an 
IMAGE instead of a BOX, and use the DRAW function to draw permanently 
onto the image. (The IMAGE style is very similar to BOX, but its 
'image facet is set to an image! for us, ready to use.)

Thanks Anton, that looks a lot simpler. It is going to take me a 
while to digest your suggestions fully.   I want to understand it 
well enough to appreciate exactly how this works & where I can read 
the code to deduce locations of thing like box/effect/draw/3/y  for 
myself.   I have been hunting through the documentation but there 
is such a lot of it that I may have failed to look in the right place. 
Thanks.

I advise you to review each facet in the face object:

	print mold first system/standard/face

and compare with the slightly larger vid-face:

	print mold first system/view/vid/vid-face


(Note, here FIRST is being used to return just the words of an object!, 
without their values. If you just probe a face it will fill up your 
console...)

Once you find a specific facet you are interested in, you can then 
probe it to see its value:

	print mold get in face 'color  ; == 200.200.200


and you can do this, of course, with any face you make, such as the 
BOX above.

Hi, I have continued to re-read the documentation for REBOL, and 
appreciating it more as I understand a bit more.

Are there any puzzels I could try to write a solution to, in REBOL, 
that would be good for a beginner please?

There is a puzzles group, and the corresponding puzzles answers group. 
 However, I don't believe the puzzles are easy.

It is hard for me to judge how hard a puzzle might be. I have some 
ideas of what I want to program for my self, but I get stuck too 
quick, so I need to exercise my understanding in a context where 
I can have a good chance of success.

Definitely these puzzles aren't for beginners. But have you already 
had a look at the cookbook at http://www.rebol.net/cookbook? That 
might be a good start trying to understand some of the examples there 
and go on from there ...

Here's how you can get a cross-section of all the VID styles, examining 
the same facet (TEXT) for all of them:


 foreach [style face] svv/vid-styles [print [style mold face/text]]

As you can see, only a few have TEXT set by default.

Here's a puzzle I posed (because I wanted a better answer). The ensuing 
discussion is excellent:
http://www.rebol.org/ml-display-thread.r?m=rmlCHQQ

Thanks Sunanda. I will have a go at it without reading any suggestions, 
then learn what I did wrong :-)   If I am not back in a week, send 
a search party.

That's kind of what I did.....First had the operational problem; 
then solved it with a procedural hack; then asked the experts to 
impress me. They did!

I have a plan, but I am stuck before that as I can't work out how 
to reference the value of a variable in a block.
aa: 1  bb: 2  cc: [aa bb]  print first cc

I want it to print 1, but however I arange the brackets I can work 
out how to do it..  I know this is very basic, sorry.

the get  function evaluates a word and returns its value, 

the reduce function evaluates a block and leaves all the results 
within the block

in rebol, words are both litteral values and references to values. 
  a word can also be unbound, in which case it essentially refers 
to no value.

and dont kid yourself, this isn't as basic as you'd think  :-)  
I still get bit, even fater years of rebol experience  :-)

Thanks, that has bought me back to the position that there is an 
outside chance I can solve this. 

What was getting me was that sometimes print reduce cc/1 would return 
an interger & sometimes a word & I couldn't work out why.

storing the integers in the block  as suggested  cc: reduce [aa bb] 
makes it work right through my code. :-)  Thanks.

It works, and it is more compact than my original -- so lots of bonus 
points there.


It's worth reading on to look at some of the other procedural solutions, 
and Joel's analysis. That'll give you some good tips on how to solve 
a problem like this using  REBOL's data manipulating tools.

The parse solutions then take it to another level :-)

I still dont feel up to the parse version of the first puzzel, so 
I have had a go at the first part of the second puzzel.  I think 
I am a bit confused about where to use var: 0 
var: copy 0

I have also got a bit mixed up with the use of global variables which 
I know is bad.  This is the code, which now dosnt seem to work since 
I put the variable initalisation inside the compress function, and 
tried to pass the variables to the function.. Dont laugh, but this 
is about 3 hours work.

raw-data: [1 2 3 10 11 99 101 2000 2001 2002 2003 2004]

sequence-break: func [count store result][
	if/else (count > 1) [
		append result to-pair rejoin [store "x" count]
		count: 1
	][
		append result store
	]
]


compress: func [raw-data][count: 1 store: reduce raw-data/1 result: 
[]
	repeat i ((length? raw-data) - 1) [
		if/else ((raw-data/(i) + 1) = (raw-data/(i + 1))) [
			count: count + 1 
		][
			sequence-break count store result
			store: reduce raw-data/(i + 1)
		] 
	] sequence-break count store result
]

probe compress raw-data


I am happy if my code is functional & easy to maintain at the moment. 
 I will never be an application developer but using small bits of 
code to increase personal productivity is IMHO a very worthwhile 
thing to try and do.

you'd use  var: 0  since 0 (an integer!)  is not a series type of 
data.

We were all newbies once! And we all are again every time we start 
learning something new.


I just remembered another puzzle/challenge I presented to the Mailing 
list, and got back a rich range of replies. This one is purely parse 
(including my first attempt), so trying it out, and then looking 
at others' code can help understand parse. As with the other two, 
it is based on a real-world need, rather than being a textboox exercise. 
(You experience the results of all three puzzles whenever you browse 
wwwREBOL.org).

Good luck with this one too!
http://www.rebol.org/ml-display-thread.r?m=rmlGPGQ

And, just in case you had any more spare time in the next month, 
another one that really surprised me as being amenable to a parse 
solution:
http://www.rebol.org/ml-display-thread.r?m=rmlJNFC

Hi, thanks for the extra puzzles.


I have managed to write a version that works now, but I am frustrated 
because I cant understand how to keep variables local & pass them 
to my function & return the changed values back...  In previous programming 
experience I seem to remeber that the function header listed the 
variable names & types used localy, then the function was called 
with the variables of the right type in the right order.. I cant 
remeber how results were returned in that context.


I have been reading here http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.5
but every way I try seems to stop the code working as expected.

raw-data: [1 2 3 10 11 99 101 2000 2001 2002 2003 2004]

sequence-break: func [][
	either (count > 1) [
		append result to-pair rejoin [store "x" count]
		count: 1
		reduce [count result]
	][
		append result store
		reduce result
	]
]

compress: func [raw-data][
	count: 1
	store: reduce raw-data/1
	result: copy []

 repeat i ((length? raw-data) - 1) [either ((raw-data/(i) + 1) = (raw-data/(i 
 + 1))) [
			count: count + 1 
		][
			sequence-break count result store
			store: reduce raw-data/(i + 1)
		]
	]
	sequence-break count result store
	reduce result
]

print compress raw-data

here is how to declare a local word using func

my-func: func [arg1 /local my-lcl][
	print arg1
	print my-lcl
]

my-lcl: "NOT"

my-func "YEP"

==
arg1
 
none

there are three other function! type building functions:
DOES
HAS
FUNCTION

look them up in the online rebol dictionary: 
http://www.rebol.com/docs/dictionary.html

you can also get help directly in the rebol console:

>> help does
USAGE:
    DOES body

DESCRIPTION:

     A shortcut to define a function that has no arguments or locals.
     DOES is a function value.

ARGUMENTS:
     body -- The body block of the function (Type: block)

(SPECIAL ATTRIBUTES)
     catch

you can also see its source, when its mezzanine code (standard rebol 
function written in rebol itself)

>> source does
does: func [

    {A shortcut to define a function that has no arguments or locals.}
    [catch]
    body [block!] "The body block of the function"
][
    throw-on-error [make function! [] body]
]

Great, this will help a lot, thanks.

I am beginning to realise that just because I have found a way to 
create a function (e.g. func) that dosn't mean I have found ALL the 
ways to make a function.  This seems to be a common theme in REBOL 
& has caught me out before.


This is my interpretation of what you have said & what I have read, 
however it does not work so I am obviously misunderstanding the method.

;; I am expecting this to reverse the arguements by passing them 
to a second function, while keeping all the function variables local 
& just passing back the result.

func1: func [/local arg1 arg2][
	temp: arg1
	arg1: arg2
	arg2: arg1
	reduce [arg1 arg2]
]

funcA: func [/local argA argB][
	func1 argA argB
	reduce [argA argB]
]

probe funcA 2 3

>> probe funcA 2 3
[none none]
== 3
>>

So,

func1: func [arg1 arg2 /local temp][
	temp: arg1
	arg1: arg2

 arg2: temp  ;I think this was a mis-type in you original, if you 
 wanted to swap
	reduce [arg1 arg2]
]

Regarding the many ways of creating a function.


I always use 'func .... Life just seems too short to bother with 
the 'does and 'has shortcuts....The result of them is a standard 
function anyway.


So, for me, the choice is between 'func and 'function. I've made 
the choice to use 'func, but I would have been just as happy to use 
'function. It's a personal preference about how local variables are 
specified:
    f: func [a /local b][b: join a a return b]
    f: function [a][b][b: join a a return b]


(though I may change my choice if I were dynamically creating functions 
rather than typing them :)

ah, I can see why I was confused.. this function
dat2: "-"
f2: func [dat2] ["operating on the global"
	append dat2 "+"
	return "added"
]
print f2 dat2
print dat2
print f2 dat2
print dat2


keeps adding a "+" to dat2, but if only the value of dat2 is passed 
to the function I cant see why is is not just doing 
append "-" "+"

which would not seem to have any effect on dat2..  so in this case 
dat2 seems to be global.   ~~confused~~

In this case, the value passed into f2 is a string!, a subset of 
series! (block!, file!, and a couple others are also series!).  Series! 
values are the equivalent of pass-by-reference, like how passing 
an array as an argument in C is pass-by-reference (or similar to 
it...  I forget the exact terminology).

Append works by modifying a series! without creating a new one.

Now I have seen references to this behaviour & the need to use "copy" 
in some contexts, but I have not managed to understand it yet.
I suspect it is a very fundemental thing to grasp.

And so if you specifically want to keep a series from being changed 
by some operation, you must copy it.

ah. so this is for variables containing series types only? numbers 
get passed as values (which is in effect a copy?)

If you type:

>> ""


in the console. A string is allocated. You can't reuse it here, because 
you haven't referenced it to get back to it. But it would stay in 
memory until it's garbage collected.

But in this code:

>> loop 10 [append "" 1]
== "1111111111"


The string can be obtained again by the code itself. REBOL reuses 
the string.

If you don't know, then you can get some strange bugs. If a series 
changes without an apparent reason, then it's likely due to whether 
it's copied or not.

Another important point: In the context of your function above, it 
doesn't actually matter whether the input is global. This is because 
REBOL works more on a basis of context rather than locals and globals. 
Locals and globals are probably what you are used to from other languages, 
but in REBOL that functionality is achieved through contexts. If 
the content of the context is allowed to survive, the content will 
survive. 

Try:

boo: func [/local pond] [
  pond: []
  append pond 'fish
]

>> boo boo
== [fish fish]
>> boo
== [fish fish fish]

No globals. :-)

I can't see why that would work that way.
Why does 
pond:[] 
not make pond be []  each time the function is called?   

This is close to one of the first questions I wrote myself in my 
notebook, but not been able to find the answer to.  I read the words 
here
http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.6

which seems to be very closly related.   Is this just a Rebolish 
thing it does because it can be useful in some other context? or 
is there a logical reason that I am not appreciating.   Sorry, I 
am not good at just doing as I am told, I find it helps me remeber 
if I have better understanding.  Thanks.

Because the contents of a function is really a context, and once 
that function is created, it doesn't disappear, including the blocks 
and series that are existing in that function. (We have to be careful 
here about using the word "context" to describe what we say, and 
the concept of "contexts" in REBOL. Don't mix it up.)

to store a dynamic value called by several parts of the code perhaps?

It's not a unique phenomenon. It's everywhere in REBOL.

It is initially confusing, because the apparent strange behaviour 
is limited to series, not (not sure what the official term is) numbers.

If you try this:
f: func [a /local b c] [b: [] c: 0 append b a c: c + a]
f 1
f 2
source f


You can see that (quite literally, in a metaphorical sense) the in-memory 
copy of function f has been changed:
f: func [a /local b c] [b: [] c: 0 append b a c: c + a]
f 1
f 2
source f


To not have it change in that way (or to re-initialise b, if you 
like):
f: func [a /local b c] [b: COPY [] c: 0 append b a c: c + a]
f 1
f 2
source f

But 'c has not changed in either case:
  c: 0
means exactly what it says.

I have a reasonable understanding of functions now thanks to all 
your help. 


Now I have decided to have another go at understanding parsing & 
what I have picked up in more general terms seems to have helped 
my understanding of the documentation a bit better.  The question 
I am trying to solve at the moment is: Is there a straight forward 
way to extract the string "two.txt" from the following string {randomXXXrandom.log 
XXXrandom.txtrandom}  

My limited skills let me extract from the first XXX to .txt, but 
not from the XXX that preceeds the .txt alone.

what's a sample of what you are trying to do ?

using parse ... as a learning exercise.   so the only way I can identify 
the string I want is by what comes after it, but it must be before 
the next occurance of XXX

if it was a regular expression it would be something like XXX[a-z]*\.txt

I cant see a way to make the parse function be non-greedy, perhaps 
I just need to look at this in a different way all together? This 
is the sort of thing I have been trying that dosen't work.
spacer: charset reduce [tab newline #" "]
non-space: complement spacer

probe parse/all {randomXXXrandom.log XXXrandom.txtrandom} any [to 
"XXX" copy result thru non-space to ".txt"]
print result

I was used to regexp, when I used to program in python in particular, 
and that probably is one of the reasons I had soooo much of a hard 
time grasping parse (even after years of trying)

mike: the best tip I can give you is to picture a cursor in your 
head when you type your rules.  parse really is about iterating over 
a series on byte at a time and matching the next expected characetr.

since it only moves forward, its very fast.  in order to do look 
ahead assertion and things like that (which are slow in regexp anyways) 
you must learn a few tricks in order to manually set and retrieve 
the "current" character index.

also note that when there is a "roll back", the cursor and rules 
rolls back together.  (unless you are doing manual cursor manipulation 
tricks)

I presume that .txt is not going to appear in the 'random' text?? 
 And XXX is really a fixed set of characters?

this is a cheat ...

>> s: {randomXXXrandom.log XXXrandom.txtrandom}
== "randomXXXrandom.log XXXrandom.txtrandom"

>> parse/all reverse s [ to "txt." copy txt to "XXX" ( reverse txt 
) to end ]
== true
>> txt
== "random.txt"

I usually adopt a different approach which is to write a rule to 
match my target and use any and skip to apply that rule progressively 
through the input. It may not be the fastest way but it seems easier 
to grasp than backtracking.

>> haystack: {randomXXXrandom.log XXXrandom.txtrandom} 
>> alpha: charset [#"a" - #"z" #"A" - #"Z"]  

== make bitset! #{
0000000000000000FEFFFF07FEFFFF0700000000000000000000000000000000
}
>>   digit: charset [#"0" - #"9"

]
== make bitset! #{
000000000000FF03000000000000000000000000000000000000000000000000
}

>>   alphanumeric: union alpha digi

t
== make bitset! #{
000000000000FF03FEFFFF07FEFFFF0700000000000000000000000000000000
}
 
                             
>> needle: ["XXX" some alphanumeric 
".txt"]    

>> parse/all haystack [any [copy result needle (print skip result 
3) | skip]]

random.txt

== true


As you can see with this approach, you have to manually extract the 
"XXX" once you've grasped the needle.

Mike, this group has [web-public] in its title, meaning it is being 
published to the web.
So the replies are available online for anyone.
http://www.rebol.org/aga-display-posts.r?post=r3wp174x1957
A tutorial to put it all in content would be even better.

If you have not found it already, this is a detailed tutorial on 
'parse, building up slowly from the basics:

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse

Put the 'to inside the block, like this:

parse/all {zabc} [ [to "b" | to "y"] copy result thru "c"  (print 
result) ]


IIRC, your syntax has been a long-standing request to improve 'parse

Hi, I have been studying the example from Pekr and developed the 
following addaptation.

b: [to "bb" break]
y: [to "yy" break]

parse/all {zyybbc} [ some [b | y  break | skip] copy result thru 
"c"  (print result) ]


however this seems to loop for ever, but I don't understand why. 
Any wise words would be appreciated.  Sorry to be so needy, I am 
begining to wonder that as I am having so much trouble with this 
basic stuff, perhaps this is a programing language that I am just 
not suited to?  Let me know if I am causing a problem by posting 
here so often & I will admit defeat with the parsing & go back to 
something more familiar.s

my modification to add "to" seems to break it & I dont feel I have 
enough of a grip on the syntax to work out why.

mhinson... for backtracking, at least in my experience, using to 
and thru are pretty dangerous... its pretty much the same as using 
a goto within structured programming.

its creates something of a parralel to a closure.

I find that there several types of broad parse rule families.
-some find and extract values OUT of some arbitrary string.

-some are used as advanced controled structures, where you can pretty 
much simulate lisp functional programming,
-some are used to convert data streams

-others simply can match a whole data set to make sure it conforms.
(+probably others)


strangely each type of setup has sort of a different global approach, 
but its very case specific obviously.

generally, you should realise that when you build parse rules to 
need to have some sort of sence of  "context"   i.e. Where are you 
in your data. this will help you a lot.

where as in at what point in the string AND where in the sense of 
a what step are you now in the parsing.

thinking in those terms makes the rules much easier to place in what 
I like to call  "PARSE SPACE"  where everything is a little bit odd 
 ;-)f

given:

data: "THIS IS A TEST STRING WITH A <TAG> IN IT "

if we want to extract what is after that single tag, then you can 
easily use to or even better thru:


but lets do it using skip.  starting with a simple example will make 
the lesson 2 more obvious.

so why did it only print the string once?  simple question... but 
not so obvious to answer for a newbie  :-)

Here is a crude way to do what we did earlier that doesn't use parse 
but matches any part to any first occurence of the letter

>> chars: charset "by"
== make bitset! #{
0000000000000000000000000400000200000000000000000000000000000000
}
>> copy/part z: find {aabbyyc} chars next find z "c"
== "bbyyc"

it evaluates until it finds a given character that it cannot match

ok, I'll be back later for lesson two  :-)  but I'll give you a simple 
lesson 1.5 assignment  ;-)

edit the above so it matches either "<TAG>"  OR  "[TAG]"   :-)

Thanks Paul, I fear I have been ignoring the use of other things 
like find. I guess with more complex parse expressions find may be 
a shortcut to extract a substring from a predictable block of text..

the "comprehension" of those simple things is essential, simply knowing 
about them is useless... cause in real life, you will have to "SEE" 
the whole recursive structure of the parse rules played in your head. 
 


if you don't fully grasp what is going on, you can't really create 
that essential mental map.   that is what kept me from understanding 
parse for 6 yess... SIX years :-(   and suddenly over the course 
of 2 days, I finally "GOT" it and a week later I was building a 700 
line parse rule for a real-time server doing signal convertion from 
one data format to another through two network ports.

Sounds like a chalange.   I have wrote quite extensive data conversion 
routines in Pascal, but that was in the 80s.

its funny cause once you "get" parse... just about every data manipulation 
is really easy using it.  remark, used find and copy and shit like 
that before... it was a horrendous 100 lines of code.


it was replaced by 10 lines of parse code and now runs 20-50 times 
faster and can do much more funky stuff on top of it.  :-)

isnt Paul's example a "propper" parse?

that was my situation before too... hell I had trouble doing just 
about anything in parse... for sooo long... now I can argue with 
the parse gurus... hehe I admit I'm a wee bit proud of that  ;-)

mhison its a valid, but not really appropriate use of parse

when you start to add a single other rule, that will start to fall 
appart.

Ah, so Paul wants to create in effect a "regular expression" and 
use it in the parse.

Sunanda, I had a look at the parse visualiser yesterday, it looks 
a bit advanced for me yet. A simple version would be good for newbies. 
 I got it to work on his examples, but my examples produced no output. 
 I expect I was doing something foolish.  I will return to it when 
my basic skills are a bit better.

Maxim.  Here is my first attempt at the homework you set me. This 
builds on what you showed me & also relates to the example given 
to me by Pekr.


data: "before first tag <TAG> after 1st pointy tag [TAG] after square 
tag <TAG> after pointy tag 2"

tag-square: "[TAG]"
tag-pointy: "<TAG>"

output: func [tag here] [
	print rejoin ["we are passed the " tag " : '" here "'"]
]

parse/all data [
	some [ 
		[tag-pointy here: (output tag-pointy here) ] 
		| [tag-square here: (output tag-square here) ] 
		| skip
	]
]


I thought it would make the action clearer if the output was in a 
function & the keys used variables.

mhinson: your rule:

b: [to "bb" break]


looks quite dangerous. TO means a lot of input may be skipped, which 
is usually not what you want. Moreover, BREAK in that rule is not 
the right place. (it just breaks the rule, but that is totally unnecessary.

(I am not a big fan of BREAK myself, every rule can be written without 
BREAK)

mhinson: there is simple rule to how to read TO: skip everything, 
unless you find the target. This is not what you wanted in your original 
example, because e.g. TO "b" might also mean, that "b" might be the 
last char of your string. So if you are looking for FIRST occurance 
of [a | b | c], you really have to forget TO and use skip based parsing 
by one char. Hence some [a break | b break | c break | skip] is your 
friend ...

To [a | b | c] may work in the future, but it certainly does not 
work now (although it is not hard to replace using ANY or SOME)

did you have a look at the link Sunanda mentioned? http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse?

Yes, that was the firt time I found that as I had not realised the 
Wiki was so extensive. It is a good source.

I am not sure why the BREAK is needed in the example from Ladislav 
above. Is it to force the rule to return true when the "B" and "." 
matches are found to prevent it carrying on looking for a second 
match further down the string?

I have been working out ways to extract IP addresses from a string 
today.  Is this a good way to do it? What could catch me out?


parse to-block "junk 111.111.111.111 0.0.0.0 255.255.255.128 junk" 
[
  any [
    set tup tuple! (print tup)
    | skip
  ]
]

Hi, I have been working on a bit of code for some time & it now does 
something usefull for me, but to use it I am coding the output file 
into the code & running it repeatedly against every file in a directory. 
  I thought it would be nice for it to have a very simple GUI to 
navigate to the input directory & output file & perhaps display some 
indicator of progress. 

Is this something a beginner might hope to add to existing code, 
or should I start from scratch again with the GUI part, then try 
to recreate my code in the view Layout part? Thanks.

you can create a prototype of the GUI first, by just creating a layout 
with the placement of the styles you want. afterwards you can make 
it work as you want using SET-FACE, GET-FACE, etc.

I will have a fiddle & see if I can understand that. Thanks very 
much Henrik