Movie problems in LiveCode

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Movie problems in LiveCode

stgoldberg@aol.com
Regarding the problem of the LC 6-7 series not allowing relative paths on the Macintosh:

>On 3/24/2015 10:26 AM, Richard Gaskin wrote:

> I've always been wary of shipping things that rely on
>relative paths, since any other script can change the
>default directory out from under me at any time.
>In apps where the media I'm playing resides in a single
>folder. I often just have a central handler cover that to
>which I pass the file's short name only and it takes care
>of the rest, e.g.:
>
> on PlayMovie pFile
>    put specialFolderPath("documents")&"/MyApp/media/"& pFile into
tPath
>    if there is not a file tPath then
>       answer "Media file missing: "& tPath
>       exit to top
>    end if
>    play tPath
> end PlayMovie

>Jackie Landman Gay wrote:
>That's exactly what I do too, I've never trusted relative paths.

Richard and Jackie, does your reluctance to use relative paths
also extend to the distribution of standalones, or is it just stacks
that present the problem? I’m not experienced enough to follow the above script.
Perhaps you can recommend a place where I can find a more
detailed explanation.
Thanks.

Stephen Goldberg, President
Medmaster Publishing Co.
Prof Emeritus, Univ Miami Miller School of Medicine
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Movie problems in LiveCode

Richard Gaskin
stgoldberg wrote:

 >>On 3/24/2015 10:26 AM, Richard Gaskin wrote:
 >
 >> I've always been wary of shipping things that rely on
 >>relative paths, since any other script can change the
 >>default directory out from under me at any time.
 >>In apps where the media I'm playing resides in a single
 >>folder. I often just have a central handler cover that to
 >>which I pass the file's short name only and it takes care
 >>of the rest, e.g.:
 >>
 >> on PlayMovie pFile
 >>    put specialFolderPath("documents")&"/MyApp/media/"& pFile into
 > tPath
 >>    if there is not a file tPath then
 >>       answer "Media file missing: "& tPath
 >>       exit to top
 >>    end if
 >>    play tPath
 >> end PlayMovie
 >
 >>Jackie Landman Gay wrote:
 >>That's exactly what I do too, I've never trusted relative paths.
 >
 > Richard and Jackie, does your reluctance to use relative paths
 > also extend to the distribution of standalones, or is it just stacks
 > that present the problem?

It's not so much a problem (at least not while QuickTime existed) as it
is an opportunity to centralize program logic for easier scripting in
the short term and easier maintenance over the long term.

Without centralizing the playback handling, I'd need to write paths to
the media and check for the file's existence everywhere throughout my
code that I need to play a movie.

By centralizing it in a common handler, the scripts that call it are
very short:

   on mouseUp
       PlayMovie "SomeFile.mov"
   end mouseUp

...and all the details for how that file is found, verified to exist,
and then played are handled in one handler.

So there's an immediate benefit while I'm writing the program, and it
only gets better over time:  if I later need to change anything about
how movies are played, I change only one handler and everything
throughout my app that calls it benefits from that change immediately
without any of those calls needing to be changed themselves.


 > I’m not experienced enough to follow the above script.
 > Perhaps you can recommend a place where I can find a more
 > detailed explanation.

The Dictionary entry for the specialFolderPath function is good reading,
and worth taking some time to experiment with.

For security reasons, OSes are increasingly limiting the places
applications can access files.  The specialFolderPath function returns
the path to a good many "special" folders, directories the OS guidelines
recommend for certain types of files, such as Preferences and
Application Support, and handles constants for other commonly-used
folders like Desktop and Home.

All that's happening in that handler is using that function to build a
full path at runtime, with an additional step to make sure the file
exists (you never know what people might do with stuff after it's
installed, which is why more than 30% of an app's code on average isn't
feature-related but merely error-checking).

Let's look at each part:

   put specialFolderPath("documents")&"/MyApp/media/"& pFile into tPath

This calls the specialFolderPath function, asking for the path to the
Documents folder.  Mac, Windows, and Linux all have a Documents folder,
the recommended place for users to store files they create with your app.

For files your app creates or installs itself it may be better to use
another folder to install those into, but the recommended location is a
bit different for each OS.  I can provide a handler for that if needed,
but for now we'll keep things simple here using one of the special
folders consistently supported across OSes.


This second bit just ensures the file exists, informing the user if it's
been removed:

   if there is not a file tPath then
      answer "Media file missing: "& tPath
      exit to top
   end if

The last line just plays the file:

   play tPath

If somewhere down the road is became necessary for the engine team to
change the play command to something like "PlayVideo", with this
centralized handler you just make that change in one place and
everything in your app immediately benefits without any other changes.

If you if need to add more error-checking, or handle platform-specific
considerations, or just about anything else, without a centralized
handler you'd need to replicate that code throughout your app every time
you want to play a movie.

Much simpler to just write:

    PlayMovie "SomeMovie.mov"

...and let one script to all the work for you in one place.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Movie problems in LiveCode

J. Landman Gay
In reply to this post by stgoldberg@aol.com
On 3/26/2015 8:47 AM, [hidden email] wrote:
> Richard and Jackie, does your reluctance to use relative paths
> also extend to the distribution of standalones, or is it just stacks
> that present the problem?

I do it mostly for the reasons Richard outlined -- more control over
playback and media selection as well as the abilitly to specify
different movie playbacks by reloading the same player object.

But I get the feeling you don't want to mess around with scripts, you
just want to set a filepath once during development and forget about it.
If the IDE is changing that path then you're right, you won't be able to
do that during development. I'd submit a bug report.

But it shouldn't be an issue for a standalone. Selecting the "Copy
referenced files" in the standalone builder's Copy Files pane should
create a standalone where your referenced movies are converted to
correct filepaths inside the standalone, which is probably what you're
after. So that's a solution for standalones, even though during
development you may be stuck with absolute paths.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Accessing Amazon Database?

kee nethery
I want to build a multi-user database client that uses Amazon AWS capabilities for the centralized database.

I envision one S3 bucket for app updates. Have the app hit a text file to see if it is up to date and if not, download the latest version.

I envision some kind of SQL-ish database where shared data is stored so that each client can access and write to it.

Is anyone else out there doing this and if so, what experiences could you share with me?

Thanks in advance.

Kee Nethery
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Accessing Amazon Database?

Skip Kimpel
I am actually in the process of experimenting with Azure and SQL.  Very, very impressed with what I have been able to do so far and how easy it is to implement and manage.

SKIP

> On Apr 1, 2015, at 7:18 PM, kee nethery <[hidden email]> wrote:
>
> I want to build a multi-user database client that uses Amazon AWS capabilities for the centralized database.
>
> I envision one S3 bucket for app updates. Have the app hit a text file to see if it is up to date and if not, download the latest version.
>
> I envision some kind of SQL-ish database where shared data is stored so that each client can access and write to it.
>
> Is anyone else out there doing this and if so, what experiences could you share with me?
>
> Thanks in advance.
>
> Kee Nethery
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Accessing Amazon Database?

Vaughn Clement
In reply to this post by kee nethery
Hi Kee

I am a database developer and I am also familiar with Amazon's seller
reports. The reports can be exported so the data is available to use in a
database. But why not just use the reports Amazon provides? Do you need to
something special with the data?

Vaughn Clement

www.ontargetsolutions.biz

On Wednesday, April 1, 2015, kee nethery <[hidden email]> wrote:

> I want to build a multi-user database client that uses Amazon AWS
> capabilities for the centralized database.
>
> I envision one S3 bucket for app updates. Have the app hit a text file to
> see if it is up to date and if not, download the latest version.
>
> I envision some kind of SQL-ish database where shared data is stored so
> that each client can access and write to it.
>
> Is anyone else out there doing this and if so, what experiences could you
> share with me?
>
> Thanks in advance.
>
> Kee Nethery
> _______________________________________________
> use-livecode mailing list
> [hidden email] <javascript:;>
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


--
Thank you

Vaughn Clement

On Target Solutions LLC (Support)
On Target Solutions LLC Website: http://www.ontargetsolutions.biz
Email: [hidden email]
Skype: vaughn.clement

FaceTime: [hidden email]
Ph. 928-254-9062
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode