hello my friend

i am a developer and i useing lingo.
i very interested in OOP in lingo.
i have skill in lingo and may i can help you.

m.b.tadi

Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download
Now! http://messenger.yahoo.com/download.php

Thanks heaps for the lateral thinking Robert: that should do the trick
nicely!

Much obliged indeed.

James.

--- In openLingo@yahoogroups.com, Robert Tweed <robert-lists@k...> wrote:
> natcher00 wrote:
> > I'm interested in something like this, but that can perform as a
> > function in Authorware: any ideas?
> >>
> >>Base64.txt
> >>Base64 encoding and decoding
>
> Personally, I have no experience with Authorware. From the looks of
> things though, it just uses standard JavaScript. You should easily be
> able to find a JavaScript implementation of base-64. It won't have my
> non-standard url-safe mode, but all you need to do is change two of the
> characters if you need that option.
>
> FYI, first result on Google:
> http://rumkin.com/tools/compression/base64.php
>
> - Robert

natcher00 wrote:
> I'm interested in something like this, but that can perform as a
> function in Authorware: any ideas?
>>
>>Base64.txt
>>Base64 encoding and decoding

Personally, I have no experience with Authorware. From the looks of
things though, it just uses standard JavaScript. You should easily be
able to find a JavaScript implementation of base-64. It won't have my
non-standard url-safe mode, but all you need to do is change two of the
characters if you need that option.

FYI, first result on Google:
http://rumkin.com/tools/compression/base64.php

- Robert

Hi Robert (et al),

I'm interested in something like this, but that can perform as a
function in Authorware: any ideas?

Cheers,

James "natcher00" Helm
--- In openLingo@yahoogroups.com, "Robert Tweed" <robert@k...> wrote:
> The files I have uploaded are:
>
> Base64.txt
> Base64 encoding and decoding
>

deroetztaler wrote:
>
> I joined this group because I found some links to here telling there was a
> "URLDECODE" code snippet available.
> The full text search keeps me without results.

That's one of mine. It's in here:

http://groups.yahoo.com/group/openLingo/files/Robert%20Tweed/

Direct Link: http://tinyurl.com/6ugfx (may not work, but I think it will).

Note that the way files are sorted is that each member creates a
directory in the files area, and they upload their files into their own
area. This is not an ideal system because it's hard to search, but it's
the best system we have at the moment.

- Robert

Hi all,

I joined this group because I found some links to here telling there was a
"URLDECODE" code snippet available.
The full text search keeps me without results.

Any help greatly appreciated

Niko

Hi Friends :

   i m RITESH PATEL, From India.
   I want Script For cd drive configuration/ Cheacking.



    Pls Reply Urgently.

   Thanks
         Ritesh Patel.

Hi everyone,

I've just uploaded three scripts to:

   <http://groups.yahoo.com/group/openLingo/files/openSpark/>

Two of these (GroupBroker and SpriteGroup) allow you to create a group of
sprites that share a common ancestor.

For example: you may need four separate sprites (an integer slider, an
integer input field and a pair of nudge arrows) to create a unified integer
input control.  You would drop the Sprite Group behavior on all four
sprites, and place the code to manage them in the shared ancestor instance.
The Group Instance Broker script allows you to identify such common
ancestors by ID, so you can have several distinct input controls at the same
time.

Other examples:
Text + scrollbar + hilite sprite
Multiple input fields + Revert + Cancel + OK button


