Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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