Re: Multi-platform development.

[Matt Maier]

I'm trying to put as much of the logic into script only stacks as possible
cuz I want my application to be open source contribution friendly. Livecode
actually makes that counterintuitive because it's so tempting to put little
handlers in each control.
On Jan 20, 2016 12:45, "Bob Sneidar"  wrote:

>
> On Jan 20, 2016, at 10:14 , Mark Waddingham > wrote:
>
> For example, many document-centric apps will have a 'Save' function. On
> Mac this is typically 'just' in the File menu. However, on Windows it is
> usual to have it both in the File menu *and* as a button on a document's
> toolbar. If the code for the 'save' action is not factored out you end up
> with duplicated code - so it is quite natural to move this code 'down' into
> core logic.
>
> Oh right yes I do that too. As soon as I need to access the same code from
> multiple locations, I will often do that, but sometimes I will just send a
> mouseUp (or call a handler) from the object itself. A lot has to do with
> whether or not the object script has relative references to itself of the
> card/stack it belongs to. Sometimes moving complex code requires a lot of
> refactoring, so rather than do that, I just send or dispatch to the handler
> in the object, rather than go through the nonsense of re-debugging
> everything all over again.
>
> Bob S
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: server vs not server

[Mike Kerner]

Roger,
But why do it in server instead of just having another instance of LC
running, sitting off in its own space?  Since you don't have a message box,
any output is going to require email, push, or writing to a file.  Is
Server just a beast for speed?  You can't possibly save enough memory from
avoiding the GUI to make it worth while.

Server managing several other server instances is sexy, but I'm trying to
gage when switching over is the thing to do.

On Wed, Jan 20, 2016 at 9:36 AM, Roger Eller 
wrote:

> Hey Mike,
>
> Most daemons I have built with LC will poll a folder at a set time
> interval, and act accordingly dependent upon what it finds in the folder.
> A polling interval set too short can make the server slower.  Setting it
> too long makes the users complain about waiting 30 seconds or a minute.
> Using LC Server for the same tasks makes it on-demand, and much more
> efficient.  The only con is that some tasks may require elevated
> privileges, and since it isn't being run by a normal user, this can be
> tricky.  I have some of both, but my goal is to port all my daemons to LC
> server scripts.
>
> ~Roger
>
> On Wed, Jan 20, 2016 at 8:55 AM, Mike Kerner 
> wrote:
>
> > I have a bunch of stacks that run, constantly, doing a variety of things.
> > Some are even run as daemons by other processes.  So, I suppose they
> could
> > run in server, but I'm still unclear as to why I would choose to do that.
> >
> > --
> > On the first day, God created the heavens and the Earth
> > On the second day, God created the oceans.
> > On the third day, God put the animals on hold for a few hours,
> >and did a little diving.
> > And God said, "This is good."
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

LC 8.0 dp13 crash when pasting script through clipboard into script editor

[Roland Huettmann]

If someone also experienced this, I will file a bug report.

I installed LC 8.0.0 dp 13 on a Windows machine, OS 8.1.

When trying to copy script or any text from some other application and
paste it from clipboard to be inserted into the opened script editor, LC
crashes each time. It crashes without me having to kill the process, but
repeatedly is crashing being not-responsive.

Roland
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Multi-platform development.

[Mark Waddingham]

On 2016-01-20 16:53, Bob Sneidar wrote:

On Jan 12, 2016, at 11:26 , Mark Waddingham
> wrote:


Simple things like not putting code in a mouseUp, but instead just get
it to call an action function in the core part of the application
(independent of UI) help immensely.


This makes me a little sad, because one of the great things about LC
in my opinion is the modularity of the code. Going to an object's
script and seeing exactly what the object does, as opposed to having a
single large (and unweildy I might add) script is very attractive to
me.


My comment there was perhaps a little 'glib' and perhaps not quite 
representative of what I was suggesting.


In general there is always a line (which sometimes can be very difficult 
to find!) between code which drives a UI, and code which drives the 
application logic. So a sensible way to write an application which has 
to have multiple distinct UIs is to find that line and make sure the UI 
calls actions which perform the application's actual function. (Think 
command-line application being driven by a frontend UI - something which 
MetaCard was used widely for in the UNIX world from its original 
inception).


