Przemyslaw, this is the answer that I get running your sample:
--------8<----------------- Xbase++ (R) Version 1.90 Windows 2000 05.00 Build 02195 Service Pack 4 12/04/200 7 19.35.29 1 U U U U 2 N U U U 3 C C C U 1 4 C C U U 5 U C U U ==== 1 U U U U 2 N U U U 3 C C C C 1 4 C C U U 5 U C U U ==== -------->8----------------- Best regards Maurilio. Przemyslaw Czerpak ha scritto: > > On Mon, 03 Dec 2007, Mike Evans (Gmail) wrote: > > Przemek, > > I can send you all the manual of xBase++. They have the best manual I've > > ever read and over there you can find a lot of information's As an example : > > SET DELETED on | OFF | <lToggle> > > Scope: thread-local, current work space > > Thank you for your proposition. I've already read some xbase++ > documentation so I have some basic ideas about their choices. > > > As for variables visibility : > > Visibility of variables in different threads > > > > Visibility Storage class > > > > Visible in the process PUBLIC > > (all threads) STATIC > > > > Visible in the thread LOCAL > > (this Thread) PRIVATE > > FIELD > > Variables declared as LOCAL or PRIVATE are only visible in the thread where > > the declaration occurred. The variables declared with PUBLIC or STATIC are > > visible in all threads of a process (application program). Field variables > > (FIELD) are visible in a work area of a work space. A work space is bound to > > a thread. Since work spaces can be moved between threads, field variables > > can become visible in different threads. At a given point in time, a field > > variable is visible only in one thread. > > I've read it but it does not explain what happens in some situations. > F.e. I have some private variables and create new thread. Does the new > thread inherit them or not or maybe inherits their clones? > What happen if I'll declare new public variables after creating new > threads. Will they be visible in all threads or only in the new ones > created after public declaration. > What does happen with public variable when its declaration hides > some previously defined private one with the same name when programs > leave the function where the public variables were declared and later > when leave the function where the private one were declared? > To implement the above description XBASE++ authors had to drop > compatibility with Clipper in few places. > If possible then I would like to ask xbase++ users to make a small > test with the code below. It shows some anomalies and bugs in Clipper > memvar implementation and I would like to see how close to Clipper > is xbase++ in its memvar implementation. If some can compile and run > this code and send the results here then it will help me to decide > if it's worth to replicate xbase++ behavior. > > best regards, > Przemek > > /*** mvtest.prg ***/ > proc main() > ? VERSION(), OS(), DATE(), TIME() > ? > ? "1", type("P1"), type("P2"), type("P3"), type("P4") > init() > ? "5", type("P1"), type("P2"), type("P3"), type("P4") > ? "====" > CLEAR MEMORY > ? "1", type("P1"), type("P2"), type("P3"), type("P4") > init(1) > ? "5", type("P1"), type("P2"), type("P3"), type("P4") > ? "====" > return > > proc init(x) > memvar p1 > private p1:=1 > ? "2", type("P1"), type("P2"), type("P3"), type("P4") > init2(x) > ? "4", type("P1"), type("P2"), type("P3"), type("P4") > return > > proc init2(x) > memvar p3 > private p3:=1 > init3(x) > ? p3 > return > > proc init3(x) > memvar p1, p2, p3, p4 > private p3:="[c]" > public p1:="a", p2:="b" > if x!=NIL > x:=type("P4:='d'") > endif > ? "3", type("P1"), type("P2"), type("P3"), type("P4") > return > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour