you need to make sure that your member is a field and not text, seems that text
members can't handle copytoclipboard.
One suggestion would be that keep your text membe to dislpay the text but set an
off stage field member to have the same text content & copy from, that :-

member("myfield").text = member("missionstatement").text
member("myfield").text.copyToClipboard()

should do the business. Incidentally, I think pastefromclipboard() works OK with
text members


good luck
rick



---------------------------------
   Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download
Messenger Now

[Non-text portions of this message have been removed]

I'm not sure if it's "on track" for this list, but I'm
responding to the person having trouble using the
copyToClipboard() function.

I ran into the same trouble the other day when I
wanted to add the ability for text to be copied from a
Shockwave movie to the clipboard.

In terms of text, copyToClipboard() only seems to work
with field cast members, and it doesn't work with text
cast members. The workaround is easy though. Just copy
the text data from a text member to a field member and
use the copyToClipboard() function with the field cast
member.

Good luck,

- Ken

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

----- Original Message -----
From: "Christoffer Enedahl" <christoffer@...>
>
> > - Code should be freely downloadable and free to distribute via the
> > Internet (mainly email and Usenet) so long as the comments remain
> > intact, or a link to the original code is given where quoted in part.
>
> Why the diffrence with distributing on the internet and a fixed medium
such
> as CD?

The basic reason for this is that we don't really want people making CDs out
of the openLingo library and selling those CDs. The reason I don't think
there should be an implicit mechanism to allow this as part of openLingo is
that it does not benefit openLingo in any way, but it does mean that there
will be fixed copies of openLingo code out there, which may be out of date,
which can in itself cause problems. You also have the legal problems of the
license under which the CD is distributed, which might conflict with the
interests of the copyright holders.

It is basically just difficult to put in controls to ensure that *any*
re-distribution is done in a way that benefits both the end-users and the
openLingo project. Better just to ban all redistribution apart from specific
exceptions (i.e., posting code on Usenet, or quoting it in web-based
tutorials, etc.). With these exceptions it is easy to provide a link back to
the original code. If anyone wants to distribute the source code on a CD
then there is nothing stopping them from contacting each of the copyright
holders individually (which is what they would have to do otherwise,
anyway).

> Why not claim that it must not cost any money to get it, other than the
cost
> for a burned cd and shipping ?
> Or is that sort of distributing out of the question?
> Or perhaps it's better with the copywriters written permission as you
wrote?

I think it should be up to the copyright holders if they do/don't want to
allow their code to go onto a fixed medium, and it should also be up to them
if they want to /charge/ for it. Just because the code is going into
openLingo for free doesn't mean anyone should be giving up any of their
other rights to their own work.

openLingo is solely an Internet-based distribution so we *need* to have an
agreement that says we can distribute any openLingo code on the Internet for
as long as we like. Anything else is separate and should be excluded from
the redistribution license, IMO.

Note that the redistribution license also needs to say that anyone can use
openLingo code in their own /projects/ free of charge - I think we should
say that they must either not include the source and may voluntarily give a
credit to openLingo, or if they include the source they must leave all
comments intact giving full credit to the copyright holder(s).

The grey area here is how we distinguish between someone's project that uses
openLingo and a library CD that attempts to sell openLingo source code. I
think the license should simply preclude /advertising/ the fact that the CD
contains source code anywhere on the packaging, but a credit/link may be
given (which would be encouraged, but not required).

- Robert

> - Code should be freely downloadable and free to distribute via the
> Internet (mainly email and Usenet) so long as the comments remain
> intact, or a link to the original code is given where quoted in part.

Why the diffrence with distributing on the internet and a fixed medium such
as CD?
Why not claim that it must not cost any money to get it, other than the cost
for a burned cd and shipping ?
Or is that sort of distributing out of the question?
Or perhaps it's better with the copywriters written permission as you wrote?

/Christoffer