For example, many document-centric apps will have a 'Save' function. On 
Mac this is typically 'just' in the File menu. However, on Windows it is 
usual to have it both in the File menu *and* as a button on a document's 
toolbar. If the code for the 'save' action is not factored out you end 
up with duplicated code - so it is quite natural to move this code 
'down' into core logic. If you do that for anything which can be taken 
out of a UI context you quickly end up with a architecture where the UI 
of your app is separated from the action thus making (in theory at 
least) adding variants of the UI easy.


Of course, good UIs are not easy to write - personally I generally find 
it much easier to define the core application model than I do to write 
the UI sitting on top of it. However, this is where LiveCode (and 
similar things) excel due to their visual and 'immediate' nature - you 
can iterate UIs rapidly, particularly if you don't have to worry about 
'breaking' the core application logic, something which splitting things 
up into UI + Logic helps with.


So, I perhaps should have been more specific - code that deals with the 
UI should probably be 'closest to use' for all the places it should be 
used, whereas code which deals with core application logic is probably 
best 'pushed down' into a core library or set of libraries.


Of course, in the end, it all does largely depend on the application, 
how well the programmer understands the problem he/she are trying to 
solve in the first instance and how much time you have to solve it!



I also understand the advantage of a centralized library of functions
and I am not argueing against that, but I like the LC (and originally
HC) model. In fact the computing world thought this was such a neat
concept that OOP was born.


Well, I think OOP predates HyperCard by a significant margin. Simula was 
perhaps the first 'object oriented' language (although it did 
inheritence in reverse to current languages) - a superset of Algol, it 
appeared in 1965.


SmallTalk, one of the first 'purely object oriented' languages appeared 
in 1972.


HyperCard didn't appear until 1986.


So it seems that one objective might favor one approach, and another
objective a different one. This is exactly why designing for multiple
OSes, while certain techniques can get you a long way there, might
eventually be unattainable.


It would be possible to do a reasonably good job of abstracting some of 
the UI patterns people use today so that they specialize appropriately. 
For example, on an iPad you tend to use 'Split View' controllers which 
are similar to having a content view with a 'menu' callout button on 
iPhones. Conceptually (if you ignore the actual layout / rendering) 
these are almost the same - it is just the rendering and interaction 
which are different.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Http Header question

[Peter Haworth]

If you were doing this from an html form, the file in question would be
uploaded to the server's temp directory and the php script can access it
from there using the "tmp_name" key.  I think the $_FILES array is created
as a result of the  enctype setting.  Not sure how you would replace all
that via LC though.

On Tue, Jan 19, 2016 at 5:38 PM William Prothero 
wrote:

> Folks:
> Dave got me started, but I’m still confused, unfortunately. I am having
> trouble seeing how the variables and data are passed from the POST command
> to the php script. What I’m trying to reproduce is:
>
> if(isset($_FILES['image'])){
>   $errors= array();
>   $file_name = $_FILES['image']['name'];
>   $file_size =$_FILES['image']['size'];
>   $file_tmp =$_FILES['image']['tmp_name'];
>   $file_type=$_FILES['image']['type'];
>   $file_ext=strtolower(end(explode('.',$_FILES['image']['name'])));
>
>   $expensions= array("jpeg","jpg","png");
>
>   if(in_array($file_ext,$expensions)=== false){
>  $errors[]="extension not allowed, please choose a JPEG or PNG
> file.";
>   }
>
>   if($file_size > 2097152){
>  $errors[]='File size must be excately 2 MB';
>   }
>
>   if(empty($errors)==true){
>  move_uploaded_file($file_tmp,"images/".$file_name);
>  echo "Success";
>   }else{
>  print_r($errors);
>   }
>}
> ?>
> 
>
>
>   
>  
>  
>   
>
>
> 
>
> I’m familiar with a php script getting variables from lines like:
> $tName =  $_POST["name"];
>
> But, in the above example, how do the file variables get sent? I suppose,
> in the headers? But, I don’t seem to be successful. The file doesn’t seem
> to be passing to the php. I’m thinking that the image data gets embedded in
> the header, but I don’t see the file on my server and nothing seems to be
> getting into the $_FILES variable.
>
> Help?? thanks.
> Bill
>
>
> > On Jan 19, 2016, at 3:55 PM, William Prothero 
> wrote:
> >
> > Dave:
> > That’s it! I knew there was something like that, but couldn’t remember
> it.
> > Thanks!
> > Bill
> >
> >> On Jan 19, 2016, at 3:51 PM, Dave Cragg 
> wrote:
> >>
> >> Bill,
> >>
> >> Take a look at libUrlMultipartForm and libUrlMultipartFormAddPart in
> the dictionary. There are examples there that might help you.
> >>
> >> Cheers
> >> Dave Cragg
> >>
> >>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8.0 dp13 crash when pasting script through clipboard into script editor