The other script allows you to convert strings with high-ANSI characters and
line breaks from Windows to Mac format and back on the fly.  Unix line feeds
(as created by OSX's TextEdit) are also handled.


These scripts are not yet in openLingo approved format.  I would welcome
feedback on them first.

Cheers,

James

----- Original Message -----
From: "James Newton" <james.newton@...>
>
> > - Do not comment indvidual lines or chunks of code unless absolutely
> > necessary. In such cases, explain *why* the code is written the way it
is,
> > not *what* the code does, unless it really is not obvious what the code
is
> > doing by looking at it.
>
> There are times when I would want to comment the *what* of an individual
> line of code.  For example, an Undo script may need to do several things,
> such as altering a data structure, updating an interface in a MIAW and
> updating an interface on the Stage.  Each of these operations would need a
> comment to distinguish it from the others, even if the operation itself
only
> required a single line of code.

Bear in mind that these are only *guidelines* not hard-and-fast rules (which
the naming conventions pretty much are). They are just a guide to writing
good code. There are of course, exceptions. Rather than try to list all the
exceptions it's better to just leave it up to the good judegement of the
programmer to know when something makes sense. In a more complete writeup
I'd probably stress the flexibility of the above a bit more, but the good
thing about putting it that way is that it makes people _think_ about their
comments a bit more, and avoid over-commenting.

> > The openLingo naming convention is:
> >
> > - Names are always first-letter caps with the first word (or prefix)
being
> > all lowercase. Only exception is private globals...
> > - Private globals begin with a double underscore and words are all
> > lowercase, separated by underscores, e.g., __global_controller
>
> Excuse my ignorance, but what is a "private global"?

Well there is no such thing as a private anything in Lingo. However, the
concept of a private global is similar to a static variable in C, where the
variable should be local to a specific package or collection of packages,
but it simply isn't possible to create such a thing in Lingo.

In fact, it is possible to create static variables but they are very slow to
access, so not ideal if you need to access them frequently. Also, this still
wouldn't make them any more private than a global variable, so there isn't
much point.

Basically with the openLingo naming convention, if something has an
underscore at the start of it's name you need to think twice before directly
accessing it - the chances are it doesn't belong to you, and there will
always be an alternative interface provided.

The openLingo wrapper script contains one "private" global called
__ol_singleton. No-one should ever access this variable. It is used in the
wrapper scripts, but those scripts are the only ones that should ever touch
that variable. If anyone else wants to do anything with that variable, it
should be done via the interface provided.

- Robert

On 17/6/04 3:11 pm, "Robert Tweed" <robert-lists@...> wrote:

> ... all openLingo scripts use me.xxxx to refer to properties so that
> those properties can be overridden in descendant objects while
> maintaining the correct behaviour.

Hi Robert,

That makes sense.

> - Do not comment indvidual lines or chunks of code unless absolutely
> necessary. In such cases, explain *why* the code is written the way it is,
> not *what* the code does, unless it really is not obvious what the code is
> doing by looking at it.

There are times when I would want to comment the *what* of an individual
line of code.  For example, an Undo script may need to do several things,
such as altering a data structure, updating an interface in a MIAW and
updating an interface on the Stage.  Each of these operations would need a
comment to distinguish it from the others, even if the operation itself only
required a single line of code.

> The openLingo naming convention is:
>
> - Names are always first-letter caps with the first word (or prefix) being
> all lowercase. Only exception is private globals...
> - Private globals begin with a double underscore and words are all
> lowercase, separated by underscores, e.g., __global_controller

Excuse my ignorance, but what is a "private global"?

Cheers,

James

----- Original Message -----
From: "Mathew Ray" <mathew@...>
>
> On another note, is there a good place on openLingo where people can put
> examples or proof-of-concept pieces created using the library?

At the moment, you can upload whatever you like into the files area. To keep
things organised, what we do is:

- Make a folder for your files using your own name.
- Scripts should be uploaded as a text file that folder.
- Example .dir files should be in a sub-folder named after the version of
Director in which the file was make, e.g., My Files/Director 8.5/My
Example.dir

If you want to upload closed-source projects etc., just put them in another
directory, called "showcase" or something.

The full site, when finished, will have a showcase area where people can
post links and screenshots. I don't think I'll be able to allow people to
upload work directly to the openLingo server because it would most likely
require too much bandwidth, which I wouldn't be able to afford since I've
got to pay for it myself.

- Robert

Consider the notion seconded.

On another note, is there a good place on openLingo where people can put
examples or proof-of-concept pieces created using the library?

Thanks,
~Mathew


Stefan Ladstaetter wrote:
>>Does this make sense, or am I being pedantic?
>
>
> <unlurk>
> makes sense to me, that's my style, too.
> </unlurk>

----- Original Message -----
From: "James Newton" <james.newton@...>
>
> I'm new to this list, so perhaps there are reasons for working in the
> approved way that I am not aware of.  My reasons for the changes are
> connected with debugging:
>
> * If the "if ... then" statement is on the same line as the action it
>   generates, step by step debugging will not show whether the line is
>   executed or not
> * If the result is calculated on the same line as it is returned,
>   you may not be able to see what value *is* returned, either in the
>   current handler or in the calling handler.

Not really, these points were never brought up before, so it was never a
criteria for whether something should be approved or not. As far as making
debugging easier is concerned, these are good points that I wouldn't have
noticed myself because I don't use the debugger. Ever.

I'd be happy enough to add these changes to the conventions and update any
approved code accordingly. Suggestions such as these are always welcome -
it's kinda the whole point of openLingo.

> * The "me." prefix is unnecessary for properties declared in the
>   current script.  It is only required if the property is declared
>   in an ancestor.  I omit the "me." where possible, so that it is
>   clear when a property is "personal" or "inherited".

The reason for the me prefix (and this *was* discussed at length) is because
of the way inheritance works in Lingo. If you override a property in a
descendant object and then call a handler in the ancestor then:

val = pProperty -- the value set locally
val = me.pProperty -- the "real" value, set in the descendant

It is therefore mandated that all openLingo scripts use me.xxxx to refer to
properties so that those properties can be overridden in descendant objects
while maintaining the correct behaviour. It's not a big deal, and it also
makes the code very marginally slower, but these rules are supposed to make
the code easier to expand later, if/when the library becomes much more
complex in the future.

BTW, I did a complete set of tests relating to this, which are here:
http://www.killingmoon.com/director/tests/inheritance/

> (The "t" prefix for temporary variables follows the practice used in the
> more recent Director behaviors, which also use a "p" prefix for
properties).

The openLingo convention for a local variable is to use the prefix "v" (for
"variable").

I wrote a short summary of the openLingo conventions in a recent post on
m.d.l - it's probably not as complete as a full writeup, but since the basic
philosophy of openLingo is to have a fairly simple and not overly-strict set
of conventions anyway, it's probably not a bad summary. Here it is:

Some general guidelines for code style:

- Try to keep functions short (one page max), break complex things down into
smaller chunks, but make each function general purpose. Give functions
meaningful names that say what the function does (the name should be or
include a verb). If a function must be longer than ideal, try to split it
into sub-chunks with a short comment to say what each part does.

- Give variables meaningful names. Don't use x, y, i, j, except in short
loops or places where it is absolutely obvious what they mean.

- Comment files and functions. Explain what the file is, who has worked on
it, etc. Say what each function does, what the inputs and outputs are, etc.

- Do not comment indvidual lines or chunks of code unless absolutely
necessary. In such cases, explain *why* the code is written the way it is,
not *what* the code does, unless it really is not obvious what the code is
doing by looking at it.

The openLingo naming convention is:

- Names are always first-letter caps with the first word (or prefix) being
   all lowercase. Only exception is private globals (see below).
- Functions are verbs (says what the function *does*)
- Object instances / variables are nouns (says what the variable *is*).
- Properties start with lowercase "p", e.g., pMyVariable
- Globals start with lowercase "g", e.g., gMyGlobal
- Function arguments (except "me") start with a lowercase "a", e.g., on
   doStuff me, aTarget
- Local variables start with a lowercase "v", e.g., vLocH
- Private properties begin with an underscore, e.g., _dontTouchThis
- Private globals begin with a double underscore and words are all
   lowercase, separated by underscores, e.g., __global_controller

- Robert

> Does this make sense, or am I being pedantic?

<unlurk>
makes sense to me, that's my style, too.
</unlurk>

On 17/6/04 6:11 am, "Christoffer Enedahl" <christoffer@...> wrote:
> I had some time to tweak the approved openLingo scripts tonight between the
> children screams.

Hi everyone,

I notice that the approved scripts contain structures like:

on getCount me
   _errorSymbol = void --Reset any previous error

   if ListP( me._instancePropList ) then return me._instancePropList.count
   else return 0
end


I would suggest restructuring the handler above as:

on getCount me
   _errorSymbol = void --Reset any previous error

   -- Place "if ... then" and action on separate lines
   if ListP(_instancePropList) then -- no "me."
     tResult = _instancePropList.count
   else
     tResult = 0
   end if

   return tResult -- calculate result and return it on different lines
end getCount


I'm new to this list, so perhaps there are reasons for working in the
approved way that I am not aware of.  My reasons for the changes are
connected with debugging:

* If the "if ... then" statement is on the same line as the action it
   generates, step by step debugging will not show whether the line is
   executed or not
* If the result is calculated on the same line as it is returned,
   you may not be able to see what value *is* returned, either in the
   current handler or in the calling handler.
* The "me." prefix is unnecessary for properties declared in the
   current script.  It is only required if the property is declared
   in an ancestor.  I omit the "me." where possible, so that it is
   clear when a property is "personal" or "inherited".

(The "t" prefix for temporary variables follows the practice used in the
more recent Director behaviors, which also use a "p" prefix for properties).


Does this make sense, or am I being pedantic?

James

Hi!

I had some time to tweak the approved openLingo scripts tonight between the
children screams.
First I changed the default prefix in openLingo from "ol" to "ol_". Not
sure if that is what we want but it looks better in the castwindow to me.
Secondly I changed the name of "openlingo Singleton" to "ol_Singleton" so
it will work under the default openlingo Prefix. ie: openLingo(#singleton).

I've added errorHandling to the singleton script so I could handle when the
requested script was not found or no object was returned when creating the
same.
Thats it.

To get the files navigate to www.openLingo.org > yahoo site > logon >
files > christoffer enedahl.
The names are as below, (waiting approval)
<http://f1.grp.yahoofs.com/v1/0LTQQF3qK1jl-1762E4yUABYoZTeqoZRBNQ5AN6ufNzuZs49wj\
6CWiHwp_4QXbEWs4BaUdfZIoT9LfZ2asV8iM_hc459/Christoffer%20Enedahl/ol_Singleton%20\
%28v2.1%29>ol_Singleton
(v2.1)
<http://f6.grp.yahoofs.com/v1/0LTQQLeRar3l-176VqqswAXKVK067_kESghRQDxwAFEa5UbEAj\
xR5KP8WyGaM_uj9U-V7qOvdz0edKqUkjX33lNfy3lA/Christoffer%20Enedahl/openLingo%20%28\
v1.2%29>openLingo
(v1.2)


BTW, it would be cool to have a openLingo ScriptDownloader xtra/dcr that
downloaded/updated openlingo scripts from the web in director as a miaw.
Like mediamacros stagemanager. Well, another task on the list not being
done this year.

/Christoffer

----- Original Message -----
From: "Mathew Ray" <mathew@...>
>
> I agree to a degree... One issue is that several people I have mentioned
> this list to will not sign up due to the commercial nature of
> yahoogroups and their spam/privacy policy. The potential hassle is not
> worth it to them, and as silly as it sounds, the Yahoo affiliation
> doesn't do much for the image of the group.

This was discussed in the early days and at that time it was not a problem
for the vast majority of people, other than the minor hassle of creating a
Yahoo ID for those who did not have one already.

FWIW, Yahoo's spam policy isn't as bad as it's made out to be, and although
Yahoo groups tend to be the target of random spammers, I set the group to
first post moderated a long time ago to combat that problem. So although I
see a small number of spam messages, not one has made it through to the
list. The only thing we do get occasionally is spam uploads in the files
area, but those are deleted pretty quickly.

Hopefully it won't be an issue too much longer anyway....

> Is there an easy way of
> setting up the same functionality on the website? I may be able to
> provide some of that functionality with a portal system on my server if
> it would be helpful.

Yes and no. The site is still in development and one of the things I'm
working on is a dual-ported mailinglist manager to handle sub-groups and
other useful things, but which allows people to use either email or the
website. This is actually relatively easy to set up with plain text emails
only, but the problem is the number of MIME types that now exist, so it
could take some time to get working reliably.

However, if the new interest in the group is going to be significantly
dampened by the Yahoo group issue then I should be able to set up a standard
mailinglist fairly quickly. I've just avoided doing this until now because I
don't want to go around changing things that may change again in the future,
causing whatever disruption to the people already on the list. If there is a
lot of discussion on Direct-L and a significant number of people are
unwilling to join the Yahoo group then I will certainly make sure we have
another mailinglist quickly, to avoid losing the new momentum.

- Robert

I agree to a degree... One issue is that several people I have mentioned
this list to will not sign up due to the commercial nature of
yahoogroups and their spam/privacy policy. The potential hassle is not
worth it to them, and as silly as it sounds, the Yahoo affiliation
doesn't do much for the image of the group. Is there an easy way of
setting up the same functionality on the website? I may be able to
provide some of that functionality with a portal system on my server if
it would be helpful.

Thanks,
~Mathew


Robert Tweed wrote:
> ----- Original Message -----
> From: "wilson.bitzone" <wilson.bitzone@...>
>
>>Why donīt host the hole project at sourceforge.net?
>
>
> This idea has been suggested several times in the past, but there are many,
> myself included, who feel that sourceforge is not user-friendly enough for

> the intended audience of this sort of project. I feel it would put off more
> people than it would bring in. I believe that the Yahoo group is a perfectly
> adequate temporary home, and when the site is finished it will make a much
> better permanent home than SF or anywhere else that I've seen so far as I am
> tailoring it specifically to the needs of openLingo, which does need to
> appeal to designers and multimedia authors as much as hardcore nerds and
> programmers.
>
> - Robert

----- Original Message -----
From: "wilson.bitzone" <wilson.bitzone@...>
>
> Why donīt host the hole project at sourceforge.net?

This idea has been suggested several times in the past, but there are many,
myself included, who feel that sourceforge is not user-friendly enough for
the intended audience of this sort of project. I feel it would put off more
people than it would bring in. I believe that the Yahoo group is a perfectly
adequate temporary home, and when the site is finished it will make a much
better permanent home than SF or anywhere else that I've seen so far as I am
tailoring it specifically to the needs of openLingo, which does need to
appeal to designers and multimedia authors as much as hardcore nerds and
programmers.

- Robert

Dear Robert

Why donīt host the hole project at sourceforge.net?
Lot of features including open foruns, cvs, etc.
Just a sugestion.
My best regards,
Wilson
   ----- Original Message -----
   From: Robert Tweed
   To: openLingo@yahoogroups.com
   Sent: Thursday, May 27, 2004 1:07 PM
   Subject: [openLingo] [DIRECT-L] openLingo


   [ This was supposed to be CC'd, but Yahoo had screwed up my membership
   settings and bounced it. Original message below. ]

   Hi all,

   I haven't been subscribed to Direct-L for more than a year or so because
   I've had difficulty dealing with the traffic levels at times, but I've
   decided to sign up again, at least for a while. The main reason for this is
   because I hear there is some renewed interest in a unified open-source
   library for Director. It just so happens that such a project already exists
   and it is called openLingo.

   I haven't managed to really follow the new suggestions in the archives about
   this idea, but I daresay there will be some overlap with what's already been
   discussed on the openLingo list, as well as undoubtably some new ideas. For
   those of you who have never come across openLingo, or remember it but aren't
   sure where the project is at, here is an update:

   The basic goal of the project is to create a single library of open-source
   code that follows standard conventions of naming, calling, etc., with the
   ultimate aim being to provide, as closely as possible, the most optimal
   solutions to common scripting problems, along with quality documentation.

   The way the project is intended to operate is that people submit code in a
   "raw" state and the code is improved, commented, documented and so on by
   other members of the community until the code meets the openLingo standards.
   These standards have already been discussed on the list. Of course, if
   people submit code already in this state then there is no need for
   improvement unless people can spot optimisations, etc. Anyone is free to
   contribute whatever they like.

   To ensure that the code that goes into the library is of the quality people
   will expect, all submissions are eventually moderated. At present I am the
   only moderator, but when openLingo.org is completed, Cristoffer Enedahl will
   take over a lot of the workload. Anyone else who can prove they are
   dedicated enough will be welcome to join the group of moderators as the
   project grows. It is first and foremost a community project, so I try to be
   more of a chairman than a benevolent dictator.

   There are currently some bottlenecks with the project:

   - The Yahoo group is not ideal as it does not provide a CVS or similar
   codebase management. Instead, we are temporarily using the "files" area,
   with individuals taking responsibility for their own versions of any code
   that is submitted. The main problem with this is the lack of an index, so it
   is hard for people to find code. SourceForge was considered as an
   alternative, but I believe that it would put off the majority of users
   because it is too technical and user-unfriendly.

   [ There is a "preview" code download page at www.openlingo.org/code/ - This
   contains the only currently fully approved scripts, which are the basis for
   the whole library. ]

   - The openLingo.org site is presently in development. This will solve the
   problems with the Yahoo group, but the bottleneck here is my time being
   extremely limited and I keep having to put the project on the back burner to
   do "real" work.

   - Because the site is not finished and many are holding off contributing
   until it is finished, the mailing list has got very quiet lately. I would
   certainly encourage anyone who is interested in such a project to go along
   and start up some new threads. If nothing else, this will help renew my
   enthusiasm for the project and inspire me to cut some corners to get the
   site finished ASAP! Certainly there is no reason why the mailinglist
   shouldn't be busy, as people can discuss the project and submit new code
   even without the site being ready.

   I believe that the focus of what has been discussed here is slightly
   different from the focus of openLingo. The focus of openLingo is on creating
   a code library upon which behaviours and components can be built easily. The
   focus (if I have got it right) of what has been discussed here is on
   creating drop-in widgets. I have always maintained that drop-in widgets
   should be an important part of openLingo, but always at a top level that is
   outside of the main library, built on top of the library. I believe they
   should be as lightweight as possible, whereas the library should contain all
   the heavy code within a highly flexible API.

   Anyway, I think the best thing is to jump on the renewed interest in this
   type of project and get the discussion going on the openLingo list. I'm
   quite happy to go back over old ground, particularly because there are
   probably a lot of people now on the openLingo list who do not remember the
   original discussions and we could all do with having our memories refreshed,
   and some new life being injected into the project. It'll be good to get
   things really moving again :-)

   - Robert


         Yahoo! Groups Sponsor
               ADVERTISEMENT





------------------------------------------------------------------------------
   Yahoo! Groups Links

     a.. To visit your group on the web, go to:
     http://groups.yahoo.com/group/openLingo/

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

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



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

[ This was supposed to be CC'd, but Yahoo had screwed up my membership
settings and bounced it. Original message below. ]

Hi all,

I haven't been subscribed to Direct-L for more than a year or so because
I've had difficulty dealing with the traffic levels at times, but I've
decided to sign up again, at least for a while. The main reason for this is
because I hear there is some renewed interest in a unified open-source
library for Director. It just so happens that such a project already exists
and it is called openLingo.

I haven't managed to really follow the new suggestions in the archives about
this idea, but I daresay there will be some overlap with what's already been
discussed on the openLingo list, as well as undoubtably some new ideas. For
those of you who have never come across openLingo, or remember it but aren't
sure where the project is at, here is an update:

The basic goal of the project is to create a single library of open-source
code that follows standard conventions of naming, calling, etc., with the
ultimate aim being to provide, as closely as possible, the most optimal
solutions to common scripting problems, along with quality documentation.

The way the project is intended to operate is that people submit code in a
"raw" state and the code is improved, commented, documented and so on by
other members of the community until the code meets the openLingo standards.
These standards have already been discussed on the list. Of course, if
people submit code already in this state then there is no need for
improvement unless people can spot optimisations, etc. Anyone is free to
contribute whatever they like.

To ensure that the code that goes into the library is of the quality people
will expect, all submissions are eventually moderated. At present I am the
only moderator, but when openLingo.org is completed, Cristoffer Enedahl will
take over a lot of the workload. Anyone else who can prove they are
dedicated enough will be welcome to join the group of moderators as the
project grows. It is first and foremost a community project, so I try to be
more of a chairman than a benevolent dictator.

There are currently some bottlenecks with the project:

- The Yahoo group is not ideal as it does not provide a CVS or similar
codebase management. Instead, we are temporarily using the "files" area,
with individuals taking responsibility for their own versions of any code
that is submitted. The main problem with this is the lack of an index, so it
is hard for people to find code. SourceForge was considered as an
alternative, but I believe that it would put off the majority of users
because it is too technical and user-unfriendly.

[ There is a "preview" code download page at www.openlingo.org/code/ - This
contains the only currently fully approved scripts, which are the basis for
the whole library. ]

- The openLingo.org site is presently in development. This will solve the
problems with the Yahoo group, but the bottleneck here is my time being
extremely limited and I keep having to put the project on the back burner to
do "real" work.

- Because the site is not finished and many are holding off contributing
until it is finished, the mailing list has got very quiet lately. I would
certainly encourage anyone who is interested in such a project to go along
and start up some new threads. If nothing else, this will help renew my
enthusiasm for the project and inspire me to cut some corners to get the
site finished ASAP! Certainly there is no reason why the mailinglist
shouldn't be busy, as people can discuss the project and submit new code
even without the site being ready.

I believe that the focus of what has been discussed here is slightly
different from the focus of openLingo. The focus of openLingo is on creating
a code library upon which behaviours and components can be built easily. The
focus (if I have got it right) of what has been discussed here is on
creating drop-in widgets. I have always maintained that drop-in widgets
should be an important part of openLingo, but always at a top level that is
outside of the main library, built on top of the library. I believe they
should be as lightweight as possible, whereas the library should contain all
the heavy code within a highly flexible API.

Anyway, I think the best thing is to jump on the renewed interest in this
type of project and get the discussion going on the openLingo list. I'm
quite happy to go back over old ground, particularly because there are
probably a lot of people now on the openLingo list who do not remember the
original discussions and we could all do with having our memories refreshed,
and some new life being injected into the project. It'll be good to get
things really moving again :-)

