Viewing two or more copies of the same layout
[1/9] from: robbie_armour::hotmail::com at: 10-Feb-2004 3:59
Hi everyone
Firstly, hello from a newbie who's been captivated by Rebol since first
sight. It's a brilliant concept brilliantly done.
Apologies if this has been covered before, but I'm trying to set up an
application, part of which involves editing patient records. I think the
user should be able to have two or more patient records open at once, but I
cannot get Rebol to display a layout defined within an object more than once
(I need the object context to avoid having one set of global variables
trying to hold two records' data). No permutations of copy or copy/deep
seem to do it, and if I attempt eg obj2/lyt: make obj1/lyt [] I get "face in
more than one pane" errors.
Ironically if I define the layout twice globally it works fine, and the two
layouts are different and there are no shared faces.
A bit more detail: I have an object defined eg:
patient-record: context [
id: none
f1: none
lyt: layout [
across
text "Name"
f1: field
return
btn-enter "Save" [; save record to database for this id]
]
populate: func [i [integer!]] [
; set f1/text = to name from database where id = i
]
]
The user selects a name from a text-list of patients, and clicks the "edit"
button, and the associated code does:
p: make patient-record [self/populate 1]
view/new p/lyt
If the program later does:
p: make patient-record [self/populate 2]
view/new p/lyt
the new layout does not get shown at all.
Thanks for your help (and for Rebol!), Robbie the Rebol
ps Yes I am Scottish, have long hair and a beard, and a hefty claymore.
[2/9] from: brett:codeconscious at: 10-Feb-2004 20:45
At present you are making two objects (via context) which both share the
same layout face (a face is an object too) - sub-objects are not cloned
during Make - they are referenced/shared. A source of much debate :-)
>> a: context [o: context [name: "brett"]]
>> b: make a []
>> b/o/name
== "brett"
>> append b/o/name " handley"
== "brett handley"
>> a/o/name
== "brett handley"
So when your code:
view/new p/lyt
executes it is actually trying to put the exact same face (the one created
by layout) into two difference windows - which is not allowed, hence the
error message.
You can achieve what you want by using your context specification twice to
produce two different contexts without shared internal values. Because the
whole context specification is evaluated separately you end up with two
different contexts each having its own sub-object.
---snip---
patient-record: [
id: none
f1: none
lyt: layout [
across
text "Name"
f1: field
return
btn-enter "Save" [
; save record to database for this id
print ["Saving" f1/text]
]
]
populate: func [i [integer!]] [
; set f1/text = to name from database where id = i
insert clear f1/text now
]
]
p1: context patient-record
p1/populate 1
view/new p1/lyt
p2: context patient-record
p2/populate 2
view/new p2/lyt
do-events
---snip---
Cheers,
Brett.
[3/9] from: g:santilli:tiscalinet:it at: 10-Feb-2004 11:17
Hi Robbie,
On Tuesday, February 10, 2004, 4:59:49 AM, you wrote:
RA> patient-record: context [
RA> id: none
RA> f1: none
RA> lyt: layout [
RA> across
RA> text "Name"
RA> f1: field
RA> return
RA> btn-enter "Save" [; save record to database for this id]
RA> ]
RA> populate: func [i [integer!]] [
RA> ; set f1/text = to name from database where id = i
RA> ]
RA> ]
An alternative to Brett's would be to use:
patient-record: context [
id: none
f1: none
f1-value: ""
lyt: [
across
text "Name"
f1: field f1-value
return
btn-enter "Save" [; save record to database for this id]
]
populate: func [i [integer!]] [
; set f1-value = to name from database where id = i
]
]
p: make patient-record [populate 1]
view/new layout p/lyt
p: make patient-record [populate 2]
view/new layout p/lyt
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[4/9] from: greggirwin:mindspring at: 10-Feb-2004 8:11
Hi Robbie,
To explain Gabriele's suggestion a bit...
The idea is that you store the layout spec block in your object, so
it's just a block of data, not a face yet. The call to LAYOUT, which
creates the face, is deferred until you need to view it.
It might be a bit much if you're new to REBOL, but you could also look
at the source for the librarian (the REBOL version, not the web front
end) from REBOL.org. It has a number of views you can switch between,
so it uses tricks like this.
One of the big things to remember about REBOL is that everything is
just data until it is evaluated.
Happy REBOLing!
-- Gregg
[5/9] from: robbie_armour:hotma:il at: 11-Feb-2004 15:28
Re: Viewing two or more copies of the same layout. Thanks!
Thanks for the help everyone, I know you're all very busy just now. I'm
just getting to the level where I should have worked that one out for
myself.
I have some miscellaneous thoughts and findings from my own short journey in
Rebol:
Parse rocks. Unbelievably simple and fast with it. Going straight from
readable BNF to having a working syntax checker is nothing short of genius.
BRAVO!
The ability to add new variables to objects would be nice - an instant
alternative to hash! and more elegant.
text-list/picked should be a list of index integers rather than the
displayed text.
On Unix, open2 would be nice, although I should really write a wrapper to do
it with sockets.
I think to make a lot of money from Rebol it must be opened up: not
necessarily open-source but free to a higher level (eg to View + ODBC level)
just keeping encryption for the priced enterprise level (really the only
guys who'll need it?). On the ODBC front, I think DocKimbel's brilliant
mysql-protocol must have eroded most of the gain in keeping database access
priced.
A browser plug-in would bring a much bigger audience, and personally -
working for a large, pretty staid, predominantly MS-centric corporation - I
think Rebol would need to do OLE Automation to do all the things we want
(we'd pay for it). If it could, it has all competition beaten - central
code control, lack of .dlls and shallow learning curve all being huge
benefits (we have loadsa trouble with Visual Basic and incompatible dlls &
drivers). Maybe we'd still have some of the dll problems but at least we'd
have the fun of writing in Rebol.
id #143 in track.r refers to binary OR, AND & XOR bug in Mac OSX and Amiga.
Similar bug also exists in current Linux Sparc and UltraSparc releases.
Serious bug if you want to go there!
Docs and other web resources are the weakest link: some great stuff, but
patchy. Rebol/Core documentation is excellent - the combo of User Guide and
Dictionary is first rate. One area I would like a bit more of in the Core
User guide is context, scoping, 'use and local variables and (what caught me
out with layout) what happens with 'make and sub-objects. Also, when does
one object = another? I really look forward to View 1.3 (and detail docs on
all "widgets")! On the web site front, Reboltech is very interesting, but
there's a lot of broken links. Brett's codeconscious.com is great, but
beyond me some of the time.
Re documentation discussions on novice, intermediate & expert level: get the
readers to tell you the level(s) they want as they access it? Great use for
colour-coding too.
Would you like a hand with anything - beta testing or documentation perhaps?
Thanks again for your speedy help,
Robbie Armour
[6/9] from: SunandaDH:aol at: 11-Feb-2004 12:30
Robbie:
> The ability to add new variables to objects would be nice - an instant
> alternative to hash! and more elegant.
Take a look at:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=extend-an-obje
ct.r
and its documentation -- though bear in mind the limitations: "extending" an
object in this way actually creates a new instance. Not much use if the
object has references.
Sunanda.
[7/9] from: maximo::meteorstudios::com at: 11-Feb-2004 12:52
I'll just add that then, you can create a superclass object and reference that instead,
this way you can replace the internal object at will and keep all references to it...
Or you can use the no object approach I've explained completely at least twice on the
list... just do a quick search on the various list archives...
quickly, you can use a block to imitate much of an object's feature, if you don't need
the context.
not many rebolers know that you can use path notation on a block! data and it will evaluate
the next element for you (like a switch call), if it finds a matching word.
HTH !
-MAx
---
PS: This was intended for the newcommers, Sorry if its redundent for you.
[8/9] from: ljurado:bariloche:ar at: 11-Feb-2004 21:22
> A browser plug-in would bring a much bigger audience, and personally -
> working for a large, pretty staid, predominantly MS-centric corporation -
I
> think Rebol would need to do OLE Automation to do all the things we want
> (we'd pay for it).
This text was posted by me some time ago (7/7/2000):
{
I am testing Tego Web Express
http://www.tegosoft.com/VBApps/TegoWebExpress.htm with Rebol.
I am loading rebol.htm from IE5 and Rebol View is live in the browser !!!
}
With this plug-in Rebol/view is embedded at full page, but using floating
frames you can get a pretty small window in your page with rebol/view living
in it.
Luis
[9/9] from: maximo:meteorstudios at: 11-Feb-2004 19:47
WOW!
thats all I can say.
when Carl S. told about putting c source in rebol... maybe he could look at this and
see if there couldn't be an agreement with the authors which would allow a version of
rebol to be compiled with their download engine directly !!!
or something like that...
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.