[Richard Gaskin]

Roland Huettmann wrote:

If someone also experienced this, I will file a bug report.

I installed LC 8.0.0 dp 13 on a Windows machine, OS 8.1.

When trying to copy script or any text from some other application and
paste it from clipboard to be inserted into the opened script editor, LC
crashes each time. It crashes without me having to kill the process, but
repeatedly is crashing being not-responsive.


I haven't experienced that myself, but please do submit the report 
anyway if it's repeatable for you.


Deep revisions have been made to clipboard handling in v8 to support 
some exciting new features, but the chances of regression go along with 
that so your report will be very valuable.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Multi-platform development

[Richard Gaskin]

Bob Sneidar wrote:

> On Jan 12, 2016, at 09:02 , Richard Gaskin wrote:
>
>> While it's true that Ubuntu and more recently Microsoft have begun
>> exploring convergence strategies for a single adaptable, scalable
>> set of UI conventions across all device types, the reality is that
>> to date neither has been enormously successful (though the night is
>> young, and the research and APIs still in early days).
>
> Adobe tried this years ago, with a feature that could take a regular
> magazine layout (for example) and format it to display nicely in a
> web browser or some other format. The idea was to design once then
> deploy in multiple forms. It was a good idea. But it always required
> some tweaking. Sometimes it required a LOT of tweaking. And sometimes
> it didn't work well at all. The nature of the problem is such that
> the solution can never really be perfect.

While it's true that mixing web and native app design is very rarely a 
good idea (they're very different platforms serving very different 
needs), mixing native app design across device types seems, at least to 
me, a more exciting and viable prospect.


When I see any OS without design issues of its own I'll start to get 
worried about multi-platform design challenges. :)


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Multi-platform development.

[Bob Sneidar]

On Jan 12, 2016, at 11:26 , Mark Waddingham 
> wrote:

Simple things like not putting code in a mouseUp, but instead just get it to 
call an action function in the core part of the application (independent of UI) 
help immensely.

This makes me a little sad, because one of the great things about LC in my 
opinion is the modularity of the code. Going to an object's script and seeing 
exactly what the object does, as opposed to having a single large (and unweildy 
I might add) script is very attractive to me.

I also understand the advantage of a centralized library of functions and I am 
not argueing against that, but I like the LC (and originally HC) model. In fact 
the computing world thought this was such a neat concept that OOP was born.

So it seems that one objective might favor one approach, and another objective 
a different one. This is exactly why designing for multiple OSes, while certain 
techniques can get you a long way there, might eventually be unattainable.

Bob S

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Getting the clicktext from a browser control

[Bob Sneidar]

Well you can see how that would make the LC browser object horribly insecure. 
User clicks a link and you take him somewhere completely different? Or 
somewhere else in another browser object?? K! I don't think you can get 
that kind of control, and I would be very afraid if you could. 

Bob S