- Robert

I'm sorry I forgot to thank you guys for helping me with using the
CopytoClipboard command. I was able to get it working.

Max

----- Original Message -----
From: "Ben St Johnston" <ben@...>
>
> That might not always work. If you are providing a library of "classes"
> which people can extend,

But that's not what we are doing. We are providing an object-oriented
toolset, which people can incorporate into higher-level scripts. There will
be a collection of high-level scripts and behaviours that use the main
library as well, so perhaps such classes would fall into that category, but
that is not part of the main project.

> It is also the case that lingo cannot contruct javascript objects and vice
> versa, although given a reference either language can use objects written
> in the other language. Therefore, you should provide factory methods (e.g.
> createMyObject()) rather than expecting people to call new MyObject or
> script("MyObject").new().

This is true, at some point we need to have a generic factory object as part
of the library anyway, in fact it's one of the things we should have already
addressed.

If you want to instantiate ECMAScript objects in Lingo then you can simply
write your scripts slightly differently - in fact, this method is
preferrable in ECMAScript because of the way inheritance works (I won't get
too into that just now). What you do is this:

function someobject_memberFunction()
{
     return this.someProperty;
}

function someobject()
{
     var temp = new Object();
     temp.someProperty = "a property";
     temp.memberFunction = someobject_memberFunction;
     return temp;
}