I am sending this message as a "Special Notice" because it is
important and I don't want anyone to miss it because of their email
preferences. If you have submitted code to openLingo already then you
should definitely get involved in this discussion. Otherwise feel
free to ignore it.

It is fair to say that this is a pretty boring subject, which is
probably why there was no final concensus when it came up back in the
early days of the group. However, before we can really move to a more
permanent home, we need to reach an agreement about what the terms
will be for:

- Submitting code
- Downloading/using code
- Redistributing code in source form

I would like this to be established now and be written in stone when
the new site goes live, so I can then ask everyone who has already
submitted code to agree to the new license before re-submitting it to
the new site. I should have a bit of free time over the next few
weeks, so I would like to have the site live ASAP, before I get too
busy again.

I've looked at existing licenses and I'm not 100% happy with any one.
Our main options for an existing license are the LGPL or BSD, since
the GPL is ruled out as too restrictive. There may also be an
applicable creative commons license, but I couldn't find one that
seemed to fit, so if anyone wants to point one out then that would be
helpful.

As I see it, the general terms of the license should be as follows,
as I think this is best for the group in general. If anyone wants to
disagree with any of these points or add to them then please do so,
otherwise we should assume that these will be the requirements for
our license. What might be the best route would be to find the
closest existing license and just take out any clauses we feel are
too restrictive, or something like that.

- Authors & the group should be protected from liability. No warranty
should be given.

- Authors should not be able to prevent openLingo from distributing
code after it has been submitted, although apart from that, they
should retain full copyright on their work.

- Code should be freely downloadable and free to distribute via the
Internet (mainly email and Usenet) so long as the comments remain
intact, or a link to the original code is given where quoted in part.

- Code should be free to use in a project where it is not distributed
as source (or at least not advertised as such, so leaving code as .ls
files on a CD should not be an automatic breach of this).

- Code should not be free to distribute on a fixed medium without
permission from each of the contributors.

That's how I see this anyway, and I'm pretty sure from the previous
discussion that most people would agree. Anyone who has anything else
to add should do so now though because getting the license sorted out
has got to be the number one priority at this point in time. I
therefore will be making a final decision one way or another within
the next few weeks.

- Robert

--- In openLingo@yahoogroups.com, "Christoffer Enedahl"
<christoffer@e...> wrote:
>
> Nothing seems to happen here anymore.

It is a bit quiet, isn't it? ;-)

> Robert, hows the php site doing?

Yes, it's definitely a high priority now, since the list is almost
dying off without it. I've been stupidly busy for the past few months
and now I've got a couple of weeks in which I need to sort out my
taxes, but other than that I should be able to properly dedicate
myself to getting the site live this/next month.

Also, I've just changed my Yahoo account becaue of spam, and set my
new account as the group moderator. But for some reason I've not been
getting emails from the list since making the change. I'll need to
look into that, so apologies for the delay if anyone's gets left
waiting for a first-post to be approved.

- Robert

I have created a simple rollover button that, when clicked, is
supposed to copy a text member from  the cast to the Windows
clipboard. The script I'm using is this:

----------------------------------
on mouseUp me
member("missionstatement").copyToClipboard()
end

on mouseEnter me
   sprite(19).memberNum = 41
end

on mouseLeave me
   sprite(19).memberNum = 39
end
-----------------------------------

For the copyToClipboard command itself, I've also used the following
two variations:

-------------------------
member(36).copyToClipboard()
-------------------------

and

------------------------------
copyToClipBoard(member("missionstatement"))
------------------------------