> On Jan 13, 2016, at 10:51 , J. Landman Gay  wrote:
> 
> On 1/13/2016 7:39 AM, Colin Holgate wrote:
>> The times that BrowserBeforeNavigate doesn’t get sent, is a
>> BrowserBeforeNavigateFrame sent instead?
> 
> There are no frames, so no. The browserBeforeNavigate only gets sent when the 
> URL changes, and the links in the page do not always change URLs, (they are 
> basically reference IDs, mainly footnotes) so that's why.
> 
> If the footnote is contained in the existing browser content then the link 
> navigates but I can't find out about it until after the navigation completes. 
> If the link points to another set of content that isn't loaded yet, nothing 
> happens and I still don't find out about it until browserNavigateComplete is 
> sent. I want to know what link was clicked so I can handle it regardless of 
> the intended link destination. I don't see any way to do that.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Multi-platform development

[Bob Sneidar]

Adobe tried this years ago, with a feature that could take a regular magazine 
layout (for example) and format it to display nicely in a web browser or some 
other format. The idea was to design once then deploy in multiple forms. It was 
a good idea. But it always required some tweaking. Sometimes it required a LOT 
of tweaking. And sometimes it didn't work well at all. The nature of the 
problem is such that the solution can never really be perfect.

Bob S


On Jan 12, 2016, at 09:02 , Richard Gaskin 
> wrote:

While it's true that Ubuntu and more recently Microsoft have begun exploring 
convergence strategies for a single adaptable, scalable set of UI conventions 
across all device types, the reality is that to date neither has been 
enormously successful (though the night is young, and the research and APIs 
still in early days).

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: server vs not server

[Roger Eller]

Mike,

I like not having to leave a session logged in just to run a daemon, or a
LC instance.  If there is a power failure, my server reboots, and scripts
are available.  Otherwise, after a power failure, I have to log in and
start the daemons.  It is speedy, but for my applications (in-house), what
I found most advantageous is for network database access.  Previously, I
had to ensure that all my clients had the proper drivers, etc. but in this
configuration, only the server has to have access.  My LC client apps just
send http requests and sql data is returned, and no DSN or driver or even a
database command is ever sent from the client.  You could also communicate
with sockets, if that is your thing.

~Roger


On Wed, Jan 20, 2016 at 9:56 AM, Mike Kerner 
wrote:

> Roger,
> But why do it in server instead of just having another instance of LC
> running, sitting off in its own space?  Since you don't have a message box,
> any output is going to require email, push, or writing to a file.  Is
> Server just a beast for speed?  You can't possibly save enough memory from
> avoiding the GUI to make it worth while.
>
> Server managing several other server instances is sexy, but I'm trying to
> gage when switching over is the thing to do.
>
> On Wed, Jan 20, 2016 at 9:36 AM, Roger Eller 
> wrote:
>
> > Hey Mike,
> >
> > Most daemons I have built with LC will poll a folder at a set time
> > interval, and act accordingly dependent upon what it finds in the folder.
> > A polling interval set too short can make the server slower.  Setting it
> > too long makes the users complain about waiting 30 seconds or a minute.
> > Using LC Server for the same tasks makes it on-demand, and much more
> > efficient.  The only con is that some tasks may require elevated
> > privileges, and since it isn't being run by a normal user, this can be
> > tricky.  I have some of both, but my goal is to port all my daemons to LC
> > server scripts.
> >
> > ~Roger
> >
> > On Wed, Jan 20, 2016 at 8:55 AM, Mike Kerner 
> > wrote:
> >
> > > I have a bunch of stacks that run, constantly, doing a variety of
> things.
> > > Some are even run as daemons by other processes.  So, I suppose they
> > could
> > > run in server, but I'm still unclear as to why I would choose to do
> that.
> > >
> > > --
> > > On the first day, God created the heavens and the Earth
> > > On the second day, God created the oceans.
> > > On the third day, God put the animals on hold for a few hours,
> > >and did a little diving.
> > > And God said, "This is good."
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: server vs not server

[Mike Kerner]

I have a pile of OS's running, here, for all sorts of reasons.  Yes, I
could, and have, deploy (and develop) on one of several linux boxes that I
have running you-name-it with whatever desktop environment is on that box.
In some cases, there are issues where some other piece of gear is OS
limited to Windoze, for example.

On Wed, Jan 20, 2016 at 12:53 PM, Richard Gaskin  wrote:

> Mike Kerner wrote:
> > I have a bunch of stacks that run, constantly, doing a variety of
> > things.
> > Some are even run as daemons by other processes.  So, I suppose they
> > could run in server, but I'm still unclear as to why I would choose
> > to do that.
>
> LC Server is a great tool for mixing LiveCode scripts with HTML for
> convenient delivery of web pages.
>
> But beyond that, the differences in terms of benefits to the developer
> between using the Server edition and running a standalone facelessly with
> the -ui flag are minimal, and often favor the standalone.
>
> In fact I've never deployed a production system with LC Server, even on
> web sites like LiveCodeJournal.com where the entire CMS all the way down to
> the data store is entirely written in LC.  Calling the merge function
> explicitly rather then having an extended version called implicitly is
> handy but ultimately less valuable for me than having an engine that works
> identically on both desktop and server.
>
> Most of my work these days is delivering client-server workgroup
> solutions, and LC provides a complete solution on both ends.  But by using
> a "desktop" standalone as the CGI instead of LC Server, it was a trivial
> matter to integrate the server functionality directly into my client
> development workflow, all running within the LC IDE.
>
> Of course LC Server also provides many other conveniences for web work,
> like parsing incoming POST data, but since I've been using LC as a CGI
> since it was called "MetaCard" I already had libraries for those things
> more than a decade ago.
>
> So for web development LC Server can be very convenient, but with a little
> extra work one can use a "desktop" standalone equally well, with the extra
> benefit of being able to develop and test directly in the IDE.
>
> But outside of web development, if all you need is a LiveCode engine to
> run some scripts and you don't need a GUI, just call a standalone with -ui
> so the engine knows not to bother initializing GUI elements (launches
> super-fast and takes less RAM and fewer CPU cycles as it runs):
>
>   /home//LCdaemonFolder/lc-daemon -ui
>
> Whether I'm building a socket server on a VPS or just need some auxiliary
> processing on a separate machine so I don't tie up my workstation,
> standalones are a wonderful option that gives us nearly complete fidelity
> between development and runtime.
>
> I generally make the standalone very slim, in which the only code is a
> startup handler that looks for a stack file in the same folder; if it finds
> the stack it runs "start using..." to bring it into play, and if not it
> reports an error and quits.
>
> This lets me update the app by just replacing the very slender stack file,
> never touching the standalone at all until there's an engine upgrade I need
> for new things.
>
> Extra bonus points: if you share your public SSH key with the target
> machine running your LC standalone, you can completely automate updating
> your stacks and other files very conveniently using rsync, regardless
> whether the target machine is a spare computer on your local network or a
> VPS hosted anywhere in the world.  Write in the UDE, click a button in a
> plugin stack, and - poof! - everything on your remote system is updated
> with all the smart efficiency rsync delivers.
>
> Instructions for this are all over the Web; I particularly like the
> simplicity of this one:
> <
> https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2
> >
>
>
> Tip about file polling:  while we're (often rightly) conditioned to think
> of file I/O as a bottleneck, checking for the existence of a file is not
> very costly at all, not nearly as much as opening and reading a file.  Even
> on Windows it takes relatively few clock cycles, and on any Unix-like
> system like OS X or Linux the ultra-smart file caching mechanism makes it
> even faster - much faster, so that the overhead of polling once every few
> seconds or even once a second, is barely measurable.
>
> If speed is critical you can even take that one step further if you're
> using Linux* by using the /run/shm/ directory for delivering files that
> need to be polled for.  The /run folder is a sort of RAM disk automatically
> created by the OS, so while it won't give you persistence between boots
> it'll make file I/O even breezier for those cases where it's a good fit,
> such as delivering instructions to an LC daemon without the complexity or
> security concerns of direct socket comms.
>
>
> * For a faceless system why not use Linux?  It runs on 

Re: Multi-platform development.

[Bob Sneidar]

On Jan 20, 2016, at 10:14 , Mark Waddingham 
> wrote:

For example, many document-centric apps will have a 'Save' function. On Mac 
this is typically 'just' in the File menu. However, on Windows it is usual to 
have it both in the File menu *and* as a button on a document's toolbar. If the 
code for the 'save' action is not factored out you end up with duplicated code 
- so it is quite natural to move this code 'down' into core logic.