As opposed to:

function someobject()
{
     this.someProperty = "a property";
     this.memberFunction = someobject_memberFunction;
}

(the latter requires the new operator, whereas the former is simply a
self-contained factory for the object)

BTW, I always declare member functions outside of the class definition and
use that convention, i.e.: classname_functionname. I haven't been doing much
JavaScript programming lately, but if I were, I would start using this
instantiation method more because JavaScript does not have any inheritance
in the C++ sense, but by using these self-contained factory functions
instead of a class function, you can create descendants in the same way as
any other type of object so the whole thing becomes a lot more transparent.

Unfortunately there is no reverse equivalent for creating Lingo objects in
JavaScript (that I know of) but a generic factory class within the openLingo
framework would solve the problem.

- Robert

That might not always work. If you are providing a library of "classes"
which people can extend, then you should provide them as javascript and
lingo, as you can only extend a lingo Parent script in lingo, and you can
only use a javascript "class" as a prototype for another javascript "class".


It is also the case that lingo cannot contruct javascript objects and vice
versa, although given a reference either language can use objects written in
the other language. Therefore, you should provide factory methods (e.g.
createMyObject()) rather than expecting people to call new MyObject or
script("MyObject").new().

Ben

-----Original Message-----
From: Robert Tweed [mailto:robert-lists@...]
Sent: 10 March 2004 12:14
To: openLingo@yahoogroups.com
Subject: Re: [openLingo] javascript in MX 2004