Unfortunately, I am still unable to copy the cast member to the
clipboard. Am I doing something wrong with the script? Does this
command require a handler of some type (which I haven't written), or a
specific Xtra?

FYI, I'm using Director MX in Windows XP.

Thanks for your help!

Nothing seems to happen here anymore.

Have a look at my inverse kinematics tutorial at director-online
http://director-online.com/buildArticle.php?id=1126

I use some openLingo material in it. Mainly the trigmath lib.

Robert, hows the php site doing?

/Christoffer

----- Original Message -----
From: "ithemabv" <ithemabv@...>
>
> I've been trying to create a backup copy of an object so I can go
> back to an earlier state of the object if something goes wrong. I
> tried to copy an object by typing:
>
> oObjectBackup = oObject
>
> This leaves oObjectBackup with a pointer instead of a copy of the
> object. So when oObject changes, oObjectBackup changes with it. Does
> anyone know how to copy an object so I can restore the previous state
> of the object?

Interesting point. Lingo has a duplicate() function, but it works only for
lists, not objects. I don't think there is a built-in function that does
this. However, you can duplicate an object like so (although this is
slightly naive when it comes to objects with ancestors that override
properties):

on duplicateObject aObj
   vNew = aObj.script.rawNew()
   vMax = aObj.count
   repeat with i = 1 to vMax
     vProp = aObj.getPropAt(i)
     vNew[ vProp ] = aObj[ vProp ]
   end repeat
   return vNew
end

( BTW, I've never personally needed to duplicate an object, so if anyone
knows of a better approach, let us know ).

Also, what might be a better thing to do is add handlers to your object
called pushState and popState, which store all the properties in a stack.
Then you can alter the object, and restore it to a previous state with
popState. This will maintain all external references to the object whereas
taking a duplicate may copy the object, but that does not mean it will be
easy to simply replace the original object with its clone.

- Robert

Hello,

I've been trying to create a backup copy of an object so I can go
back to an earlier state of the object if something goes wrong. I
tried to copy an object by typing:

oObjectBackup = oObject

This leaves oObjectBackup with a pointer instead of a copy of the
object. So when oObject changes, oObjectBackup changes with it. Does
anyone know how to copy an object so I can restore the previous state
of the object?

Thanks,
Martijn

----- Original Message -----
From: "Luke" <lukewigl@...>
>
> > Forgive my ignorance, but what are hard and soft pointers?
>
> Hi Pranav,
>
> By "soft pointers" - I mean references to objects you can use to
> address messages to the object (like normal lingo references to
> objects), but which are insufficient to keep the object alive (in
> other words, they do not get included in the 'reference count' of
> the object )

Did you know that this concept exists in Unix? The filesystem uses hard
links and soft links (or symbollic links, symlinks for short to be more
accurate with the *nix terminology). It works in exacty the way you describe
for objects - hard links to a file resource effictively *are* the file, and
only when all of them are removed is the file resource deallocated. This is
why *nix doesn't have a delete command like DOS, but has "unlink" instead.
The symlinks are much the same as shortcuts in Windows, they point the
location of another file, but they do not link physically to the file data.

However, I'm not so sure the idea of a soft link would be all that useful in
practise, since it would still be possible to create circular references
even using this. I agree with Ben, if you want to completely eliminate
memory leaks completely, you have to dump reference counting.

In the meantime, as a workaround, my protocol of having a parent object that
is soley responsible for destroying its children should prevent memory leaks
with the current model. I'm planning to sit down with my copy of design
patterns when I get a chance and make a "factory" object for openLingo that
follows this protocol. If all objects are then created with factories then
memory leaks should be eliminated. There are certain situations where this
strict parent-child model can be awkward, but these can all be worked around
so that the model is maintained.

- Robert

> Forgive my ignorance, but what are hard and soft pointers?

Hi Pranav,

By "soft pointers" - I mean references to objects you can use to
address messages to the object (like normal lingo references to
objects), but which are insufficient to keep the object alive (in
other words, they do not get included in the 'reference count' of
the object )

(i am proably mis-using the term "soft pointer", maybe reference to
child object "lite" is more appropriate... :-)

Luke

thanx luke,
works great (also as method, on handlerP(me, aHandler))

valentin

--- In openLingo@yahoogroups.com, "Luke" <lukewigl@y...> wrote:
> > - Isn't this almost a bug? I would have expected that handler()
would
> > search the whole "ancestor line", as does the lingo interpreter
when the
> > handler is actually called
>
> The handler() function (along with handlers(), new() and rawNew()
do seem to be
> private to a script object and exempt from director's 'inheritence'
model.
>
>
> > - Do you know any elegant solution to find out if any parent
script in
> > the "ancestor line" has implemented a certain handler?
>
> I dont know if its elegant, but you can manually query for a
handler like this
>
> on handlerP(anObject, aHandler)
>   -- returns true if the specified handler exists in the specified
>   -- object or in any of its ancestors
>   if anObject.ilk = #Instance then
>     a = anObject.getAProp(#ancestor)
>     if a.ilk = #Instance then
>       fnd = handlerP(a, aHandler)
>       if fnd then
>         return 1
>       else
>         return anObject.handler(aHandler)
>       end if
>     end if
>   end if
>   return 0
> end

Forgive my ignorance, but what are hard and soft pointers?

Pranav Negandhi
concept-I
www.cimultimedia.com

<snip...
> I was just idly thinking about what new lingo commands I'd like
> to see in the next
> version of Director (eg yield(), sweep() - from MU lingo etc),
> and I was thinking about
> about soft and hard pointers to objects. "Soft" pointers would be
> sufficient for
> sending messages, but insufficient to keep an object alive. Hard
> pointers would be
> just like the current object 'references'. The syntax would be
> something like
>
>  myHardPointer = script("foo").new()
>  myHardPointer.mStoreThis (me.SoftPointer)
>
> ... and in the "foo" script
>
> mStoreThis (me, someObject)
>  mySoftPointer = someObject
> end
>
> The advantage of this is that it would be easier to manage
> circular callback system --
> but could be problematic because a 'softPointer' doesn't
> guarantee that the object will
> exist. Any thoughts or opinions?
>
...snip>

Hi Luke,

Would this really make much difference? You would need to check all your
soft pointers to see if they were still valid every time before you could
use them. Granted - you often need to do this anyway as something else might
have called destroy() on the reference anyway, and checking for VOID is good
defensive programming, however, isnt it the case that all you end up doing
is recasting your object cleanup code and moving it from here to there?

What would be really nice is if Director stopped using reference counting
and used a mark and sweep algorithm for garbage collection which avoids the
memory leaks from circular references. But I dont expect it will happen.

Ben


-----Original Message-----
From: Luke [mailto:lukewigl@...]
Sent: 28 November 2003 00:37
To: openLingo@yahoogroups.com
Subject: [openLingo] lingo wishlist - soft and hard pointers


Hi all,

I was just idly thinking about what new lingo commands I'd like to see in
the next
version of Director (eg yield(), sweep() - from MU lingo etc), and I was
thinking about
about soft and hard pointers to objects. "Soft" pointers would be sufficient
for
sending messages, but insufficient to keep an object alive. Hard pointers
would be
just like the current object 'references'. The syntax would be something
like

myHardPointer = script("foo").new()
myHardPointer.mStoreThis (me.SoftPointer)

... and in the "foo" script

mStoreThis (me, someObject)
mySoftPointer = someObject
end

The advantage of this is that it would be easier to manage circular callback
system --
but could be problematic because a 'softPointer' doesn't guarantee that the
object will
exist. Any thoughts or opinions?

Luke


Yahoo! Groups Sponsor



To unsubscribe from this group, send an email to:
openLingo-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi all,

I was just idly thinking about what new lingo commands I'd like to see in the
next
version of Director (eg yield(), sweep() - from MU lingo etc), and I was
thinking about
about soft and hard pointers to objects. "Soft" pointers would be sufficient for
sending messages, but insufficient to keep an object alive. Hard pointers would
be
just like the current object 'references'. The syntax would be something like

  myHardPointer = script("foo").new()
  myHardPointer.mStoreThis (me.SoftPointer)

... and in the "foo" script

mStoreThis (me, someObject)
  mySoftPointer = someObject
end

The advantage of this is that it would be easier to manage circular callback
system --
but could be problematic because a 'softPointer' doesn't guarantee that the
object will
exist. Any thoughts or opinions?

Luke

> - Isn't this almost a bug? I would have expected that handler() would
> search the whole "ancestor line", as does the lingo interpreter when the
> handler is actually called

The handler() function (along with handlers(), new() and rawNew() do seem to be
private to a script object and exempt from director's 'inheritence' model.


> - Do you know any elegant solution to find out if any parent script in
> the "ancestor line" has implemented a certain handler?

I dont know if its elegant, but you can manually query for a handler like this

on handlerP(anObject, aHandler)
   -- returns true if the specified handler exists in the specified
   -- object or in any of its ancestors
   if anObject.ilk = #Instance then
     a = anObject.getAProp(#ancestor)
     if a.ilk = #Instance then
       fnd = handlerP(a, aHandler)
       if fnd then
         return 1
       else
         return anObject.handler(aHandler)
       end if
     end if
   end if
   return 0
end

Hi list,

I think I've never posted to this list before, so I'm not sure, if this
question fits in here, if not just one word and I will shut up, I
promise:-)
I have a question about lingo's handler() function: I have a parent
script ("foo", lets say) that's intended to be supplemented by a user
(another lingo coder) by implementing certain handlers in a child
object. In my example the parent script checks if a Header() and/or a
Footer() handler is implemented, and in case it exists, calls it:

on someHandlerInParentScript me, ...
    if me.handler(#Header) then me.Header()
    ...
end

This works without any problems, but it only works for "one generation".
If I implement those handlers in a parentscript "child1":

property ancestor
on new me
    ancestor=new(script "foo")
end

on Header me,...
....

and now create another child object "child2", who's ancestor is
"child1":

property ancestor
on new me
    ancestor=new(script "child1")
end

the handler-detection with lingo's handler() function doesn't work
anymore, me.handler(#Header) in parent script "foo" returns false,
although the handler Header() is available and can be called. The only
way I could get it to work was by implementing an "intermediate" handler
like:

on Header me
    callAncestor #Header, me
end

in the parent script "child2".

  So, here my questions:
- Isn't this almost a bug? I would have expected that handler() would
search the whole "ancestor line", as does the lingo interpreter when the
handler is actually called
- Do you know any elegant solution to find out if any parent script in
the "ancestor line" has implemented a certain handler?

Thanx,
Valentin

> > The barberhyme Copyright(c) Hank Ketcham
>
> Where did the above come from???

Ummm...dat was supposed to apply to <snip snip scissors n snip> & <spare my
ear n button ur lip>. <:o) I got it from one of my comic books.


>
> One potential problem could be if someone use this script as an ancestor,
> I'm not sure which "me" reference will turn up as the first param in the
> handler.
>


Ancestors get the reference to the derived class. Like so -

-- Fruit
on new me
	 return me
end new me

on whoAreYou me
	 return me
end whoAreYou me

-- Berries
on new me
	 ancestor = script("Fruit").new()
	 return me
end new me

-- Blueberries
on new me
	 ancestor = script("Berries").new()
	 return me
end new me


-- Welcome to Director --
x = script("Blueberries").new()

y = script("Berries").new()

z = script("Fruit").new()

put x.whoAreYou()
-- <offspring "Blueberries" 3 1d4100>
put y.whoAreYou()
-- <offspring "Berries" 2 1d3728>
put z.whoAreYou()
-- <offspring "Fruit" 2 163130>
put x
-- <offspring "Blueberries" 3 1d4100>
put y
-- <offspring "Berries" 2 1d3728>
put z
-- <offspring "Fruit" 2 163130>

Pranav Negandhi
concept-I
www.cimultimedia.com

> One potential problem could be if someone use this script as an ancestor,
> I'm not sure which "me" reference will turn up as the first param in the
> handler.

Yep confirmed, the top reference is passed as "me" not the ancestor scripts
reference.

here is the loophole: (I got the same result with callAncestor)

on startmovie
   a = script("child").new(5)
   a._PrivateHandler(1)
   a.PublicHandler(3)
end

-- "Used a privatehandler now with argument: <offspring "child" 3 237f70>"
-- "pValue is 5"
-- "Used a Publichandler now."
-- "Used a privatehandler now with argument: 3"
-- "pValue is 5"


-------- parentscript Child
property ancestor

on new me, aValue
   ancestor = script("PrivateTest").new(aValue)
   return me
end


-------- parentscript PrivateTest
property this --me reference for private handlers
property pValue --test prop to be sure we are in the correct script

on new me, aValue
   pValue = aValue
   this = me
   return me
end

on PublicHandler me, argument
   put "Used a Publichandler now."
   _PrivateHandler( argument ) --Internal call of privatehandler
end

on _PrivateHandler argument
   if ( param(1) = this ) then --Test if this handler was called from
outside. (this could check the object ancestors, will add to overhead)
     put "Don't use my private parts! Sir!"
     return -1
   end if

   put "Used a privatehandler now with argument: "& argument
   put "pValue is "& pValue
end

/Christoffer

> Heya Chris,
> Are you awake yet?

Yeah, now, after my first cup of coffe.

> The second part that Brennan mentions, about using an interface parent
> script, sounds interesting. I have actually been using a similar method
for
> several months now. I find it to be very convenient because a lot of work
> that I have done lately has been creating generic core components, and
> handing them over to other developers to incorporate into their projects.

Sounds like a good idea when working with other programmers in a large
project or as a code provider.

> The interface is a movie script. That way, the developers don't even need
to
> know the variable name of the Dictionary object instance. All Dictionary
> methods are prefixed by the name of the class (such as
> DictionaryGetMeaning(), DictionaryShutdown). It does make the names a
little
> longer at times, but helps avoiding name-space conflicts.

Well. perhaps thats the best solution in this case. Personally I'm not fond
of loads of moviehandlers all over the place. (Kinda why I'm not gonna do
something big in C, ever)

> I can't say enough about how much time this methodology has saved me.
> Whenever a developer reports some obscure bug, I'm dead sure that
someone's
> either been screwing with the Library scripts or by-passing the class
> interface and referring to the guts of the class directly.

Well thats whats the whole private fuzz is all about, preventing nosy
programmers peek n poke in your code ;)

> The barberhyme Copyright(c) Hank Ketcham

Where did the above come from???


Ok, been experimenting a bit. It seems like I cannot hide properys away with
any overriding handler, but handlers work fine, here is the script:

on startmovie
   a = script("PrivateTest").new(5)
   a._PrivateHandler(1)
   a.PublicHandler(3)
end

-- "Don't use my private parts! Sir!"
-- "Used a Publichandler now."
-- "Used a privatehandler now with argument: 3"
-- "pValue is 5"

------- ParentScript PrivateTest

property this --me reference for private handlers
property pValue --test prop to be sure we are in the correct script

on new me, aValue
   pValue = aValue
   this = me
   return me
end

on PublicHandler me, argument
   put "Used a Publichandler now."
   _PrivateHandler( argument ) --Internal call of privatehandler
end

on _PrivateHandler argument
   if ( param(1) = this ) then --Test if this handler was called from
outside.
     put "Don't use my private parts! Sir!"
     return -1
   end if

   put "Used a privatehandler now with argument: "& argument
   put "pValue is "& pValue
end

One potential problem could be if someone use this script as an ancestor,
I'm not sure which "me" reference will turn up as the first param in the
handler.

/Christoffer

Heya Chris,
Are you awake yet?

The second part that Brennan mentions, about using an interface parent
script, sounds interesting. I have actually been using a similar method for
several months now. I find it to be very convenient because a lot of work
that I have done lately has been creating generic core components, and
handing them over to other developers to incorporate into their projects.

For instance, a generic dictionary class would have the following
structure -

-- Dictionary Base Class
on new me
	 me._doPvtStuff()
	 return me
end new me

on getMeaning me, aWord
	 -- Find meaning from DB

	 return vMeaning
end getMeaning me

on _doPvtStuff me
	 -- Open DB's and the like
end _doPvtStuff me


-- Dictionary Interface
on DictionaryInitialise
	 gDictionaryObject = script("Dictionary Base Class").new()
end DictionaryInitialise

on DictionaryShutdown
	 gDictionaryObject.Destroy()
end DictionaryShutdown

on DictionaryGetMeaning aWord
	 return gDictionaryObject.getMeaning(aWord)
end DictionaryGetMeaning

The interface is a movie script. That way, the developers don't even need to
know the variable name of the Dictionary object instance. All Dictionary
methods are prefixed by the name of the class (such as
DictionaryGetMeaning(), DictionaryShutdown). It does make the names a little
longer at times, but helps avoiding name-space conflicts.

When a developer wishes to use the Dictionary component in his software, he
simply has to pull the Dictionary scripts from the Library and initialise it
when the movie starts. Calling the DictionaryShutdown() handler closes the
component very neatly. To make things consistent, common functions such as
initialisation & destruction are given the same handler suffixes
(Initialise, Shutdown) in all components.

I can't say enough about how much time this methodology has saved me.
Whenever a developer reports some obscure bug, I'm dead sure that someone's
either been screwing with the Library scripts or by-passing the class
interface and referring to the guts of the class directly.

Pranav Negandhi
concept-I
www.cimultimedia.com

<snip snip scissors n snip>
>
> Ok , I just dug it up:
> <http://groups.google.se/groups?hl=sv&lr=&ie=UTF-8&oe=UTF-8&selm=3
> 8A22E55.FD
> 88D09F%40young.net>
>
> Im not sure it does what I said it was supposed to do, vague memory. Im
> going to bed now, I'll read it my self tomorrow when my mind is not so
> clouded.
>
> Christoffer
<spare my ear n button ur lip>

The barberhyme Copyright(c) Hank Ketcham

Ok , I just dug it up:
<http://groups.google.se/groups?hl=sv&lr=&ie=UTF-8&oe=UTF-8&selm=38A22E55.FD
88D09F%40young.net>

Im not sure it does what I said it was supposed to do, vague memory. Im
going to bed now, I'll read it my self tomorrow when my mind is not so
clouded.

Christoffer


----- Original Message -----
From: "Pranav Negandhi" <pranav_negandhi@...>
To: <openLingo@yahoogroups.com>
Sent: Wednesday, November 26, 2003 7:31 PM
Subject: RE: [openLingo] Privates, software implemented or not?


> Just out of curiosity, can I see the script Chris?
>
> Pranav Negandhi
> concept-I
> www.cimultimedia.com
>
>
>
> > -----Original Message-----
> > From: Christoffer Enedahl [mailto:christoffer@...]
> > Sent: Wednesday, November 26, 2003 18:23
> > To: openLingo@yahoogroups.com
> > Subject: Re: [openLingo] Privates, software implemented or not?
> >
> >
> > Not natively. I saw a script that allowed it, but the overhead
> > was not worth
> > the trouble.
> > Stick with a namingconvention like underscore prefix:  _property , then
> > you'll know when you are writing "illegal" code.
> >
> > Christoffer
> >
> >
> > > Hi,
> > >
> > > I was wondering. Is it possible to really declare a method/variable
> > > as a private one, so that no one can address it from outside the
> > > script/object? The way I see it, is that it isn't possible. You would
> > > have program accurately. The reason I'm asking is because my boss
> > > is an OOP-loving man and he keeps asking about it.
> > >
> > > Thanks in advance,
> > >
> > > Martijn
> >
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > openLingo-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
>
>
>
>
> To unsubscribe from this group, send an email to:
> openLingo-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Just out of curiosity, can I see the script Chris?

Pranav Negandhi
concept-I
www.cimultimedia.com



> -----Original Message-----
> From: Christoffer Enedahl [mailto:christoffer@...]
> Sent: Wednesday, November 26, 2003 18:23
> To: openLingo@yahoogroups.com
> Subject: Re: [openLingo] Privates, software implemented or not?
>
>
> Not natively. I saw a script that allowed it, but the overhead
> was not worth
> the trouble.
> Stick with a namingconvention like underscore prefix:  _property , then
> you'll know when you are writing "illegal" code.
>
> Christoffer
>
>
> > Hi,
> >
> > I was wondering. Is it possible to really declare a method/variable
> > as a private one, so that no one can address it from outside the
> > script/object? The way I see it, is that it isn't possible. You would
> > have program accurately. The reason I'm asking is because my boss
> > is an OOP-loving man and he keeps asking about it.
> >
> > Thanks in advance,
> >
> > Martijn
>
>
>
>
> To unsubscribe from this group, send an email to:
> openLingo-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Not natively. I saw a script that allowed it, but the overhead was not worth
the trouble.
Stick with a namingconvention like underscore prefix:  _property , then
you'll know when you are writing "illegal" code.

Christoffer


> Hi,
>
> I was wondering. Is it possible to really declare a method/variable
> as a private one, so that no one can address it from outside the
> script/object? The way I see it, is that it isn't possible. You would
> have program accurately. The reason I'm asking is because my boss
> is an OOP-loving man and he keeps asking about it.
>
> Thanks in advance,
>
> Martijn

----- Original Message -----
From: "ithemabv" <ithemabv@...>
>
> I was wondering. Is it possible to really declare a method/variable
> as a private one, so that no one can address it from outside the
> script/object?

No. I suggest you take a look at the list archives for in depth discussions
of this subject. The openLingo coding convention is to call private
properties _PropertyName and public properties pPropertyName.

- Robert

Hi,

I was wondering. Is it possible to really declare a method/variable
as a private one, so that no one can address it from outside the
script/object? The way I see it, is that it isn't possible. You would
have program accurately. The reason I'm asking is because my boss
is an OOP-loving man and he keeps asking about it.

Thanks in advance,

Martijn

> Yes you can, you are simply naming the ancestor property wrong.
> if should be ancestor not _ancestor

Thanks, it works perfectly.

Martijn

> I've read somewhere that the object you create inherits all the
> properties and methods of the ancestor script.
> I've tried to access the width property as followed.
>
> obj = script("object").new(100,200)
> somevar = obj.getwidth()
>
> The error reports that the handler is not found in the object. As I
> mentioned I thought that the methods where inherited by the object.
> Can someone explain to me how to call the method properly?

Yes you can, you are simply naming the ancestor property wrong.
if should be ancestor not _ancestor

> Hi, I've created an object wich has an ancestor.
> like this
> -------------------
> --ancestor script
> property _width
>
> on new me, width
>  setWidth me, width
>  return me
> end
>
> on setWidth me,width
>   _width = width
>   return me -- < not needed here hander
> end
>
> on getWidth me
>   return _width
> end
>
> -------------------
> --object script
> property _heigth
> property ancestor --changed
>
> on new me, heigth, width
>   me.ancestor = script("ancestor").new(width) --changed
>   _heigth = heigth
>   return me
> end
> -------------------
>

Hi, I've created an object wich has an ancestor.
like this
-------------------
--ancestor script
property _width

on new me, width
  setWidth me, width
  return me
end

on setWidth me,width
   _width = width
   return me
end

on getWidth me
   return _width
end

-------------------
--object script
property _heigth
property _ancestor

on new me, heigth, width
   _ancestor = script("ancestor").new(width)
   _heigth = heigth
   return me
end
-------------------

I've read somewhere that the object you create inherits all the
properties and methods of the ancestor script.
I've tried to access the width property as followed.

obj = script("object").new(100,200)
somevar = obj.getwidth()

The error reports that the handler is not found in the object. As I
mentioned I thought that the methods where inherited by the object.
Can someone explain to me how to call the method properly?

TIA,
Martijn