Oh right yes I do that too. As soon as I need to access the same code from 
multiple locations, I will often do that, but sometimes I will just send a 
mouseUp (or call a handler) from the object itself. A lot has to do with 
whether or not the object script has relative references to itself of the 
card/stack it belongs to. Sometimes moving complex code requires a lot of 
refactoring, so rather than do that, I just send or dispatch to the handler in 
the object, rather than go through the nonsense of re-debugging everything all 
over again.

Bob S

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Http Header question

[William Prothero]

Peter:
Thanks. Another option is to just upload the file using ftp, then attach it to 
the email once it’s on the server. It would be more trips to the server, but 
might give me more control.

I’m not yet giving up and have to investigate the php.ini settings to see if 
I’ve missed something.
Thanks for the input.
Bill

> On Jan 20, 2016, at 9:50 AM, Peter Haworth  wrote:
> 
> If you were doing this from an html form, the file in question would be
> uploaded to the server's temp directory and the php script can access it
> from there using the "tmp_name" key.  I think the $_FILES array is created
> as a result of the  enctype setting.  Not sure how you would replace all
> that via LC though.
> 
> On Tue, Jan 19, 2016 at 5:38 PM William Prothero 
> wrote:
> 
>> Folks:
>> Dave got me started, but I’m still confused, unfortunately. I am having
>> trouble seeing how the variables and data are passed from the POST command
>> to the php script. What I’m trying to reproduce is:
>> 
>> >   if(isset($_FILES['image'])){
>>  $errors= array();
>>  $file_name = $_FILES['image']['name'];
>>  $file_size =$_FILES['image']['size'];
>>  $file_tmp =$_FILES['image']['tmp_name'];
>>  $file_type=$_FILES['image']['type'];
>>  $file_ext=strtolower(end(explode('.',$_FILES['image']['name'])));
>> 
>>  $expensions= array("jpeg","jpg","png");
>> 
>>  if(in_array($file_ext,$expensions)=== false){
>> $errors[]="extension not allowed, please choose a JPEG or PNG
>> file.";
>>  }
>> 
>>  if($file_size > 2097152){
>> $errors[]='File size must be excately 2 MB';
>>  }
>> 
>>  if(empty($errors)==true){
>> move_uploaded_file($file_tmp,"images/".$file_name);
>> echo "Success";
>>  }else{
>> print_r($errors);
>>  }
>>   }
>> ?>
>> 
>>   
>> 
>>  
>> 
>> 
>>  
>> 
>>   
>> 
>> 
>> I’m familiar with a php script getting variables from lines like:
>> $tName =  $_POST["name"];
>> 
>> But, in the above example, how do the file variables get sent? I suppose,
>> in the headers? But, I don’t seem to be successful. The file doesn’t seem
>> to be passing to the php. I’m thinking that the image data gets embedded in
>> the header, but I don’t see the file on my server and nothing seems to be
>> getting into the $_FILES variable.
>> 
>> Help?? thanks.
>> Bill
>> 
>> 
>>> On Jan 19, 2016, at 3:55 PM, William Prothero 
>> wrote:
>>> 
>>> Dave:
>>> That’s it! I knew there was something like that, but couldn’t remember
>> it.
>>> Thanks!
>>> Bill
>>> 
 On Jan 19, 2016, at 3:51 PM, Dave Cragg 
>> wrote:
 
 Bill,
 
 Take a look at libUrlMultipartForm and libUrlMultipartFormAddPart in
>> the dictionary. There are examples there that might help you.
 
 Cheers
 Dave Cragg
 
 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [OT] 64-bit computer board runs Android, Ubuntu, others

[Roger Eller]

$19 + $7 shipping
Pledge $19 or more

The PINE A64+

(April 2016 Delivery)

You will get the PINE64+ unit, which comes with the 1.2Ghz board and 1GB
SDRAM.

The updated unit has a gigabit Ethernet port, 3.5MM Audio/Mic jack, 4K
HDMI, and 2 USB ports. PINE A64+ includes touchpanel, camera, and LCD Port
accessibility.

