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/splashstack combination, and putting a fake datagrid stub substack as part of the splash so that the builder would know to included the datagrid stuff.
If a list of such things could be put together and shown on first run, it might be a just the ticket. On Fri, Aug 15, 2014 at 11:46 AM, Peter M. Brigham <pmb...@gmail.com> wrote: > 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 > attention would have to be paid to not messing up the message path, I > guess, but it seems feasible on the face of it. (Of course, lots of things > seem feasible when you don't really know what you're talking about….) > > -- Peter > > Peter M. Brigham > pmb...@gmail.com > http://home.comcast.net/~pmbrig > > > On Aug 15, 2014, at 10: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 > standalone to test out the work they've been doing, and suddenly everything > that worked so well in the IDE stops working, with no readily discernible > cause. > > > > So they come into the forums or this list, and folks mention everything > from refactoring their work to use an anchor window (or "splash" screen) > pattern, or completely rewrite everything to use an external text file or > database or what have you. > > > > The LiveCode User Guide's section on building standalones includes a > bold purple callout box explaining this (p 299), but it's a testament to > the usability of LiveCode that apparently a great many people can use it > productively for many weeks without ever cracking the User Guide. > > > > Clearly something more is needed. What should that be? > > > > Putting a note in the Standalone Builder might help, but if they've > gotten that far it's too late, they probably have to start rewriting things. > > > > How can we help users anticipate IN ADVANCE that no OS will allow their > executable to write to itself, so they can write useful things from the > very start? > > > > -- > > Richard Gaskin > > Fourth World Systems > > Software Design and Development for the Desktop, Mobile, and the Web > > ____________________________________________________________________ > > ambassa...@fourthworld.com http://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 > > > _______________________________________________ > 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
