Alain Farmer wrote:
> Thank you, Richard, for the URLs regarding JSON.
> Have you used any of them? Do you recommend one?
Unfortunately I'm useless to you there: the only service I've had to
talk to that uses anything like that is for a very trivial datum in
which a simple offset call does wha
Thank you, Richard, for the URLs regarding JSON.
Have you used any of them? Do you recommend one?
As for LC-library to make working with CouchDB more convenient, it is a project
of mine.
I should have this all worked-out in the coming weeks.
I will share it with y'all, once it's completed, polishe
Hi All
My first look at LC a year ago:
Was it just me or do you find that many of the reference documents and
media are not well written. As I have stated in the past, as a newbie I
found the media incomplete and misleading in many areas.
Today:
Since that time I have come to understand that Li
Thanks Richard. I tried that some time ago but it didn’t work with all apps. I
suppose you are saying it will work with Livecode? I will give that a try!
Bob S
On Aug 15, 2014, at 12:31 , Richard Gaskin wrote:
> Bob Sneidar wrote:
>
> > All that being said, it *would* be nice to have an emul
Alain Farmer wrote:
> I am also interested in JSON, because this is the native format
> of JavaScript, Couch, and MANY other tools. It is essential for
> inter-operability. Btw, Couch is a relatively-new no-SQL database,
> much faster than any SQL, designed for massive distributed systems,
> spec
Bob Sneidar wrote:
> All that being said, it *would* be nice to have an emulator that I
> can switch to so I can see how it will run on my Mac without having
> to switch to my Virtual Machine and run it in Livecode there. But
> that is because I am lazy. It’s not that much more trouble to bite
>
In reply to : Taking a broader view, for most apps it's not desirable to save
UI elements at all, populating the UI with data stored externally instead, so
when you deploy upgrades the new UI can display older data without having to
worry about the old UI. And for separate data storage there a
Okay, so let’s remember that a Dev Environment is an order of magnitude (or
more) more complex that simply running an application. It’s an application that
builds applications, for crying out loud, and people who take up software
development need to get used to the idea that they are going to *h
Alain Farmer wrote:
> Lack of documentation, tutorials, and ready-to-reuse stacks is
> crippling; especially for newbies, but also for seasoned veterans
> of xTalk (like myself and many oldies on this list).
It would be helpful if we could all take a really good look at what we
have now to see
Paul Hibbert wrote: "My biggest frustration at the time was the disjointed
documentation and
lack of structured tutorials, many people have also made the same
comments over the years. I feel the tutorials especially have improved
and the documentation is improving slowly. Thinking back to when
kee nethery wrote:
> I use the launcher/updater with the script/data stack model so my
> standalones can save changes into it’s stacks. Wonder if it would
> make sense to have a standard version of that launcher/updater so
> that newbies can just grab it and use it.
In a sense, that suggestion i
I like this idea a lot!
Roger
On Aug 15, 2014, at 10:46 AM, kee nethery wrote:
> I use the launcher/updater with the script/data stack model so my standalones
> can save changes into it’s stacks. Wonder if it would make sense to have a
> standard version of that launcher/updater so that newb
This would be awesome, Kee. I've been looking for something like that, myself.
(Do you have anything you would be willing to share off list?)
Not to bring up a sore subject, but something like this would be pretty easy to
share and distribute... and might even be found by new users more easily...
Late to this, but I like the Mark T thought idea. I still remember when
the datagrid first came out, one specific part of the documentation was a
big bold link that said something like.. "What things do I need to know to
avoid needless headaches.." It included things like building a
standalone/sp
Would it be possible for the standalone builder to automatically create an .exe
stack that opens invisibly and does only one thing: opens what the user has
presented as the mainstack? Then things would work exactly the same as in the
IDE and changes made to the mainstack would be saved. Some at
I use the launcher/updater with the script/data stack model so my standalones
can save changes into it’s stacks. Wonder if it would make sense to have a
standard version of that launcher/updater so that newbies can just grab it and
use it.
Kee
On Aug 15, 2014, at 7:13 AM, Richard Gaskin wrote
Mark Talluto wrote:
> I would think that this could be solved with a document titled
> something like: “Things you should know…” or “Getting Started”
> or “Read Me Before Starting” or something entirely different.
Along those lines, earlier this morning I took a look through the
various introdu
On Fri, Aug 15, 2014 at 9:20 AM, Richard Gaskin
wrote:
> Yet somehow even among young people, who've never used HC and in a world
> where they've never seen any application save to itself, find themselves
> with the expectation that this should be doable.
It's what people new to programming (ye
On Aug 15, 2014, at 7:13 AM, Richard Gaskin wrote:
> One of the most frequent frustrations new users have with LiveCode is the
> moment they realize the standalone they've built can't save changes to its
> stacks.
>
> Often this happens very late in the process, just after building the
> stan
Maybe having a saving data/reading data example stack included among the
default LC splash screen examples could be an additional learning avenue. The
demo stack could dynamically generate a data stack in the system's Documents
folder (for ease of writing/locating), as opposed to requiring the
Vaughn Clement wrote:
> Hi Richard
>
> Although I have not seen this occur in stacks I've created, I would
> like to better understand where you are going with this topic? Are
> you starting a new way to address specific issues with LiveCode, or
> suggesting changes to the IDE?
That's a good que
Hi Richard
This is a good opening topic that can solicit comments. I have passed
through the frustration about documentation already, and I find I live on
the How To email to find answers. The forums seem to take forever to get
answers. Considering that the How To offers a good reference platform,
>From my own point of view, I struggled trying to understand some of the basic
>principles of using LC (Revolution as it was then), until I finally picked
>apart some sample stacks such as the calculator etc., then a few things
>started to fall in to place.
After that I looked for stacks that h
How about going the other direction and fixing the behavior?
Technically, any standalone CAN edit itself, anyway, but there are all
sorts of things that might be able to be done with ancillary files to store
changes/updates. When the standalone is going to set something, it checks
the file (like
Hi Richard
Although I have not seen this occur in stacks I've created, I would like to
better understand where you are going with this topic? Are you starting a
new way to address specific issues with LiveCode, or suggesting changes to
the IDE?
Thank you
Vaughn Clement
Apps by Vaughn Clement (S
hmmm… it would be too much to ask that the test mode could simulate the windows
environment on a Mac and vis versa. Fairly impossible I suppose to emulate
Linux…
Bob S
On Aug 15, 2014, at 07:21 , Ludovic THEBAULT
mailto:ludovic.theba...@laposte.net>> wrote:
Le 15 août 2014 à 16:13, Richard
Yes, I like the idea of a "test" mode. I prefer that my experience in the
development environment match the final user experience as closely as possible.
I can imagine linking this test mode to what are now the View > Look and Feel >
Emulated... menu items. And of course it would be great to ha
Le 15 août 2014 à 16:13, Richard Gaskin a écrit :
> One of the most frequent frustrations new users have with LiveCode is the
> moment they realize the standalone they've built can't save changes to its
> stacks.
>
> Often this happens very late in the process, just after building the
> stan
One of the most frequent frustrations new users have with LiveCode is
the moment they realize the standalone they've built can't save changes
to its stacks.
Often this happens very late in the process, just after building the
standalone to test out the work they've been doing, and suddenly
ev
29 matches
Mail list logo