----- Original Message -----
From: "David Turk" <mediasense@...>
>
> I would wait to DMX 2005 prior to considering JavaScript in a serious way.

JFTR, I think that openLingo should progress as previously forseen, but we
should make sure the flexbility is there that any module can be either Lingo
or ECMAScript, depending on which is most appropriate for the task. For
anyone who is pre-judging one as better than the other, we should bear in
mind that tests people have done on other lists have shown that ECMAScript
is actually quite a bit faster than Lingo in some circumstances. You also
have nice things like regular expressions. However, there are still a couple
of things that don't seem to be quite there yet, so basically it's like
this: given two implementations, one in ECMAScript and one in Lingo, we
simply test to see which is best and use that one.

- Robert




Yahoo! Groups Links

----- Original Message -----
From: "David Turk" <mediasense@...>
>
> I would wait to DMX 2005 prior to considering JavaScript in a serious way.

JFTR, I think that openLingo should progress as previously forseen, but we
should make sure the flexbility is there that any module can be either Lingo
or ECMAScript, depending on which is most appropriate for the task. For
anyone who is pre-judging one as better than the other, we should bear in
mind that tests people have done on other lists have shown that ECMAScript
is actually quite a bit faster than Lingo in some circumstances. You also
have nice things like regular expressions. However, there are still a couple
of things that don't seem to be quite there yet, so basically it's like
this: given two implementations, one in ECMAScript and one in Lingo, we
simply test to see which is best and use that one.

