Maybe a better approach would be to have separate card layouts for the different OS'es?
Bob On Jun 26, 2012, at 12:38 PM, Peter Haworth wrote: > I finally tracked this down by using good old fashioned answer dialogs as > suggested by Ken. > > In addition to being the first build I had done under Lion, it was also the > first build I had done with 5.5 and it seems that the problem was related > to 5.5. > > At startup, I have a handler that goes through my stacks and sets fonts > according to platform. There were no changes in that handler between the > stack version I used to make the problematic build and the prior stack > version which built fine under 5.0. > > What I had omitted to to take into accoun was that the substacks > property can included some rev stacks in the standalone, for example "ask > dialog", "answer dialog", and most significantly in my case > "revDatagridLibrary". There are no doubt other stacks that can end up in a > standalone depending on which libraries it uses > > My debugging showed that the setting of fonts was causing the standalone to > abort silently when processing the revDatagridLibrary stack. This did not > happen when the application was built using 5.0, only when built with 5.5 > so some change in the datagrid library brought this issue to light.. > > I changed my code to exclude the rev stacks that are copied into the > standalone from the font setting handler and the standalone now runs fine. > > I still don't understand why setting the font of an object would cause a > silent abort, seems like there should be an error message of some sort. > > I am also questioning whether I really need to set fonts like this. It > feels like setting the font of the main stack would cause any other > substacks and controls to inherit the main stack's font, except for > controls that have a font explicitly defined. Is that correct? > > > Pete > lcSQL Software <http://www.lcsql.com> > > > > On Sun, Jun 24, 2012 at 11:04 PM, Ken Corey <k...@kencorey.com> wrote: > >> Does your code get a chance to run at all? If so, you can put alerts in >> to announce how far the app gets before it's crashing. >> >> on preOpenStack >> answer "preOpenStack" >> [...regular code...] >> end preOpenStack >> >> on openStack >> answer "openStack" >> [...regular...] >> end openStack >> >> and so on. If LiveCode is running at all before crashing, you get a >> chance to find the bug. >> >> I'm finding with my stacks is that the preOpenCard and openCard handlers >> get run much less in the IDE during development. I'd start by taking a >> hard look at those. >> >> Richard, I don't think it's the executable bit, as the problem seems to be >> on both platforms, and the computers both are *trying* to run the >> standalone. That wouldn't happen if the executable bit weren't set. >> >> -Ken >> >> >> On 25/06/2012 02:24, Peter Haworth wrote: >> >>> Update to this. I created the standalone on my Windows computer and >>> neither the Mac nor the versionswill run so looks like there's a problem >>> with my stack file. It runs OK in the IDE though. >>> >> >> ______________________________**_________________ >> 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<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
