Le 15 août 2014 à 16:13, Richard Gaskin ambassa...@fourthworld.com 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
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 have
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
ludovic.theba...@laposte.netmailto:ludovic.theba...@laposte.net wrote:
Le 15
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
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
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 had
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
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
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
On Aug 15, 2014, at 7:13 AM, Richard Gaskin ambassa...@fourthworld.com 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
On Fri, Aug 15, 2014 at 9:20 AM, Richard Gaskin ambassa...@fourthworld.com
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
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
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
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
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
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
I like this idea a lot!
Roger
On Aug 15, 2014, at 10:46 AM, kee nethery k...@kagi.com 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
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 is
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
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 if
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
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
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
the
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,
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 ambassa...@fourthworld.com wrote:
Bob Sneidar wrote:
All that being said, it *would*
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
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,
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 what
28 matches
Mail list logo