- Robert

You are probably right - its just a shame that parent/child lingo is only at
version 0.9 alpha!

At least lingo works with the debugger though - trying to step through
javascript is not enlightening!

Ben

________________________________

From: David Turk [mailto:mediasense@...]
Sent: 09 March 2004 20:01
To: openLingo@yahoogroups.com
Subject: Re: [openLingo] javascript in MX 2004


If you look at the big picture, you will find (feel) that the
JavaScript in MX 2004 has a version 1 feel.

I would wait to DMX 2005 prior to considering JavaScript in a serious way.

If you look at the big picture, you will find (feel) that the
JavaScript in MX 2004 has a version 1 feel.

I would wait to DMX 2005 prior to considering JavaScript in a serious way.

Hi everyone,

I have been trying out the new javascript functionality and although
I expect I am not the only one, there is precious little
discussion/comment/opinion around so I thought I might start some.

I like the idea of using javascript over lingo for several reasons,
but there seem to be a few problems with the object oriented parts.
Admittedly, as a C++ programmer, I thought it unfortunate that java
didnt have "friends", so my standards are quite high. Moving to
lingo, I found Parent/Child scripts quite frustrating, but,
similarly to everyone else, you find ways to do what you want to do
which work, and you stick to them. If you move to using javascript
then it seems you need to go through this process again.