(No wifi/bluetooth - we will offer a list of compatible wifi/bluetooth
modules you can use to connect later)

Shipping starts in April 2016. We can fulfill up to 10,000 units a month.
Estimated delivery:Apr 2016
Ships to:Anywhere in the world



On Wed, Jan 20, 2016 at 3:35 PM, Roger Eller 
wrote:

>
> https://www.kickstarter.com/projects/pine64/pine-a64-first-15-64-bit-single-board-super-comput
>
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Multi-platform development.

[Bob Sneidar]

Well this is what happens in Apple Mail when I click AFTER the quoted text. It 
bundles my response into what the quoted post was. I will try that Appel Mail 
post fix someone linked. 

Bob S


> On Jan 20, 2016, at 12:44 , Bob Sneidar  wrote:
> 
> 
> On Jan 20, 2016, at 10:14 , Mark Waddingham 
> > wrote:
> 
> For example, many document-centric apps will have a 'Save' function. On Mac 
> this is typically 'just' in the File menu. However, on Windows it is usual to 
> have it both in the File menu *and* as a button on a document's toolbar. If 
> the code for the 'save' action is not factored out you end up with duplicated 
> code - so it is quite natural to move this code 'down' into core logic.
> 
> Oh right yes I do that too. As soon as I need to access the same code from 
> multiple locations, I will often do that, but sometimes I will just send a 
> mouseUp (or call a handler) from the object itself. A lot has to do with 
> whether or not the object script has relative references to itself of the 
> card/stack it belongs to. Sometimes moving complex code requires a lot of 
> refactoring, so rather than do that, I just send or dispatch to the handler 
> in the object, rather than go through the nonsense of re-debugging everything 
> all over again.
> 
> Bob S
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OT - livecoders.slack.com site established

[Mark Wieder]

rotfl

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: server vs not server

[Richard Gaskin]

Mike Kerner wrote:
> I have a bunch of stacks that run, constantly, doing a variety of
> things.
> Some are even run as daemons by other processes.  So, I suppose they
> could run in server, but I'm still unclear as to why I would choose
> to do that.

LC Server is a great tool for mixing LiveCode scripts with HTML for 
convenient delivery of web pages.


But beyond that, the differences in terms of benefits to the developer 
between using the Server edition and running a standalone facelessly 
with the -ui flag are minimal, and often favor the standalone.


In fact I've never deployed a production system with LC Server, even on 
web sites like LiveCodeJournal.com where the entire CMS all the way down 
to the data store is entirely written in LC.  Calling the merge function 
explicitly rather then having an extended version called implicitly is 
handy but ultimately less valuable for me than having an engine that 
works identically on both desktop and server.


Most of my work these days is delivering client-server workgroup 
solutions, and LC provides a complete solution on both ends.  But by 
using a "desktop" standalone as the CGI instead of LC Server, it was a 
trivial matter to integrate the server functionality directly into my 
client development workflow, all running within the LC IDE.


Of course LC Server also provides many other conveniences for web work, 
like parsing incoming POST data, but since I've been using LC as a CGI 
since it was called "MetaCard" I already had libraries for those things 
more than a decade ago.


So for web development LC Server can be very convenient, but with a 
little extra work one can use a "desktop" standalone equally well, with 
the extra benefit of being able to develop and test directly in the IDE.


But outside of web development, if all you need is a LiveCode engine to 
run some scripts and you don't need a GUI, just call a standalone with 
-ui so the engine knows not to bother initializing GUI elements 
(launches super-fast and takes less RAM and fewer CPU cycles as it runs):


  /home//LCdaemonFolder/lc-daemon -ui

Whether I'm building a socket server on a VPS or just need some 
auxiliary processing on a separate machine so I don't tie up my 
workstation, standalones are a wonderful option that gives us nearly 
complete fidelity between development and runtime.


I generally make the standalone very slim, in which the only code is a 
startup handler that looks for a stack file in the same folder; if it 
finds the stack it runs "start using..." to bring it into play, and if 
not it reports an error and quits.


