> On 16 Jul 2016, at 1:35 PM, J. Landman Gay wrote:
>
>>> function getSMediaItemData
>>> return sMediaItemData
>>> end getSMediaItemData
>>
>> gmta
>
> Yeah, and Monte too. Parallel evolution.
I think it makes the most sense when any of the following are true:
- only want read only access
On 7/15/2016 10:25 PM, Mark Wieder wrote:
On 07/15/2016 08:20 PM, J. Landman Gay wrote:
function getSMediaItemData
return sMediaItemData
end getSMediaItemData
gmta
Yeah, and Monte too. Parallel evolution.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Softw
On 07/15/2016 08:20 PM, J. Landman Gay wrote:
function getSMediaItemData
return sMediaItemData
end getSMediaItemData
gmta
On the other hand, Brahmanathaswami, if you're going to store the data
in a backscript, why not put the functions that manipulate the array in
the backscript as well?
On 7/15/2016 8:34 PM, Sannyasin Brahmanathaswami wrote:
There is no such thing really as "a" backscript, singular. I was
always under the impression that inserting into back would be like
concatenating scripts into one giant "backscript"
Actually, they have always been independently layered sc
On 07/15/2016 06:34 PM, Sannyasin Brahmanathaswami wrote:
But now it seems we've come full circle.
Or just have getter/setter functions in the backscript and avoid global
variables altogether:
# aMediaItemData is private to the backscript
local aMediaItemData
-- but you can still get to i
mark wrote:
BR: I actually think I like using a nested object
M: Right. I wasn't suggesting *not* using a nested object, just changing
the format slightly:
{
"file_id": "gr_1999-01-11_the-path-to-god",
"file_size": null,
"file_type": null,
"format": n
> On 16 Jul 2016, at 11:34 AM, Sannyasin Brahmanathaswami
> wrote:
>
> This is important "news"
>
> There is no such thing really as "a" backscript, singular. I was always under
> the impression that inserting into back would be like concatenating scripts
> into one giant "backscript"
>
> B
This is important "news"
There is no such thing really as "a" backscript, singular. I was always under
the impression that inserting into back would be like concatenating scripts
into one giant "backscript"
But what we see now is that every script inserted into "back" is encapsulated,
if indee
> On 15 Jul 2016, at 2:21 PM, Sannyasin Brahmanathaswami
> wrote:
>
> yet to be tested, but interested in caveats
>
> assume script only stack(s)
>
> script "backScriptOne" " #saved text only as "backScriptOne.livecodescript"
>
> with script locals:
>
> local sMediaMetadata
>
> # more fun
On 07/15/2016 11:28 AM, Sannyasin Brahmanathaswami wrote:
I actually think I like using a nested object
Right. I wasn't suggesting *not* using a nested object, just changing
the format slightly:
{
"file_id": "gr_1999-01-11_the-path-to-god",
"file_size": null,
"file_type"
Usually one would do
put cr & resultOfFilter2 after resultOfFilter1
So the problem could be:
What should "filter .. after tVar" exactly do?
Simply concatenate?
Or use the current linedelimiter as "connector"?
Alex Tweedly wrote
> OK, so it's not that new - it was added in 6.1 :-)
>
> filter no
I see Mark Waddingham has already added an equivalent suggestion, so no
need for me to do so.
Thanks
-- Alex.
On 16/07/2016 00:02, [-hh] wrote:
It's connected to that. You could add your enhancement request there?
http://quality.livecode.com/show_bug.cgi?id=18010
Alex Tweedly wrote
I've
OK, so it's not that new - it was added in 6.1 :-)
filter now allows you to specify a "target container", e.g.
filter myVar with "*.livecode" into tStacks
Would it be a reasonable enhancement request to allow not just "into",
but also "after" and "before" ?
e.g.
put files() into t
f
It's connected to that. You could add your enhancement request there?
http://quality.livecode.com/show_bug.cgi?id=18010
Alex Tweedly wrote
> I've always just used the 'english' version, i.e.
>
> put the files into tVar
>
> rather than the function version,
>
>put files() into tVar
>
I've always just used the 'english' version, i.e.
put the files into tVar
rather than the function version,
put files() into tVar
but now that the function version allows an optional parameter, I'd
rather use that.
Is there a way to do the equivalent of "put the detailed files into tVa
I added an info field who's text should be
deleted or replaced by a "readme" to the zip.
The empty zipContainer is just a template.
Of course everybody can add features to his
filled container (for example the ability
to extract parts of the zip only).
*** It is at any rate now a method to upload
We do have control over the formation of the JSON, which is done by our web
server API.
for every media item record in the "item" table, there is a corresponding
series of records in the "item_formats" table. So the JSON is returning the
values for all the records in the item_formats table that
[-hh] writes:
> zipContainer is a "utility"-stack (I uploaded yesterday) that
> sets a zip as property of a stack, for uploading as stack.
Ah. OK - got it. That's clever.
As an enhancement request, how about the ability to display
text or README.md files before unzipping?
--
Mark Wieder
ahso
Sannyasin Brahmanathaswami writes:
> Question is: is the stack script replaced in the backscript? or do we start
to duplicate it everytime we insert into back?
The backscript reference is just a reference to the actual script.
So yes, you can edit it live, apply the change, and the backscript
wi
Sannyasin Brahmanathaswami writes:
> Thanks Peter.. I get it… I think… In the following we actually have a
nested object. Hence the need to use [1].
Exactly. Although the [1] is not because it's a nested object, but because
it's (in this case) a collection of one nested JSON object.
You have se
Scenario:
You have a text only stack/script/lib that you are editing, either in a text
editor or in LC script editor.
This file was previously saved on disk and is auto loaded into the backscript
on start up. So now you are continuing work in "sesson 2" changes in the
script will not be refl
zipContainer is a "utility"-stack (I uploaded yesterday) that
sets a zip as property of a stack, for uploading as stack.
Uploader has nothing more to do than to select the zip, fill
and save the container and upload it.
Downloader of the filled container have only to click a
button to extract the z
aLiveCodeArray["formats"][1]["filename"]
Peter
Thanks Peter.. I get it… I think… In the following we actually have a nested
object. Hence the need to use [1].
As per the JSON "rules" for what an array may contain
An array is an ordered collection of
[-hh] writes:
> That's not true, you can upload zips. Simply use the zipContainer there:
> Drag your zip to the stack (=zipContainer) and upload the stack
I don't understand this.
The three options are Stack, Code, and External.
What am I missing?
--
Mark Wieder
ahsoftw...@gmail.com
this seems to work:
put "media/type" into par1; put "art/paint" into par2; TestParams par1, par2
from the message box.
Kind regards
Bernd
Sannyasin Brahmanathaswami wrote
> in msg box enter
>
> testParams "1+2", "3+4"
>
> result:
>
> 1+2
> 7
>
> "
wasn't aware of that.. thanks for the hesds up.
-
Andy Piddock
My software never has bugs. It just develops random features.
Copy the new cloud space, get your free 15GB space now:
Get Copy
Script editor Themer for LC http://2108.co.uk
PointandSee is a FREE simple but full feature
26 matches
Mail list logo