Firstly, I cant find way anyway for behaviours to inherit.
Inheriting in behaviours (instantiated through the beginSprite
rather than the new method) was a bit flaky before; initialisation
was the main problem (e.g. you needed to pass the spritenum down to
the ancestors constructor). With javascript you dont directly
instantiate the base class - you set the prototype and the
constructor gets called and the properties get set immediately
before the subclass gets instantiated (but only when you new
something - not when you beginSprite it)! So, using inheritance in
behaviours never worked as would like and was best avoided. With
javascript this decision (unless you know better) is made for you.

Overriding methods and properties works better (in some ways) in
javascript than in lingo - in lingo you could end up with an
inherited method updating a property in the ancestor which was
hidden by a property of the same name in the child depending on
where "me" came from. In javascript, "this" seems to reliably
correspond to the child (as long as you dont start playing with the
__proto__ property).

I tried to use the __proto__ property like I might use the ancestor
property (or use callAncestor), but I cannot see a way to call a
method on a base class once it has been overridden. I often used
this to chain initialisers, for example.

Initialisation is an issue therefore. As the contructor of the base
class gets called before the constructor of the subclass it doesnt
make sense to initialise properties except in leaf classes. Where
initialisation is complex (e.g. objects registering with container
objects) it seems best to keep this completely separate from the
construction. Currently, I am thinking that using static/class
methods (which you can now do), with the instanceHandle passed as
the first parameter is the most effective (it allows calls to be
chained without unnecessary initialisation or instantiation).

Presumeably many of you have come across these issues before from
using javascript in browsers, but I expect that you are prepared to
write a lot more code in Director than you would write for a
browser, so OO is more likely to play a major part.

Oh, one other thing, you cant inspect a javascript object like you
can a lingo object in the debugger or object inspector (now how hard
can that be!).

Ben

if you only need the text in the clipboard you could try
member("missionstatement").text.copyToClipboard()
or

member("missionstatement").rtf.copyToClipboard()



  >> You are the grit in my oyster

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

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]