This lets me update the app by just replacing the very slender stack 
file, never touching the standalone at all until there's an engine 
upgrade I need for new things.


Extra bonus points: if you share your public SSH key with the target 
machine running your LC standalone, you can completely automate updating 
your stacks and other files very conveniently using rsync, regardless 
whether the target machine is a spare computer on your local network or 
a VPS hosted anywhere in the world.  Write in the UDE, click a button in 
a plugin stack, and - poof! - everything on your remote system is 
updated with all the smart efficiency rsync delivers.


Instructions for this are all over the Web; I particularly like the 
simplicity of this one:




Tip about file polling:  while we're (often rightly) conditioned to 
think of file I/O as a bottleneck, checking for the existence of a file 
is not very costly at all, not nearly as much as opening and reading a 
file.  Even on Windows it takes relatively few clock cycles, and on any 
Unix-like system like OS X or Linux the ultra-smart file caching 
mechanism makes it even faster - much faster, so that the overhead of 
polling once every few seconds or even once a second, is barely measurable.


If speed is critical you can even take that one step further if you're 
using Linux* by using the /run/shm/ directory for delivering files that 
need to be polled for.  The /run folder is a sort of RAM disk 
automatically created by the OS, so while it won't give you persistence 
between boots it'll make file I/O even breezier for those cases where 
it's a good fit, such as delivering instructions to an LC daemon without 
the complexity or security concerns of direct socket comms.



* For a faceless system why not use Linux?  It runs on nearly any 
hardware made in the last 20 years, is free in both senses of the word, 
and the biggest benefit of OS X is its UI which you'd never see anyway. 
 When any machine in my office outlives the vendor's OS support, it 
gets wiped with a Linux install where it gets a new and well supported 
life, and all the bash commands I'd used on my Mac continue to work (but 
in many cases with newer and less vulnerable components -- see the many 
web articles about why Apple ships with outdated and vulnerable 

OT - livecoders.slack.com site established

[developer]

For those interested in a real-time dialog for livecode, we have established a 
https://livecoders.slack.com/  team site.

The self-registration url is https://livecoders.slack.com/signup 


Also anyone signing up with the livercoder.org  email 
address will be automatically invited to the team.

Thanks!

develo...@inmytribe.com 


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Mac standalones generated on Linux and Windows

[Paul Dupuis]

On 1/20/2016 2:43 AM, Richmond wrote:
> This is an old chestnut:
>
> http://use-livecode.runrev.narkive.com/XpqiPfKN/creating-mac-standalone-on-windows-studio
>
>
> http://forums.livecode.com/viewtopic.php?f=8=26320=136924#p136924
>
> I wonder if there is a way to solve this, as having to have access to
> a Macintosh computer
> to set the executable bit inside bundles is a "right bu**er".

This is way out of date (from 6 years ago). You have been able to build
OS X standalones under Windows without setting any execution bits or
stuff like that for a number of releases. I do nearly all my development
under Windows. I just ZIP up the OSX build and move it to my OSX system
unzip and it runs just fine.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: server vs not server

[Roger Eller]

Hey Mike,

Most daemons I have built with LC will poll a folder at a set time
interval, and act accordingly dependent upon what it finds in the folder.
A polling interval set too short can make the server slower.  Setting it
too long makes the users complain about waiting 30 seconds or a minute.
Using LC Server for the same tasks makes it on-demand, and much more
efficient.  The only con is that some tasks may require elevated
privileges, and since it isn't being run by a normal user, this can be
tricky.  I have some of both, but my goal is to port all my daemons to LC
server scripts.

~Roger

On Wed, Jan 20, 2016 at 8:55 AM, Mike Kerner 
wrote:

> I have a bunch of stacks that run, constantly, doing a variety of things.
> Some are even run as daemons by other processes.  So, I suppose they could
> run in server, but I'm still unclear as to why I would choose to do that.
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

server vs not server

[Mike Kerner]

I have a bunch of stacks that run, constantly, doing a variety of things.
Some are even run as daemons by other processes.  So, I suppose they could
run in server, but I'm still unclear as to why I would choose to do that.

-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode