Re: App Dead on iOS 12
> On 21 Sep 2018, at 11:48 am, Terry Judd via use-livecode wrote: > > Panos did some sleuthing of my console output and it appears that my iOS 12 crashes (which occurred with even the most very basic of stacks/apps) are related to the fact that I use an iOS enterprise developer license to sign/distribute my apps - so not a LC issue as such. Will just have to wait for a fix from Apple I guess. Did you try your new builds on older versions of iOS to see if it is just an iOS 12 issue? Also did you try with a new profile? Cheers Monte ___ Hi Monte - I was able to get an app to run if I used the older of my two Macbooks, which is running OSX 10.10.5 and Xcode 7.2.1 to build it. No go with OSX 10.13.5 and Xcode 9.4 on my newer Macbook though. Haven't tried a new profile yet, although the current one was generated only 3 weeks ago. Regards, Terry... ___ 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: App Dead on iOS 12
> On 21 Sep 2018, at 11:48 am, Terry Judd via use-livecode > wrote: > > Panos did some sleuthing of my console output and it appears that my iOS 12 > crashes (which occurred with even the most very basic of stacks/apps) are > related to the fact that I use an iOS enterprise developer license to > sign/distribute my apps - so not a LC issue as such. Will just have to wait > for a fix from Apple I guess. Did you try your new builds on older versions of iOS to see if it is just an iOS 12 issue? Also did you try with a new profile? Cheers Monte ___ 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: App Dead on iOS 12
Panos did some sleuthing of my console output and it appears that my iOS 12 crashes (which occurred with even the most very basic of stacks/apps) are related to the fact that I use an iOS enterprise developer license to sign/distribute my apps - so not a LC issue as such. Will just have to wait for a fix from Apple I guess. Terry... Monte: > We have not been able to replicate the crash so it’s pretty > important that we get a report with a recipe ASAP. It's been a day or two. Has anyone reported/recipe'd this yet? If not I will. I suspect that a test stack needs more than one card to trigger the bug. Best wishes, Curry Kenworthy Custom Software Development LiveCode Training and Consulting http://livecodeconsulting.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: App Dead on iOS 12
> On 21 Sep 2018, at 11:20 am, Curry Kenworthy via use-livecode > wrote: > > > We have not been able to replicate the crash so it’s pretty > > important that we get a report with a recipe ASAP. > > It's been a day or two. Has anyone reported/recipe'd this yet? If not I will. > > I suspect that a test stack needs more than one card to trigger the bug. I’m not aware of a report being created yet. I could not replicate a crash and neither could Panos. We have had conflicting posts here with one user reporting behavior exactly like that fixed in RC 2, one user reporting crashes which I’m fairly sure Panos nailed down to a signing issue and other users reporting no crashes. So for the moment we are awaiting a report and recipe before continuing. So if you have a recipe that crashes 9.0.1 I would really like to have it! Cheers Monte ___ 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: App Dead on iOS 12
Monte: > We have not been able to replicate the crash so it’s pretty > important that we get a report with a recipe ASAP. It's been a day or two. Has anyone reported/recipe'd this yet? If not I will. I suspect that a test stack needs more than one card to trigger the bug. Best wishes, Curry Kenworthy Custom Software Development LiveCode Training and Consulting http://livecodeconsulting.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: Standalone build workaround
> On 20 Sep 2018, at 2:51 pm, Brian Milby via use-livecode > wrote: > > What about a front script for the build process that would intercept and > discard these messages? Could be inserted just before each action that used > to be protected by lock messages (close/open stack). I think if that solution could work then lock messages could work. The issue is some components actually need those open messages to function correctly. We are working on a complete replacement to the standalone builder scripts which will resolve this kind of issue but it will still be a some time before they can become part of the IDE. I’ve proposed a stop gap solution internally which I think would work well but will probably need to wait until Ali is back next week before we can throw it around. The idea is to not move the entire standalone build to a separate process (we will likely do that when we move to our complete replacement) but to just move the bits that modify the stackfiles (copy resources, set passwords etc). So we would have a command line app that took the path to the stackfiles on disk and all the settings, modified the stackfiles and saved them somewhere else. Then the IDE can continue on and can do the whole process without closing the stack at all. Cheers Monte ___ 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: When is suspendStack sent?
I just set up a couple stacks and it worked every time. Then I switched to another application and then the messages stopped. I will need to go back and see if I can reduce to a recipe. The dictionary says the message is sent to the card, so the stack should see it. Thanks, Brian On Sep 20, 2018, 4:35 PM -0500, dunbarxx via use-livecode , wrote: > Hmmm. > > Not sure of your setup, of course, but if I try an experiment, it always > works. Can you check the topStack each time you return to the, er, topStack? > You may indeed need to place that handler in a backScript or stack in use in > order to do so. > > Craig > > > > -- > Sent from: > http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html > > ___ > 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: When is suspendStack sent?
Hmmm. Not sure of your setup, of course, but if I try an experiment, it always works. Can you check the topStack each time you return to the, er, topStack? You may indeed need to place that handler in a backScript or stack in use in order to do so. Craig -- Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html ___ 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: When is suspendStack sent?
Yes it's in the stack script. It works the first time, and subsequent times it does not fire, even when I click back on the stack and away from it again. I think the stack I clicked on to go away from it is somehow getting the suspendStack message instead of the stack that is *actually* suspending. I'll have to test later. Bob S > On Sep 20, 2018, at 10:40 , dunbarxx via use-livecode > wrote: > > Bob. > > Is the suspendStack handler in the stack script of some stack? If so, it > will only fire when leaving that stack. > > You can always place the handler in a backScript, or something similar, so > that all stacks will have to listen to it. > > Craig ___ 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: Standalone build workaround
Maybe it's a little of both. I was helping out over screen sharing and only saw the openstack handler. The app uses a splash-screen model and we did get the conflict Bob described, where the stack the app opens threw a large number of repeated warnings about same-named stack conflicts. It took several dismissals to get rid of them. I don't know what handlers are in the separate mainstack but he said he fixed "all of them" that had open* and close* handlers. This was before we had a check to see if the revStandaloneProgress stack existed. Also during builds, a blank script error dialog appeared. It was unresponsive and empty so we don't know what it was trying to report. A stream of other error messages popped in and out of existence so fast we couldn't read them, so they weren't modal but their content is unknown. All this happened in LC 9 so I had him move back to LC 8. I told him to remove the content stack from memory and from inclusions and try building only the splash app, and that worked, so the problem points to the content stack. When he added it back into the Stacks pane in Standalone Settings the "can't find stack" error happened because the incorrect workaround handler was still in place. I've sent him the updated handler Panos posted and haven't heard back yet, but that should fix it. The release notes need updating so we have a record of the correct workaround. Like I said, it isn't the adaptation we need to do that bothers me as much as the idea that a lot of people won't know what's happening and will blame LC. That's what this person did. He had a bit of a rant about how LC didn't test enough and are producing shoddy software. I spent some time explaining what the real issue was and he then understood. But I'm concerned about other customers out there. On 9/20/18 6:40 AM, Ali Lloyd via use-livecode wrote: Just out of interest, what sorts of things are causing problems in openStack while building a standalone that do not happen when opening stacks for the first time in the IDE? To put it another way, is it simply the re-running of openStack that is causing problems, or is something going wrong? Something like a ‘cascade of errors’ sounds like the latter. -- 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
Re: When is suspendStack sent?
Bob. Is the suspendStack handler in the stack script of some stack? If so, it will only fire when leaving that stack. You can always place the handler in a backScript, or something similar, so that all stacks will have to listen to it. Craig -- Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html ___ 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: When is suspendStack sent?
I'm still curious why suspendStack is not getting sent to what appears for all intents and purposes to be the topStack (I even click the titlebar to make sure), but I found a workaround which is a bit more elegant. If I have a substack open, say for editing the details of a site record, and I am in editing mode, I check for that back on the main stack (which displays summary information for all the primary modules) and I prevent a new datagrid selection on the main form if so. Not sure if this helps anyone, but the second parameter in SelectionChanged (the old selection) really comes in handy here because I need to re-select the old selection. It's probably an edge case for me because I sync main stack selections with substack selections and vis versa, so the user doesn't think he's viewing or editing one record when he thinks he's editing another. Changing records in the middle of an edit therefore can corrupt data, overwriting one record with the contents of another while saving. Bob S > On Sep 20, 2018, at 09:02 , Bob Sneidar via use-livecode > wrote: > > Hi all. > > I was using modal as a means to prevent a user from switching to another open > window while in certain modes (editing a "form" for example). That is fraught > with peril for a number of reasons I will not go into here. > > So alternatively I thought to put a suspendStack handler in the stack script, > then check for the condition and pop a dialog alerting the user, then issuing > a go stack to refocus on the stack. > > The first time it works great. The second and subsequent times however, > suspendStack is NOT getting sent! Why? Is it because the original stack is no > longer the topStack? > > 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
When is suspendStack sent?
Hi all. I was using modal as a means to prevent a user from switching to another open window while in certain modes (editing a "form" for example). That is fraught with peril for a number of reasons I will not go into here. So alternatively I thought to put a suspendStack handler in the stack script, then check for the condition and pop a dialog alerting the user, then issuing a go stack to refocus on the stack. The first time it works great. The second and subsequent times however, suspendStack is NOT getting sent! Why? Is it because the original stack is no longer the topStack? 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: Standalone build workaround
And the engine itself can support multiple stacks open with the same name. If you do though, you have to use the long name to be sure you access the correct one and the IDE isn't built to always do that. (I've created a demo that validates that the engine can handle this. The engine does prevent opening different files with the same stack name though, so I had to clone and then save the clones with different file names but the same stack name.) For what Bob mentions, it sounds like the stand alone builder isn't keeping track of all the stacks that get opened so that it can set destroyStack to true and close them. Possibly could be as easy as getting a list of open stacks at the end and if the long name of any happens to be in the temp location, then close them before reopening the stack for use in the IDE post-build. Brian On Thu, Sep 20, 2018 at 9:37 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > When I build a standalone, I use a splash stack, which when run in a > standalone opens the mainStack. I do not typically have the mainstack > already open, because as has been mentioned multiple times, any stacks > already open after a build, say when building for a separate platform (I > still cannot build for multiple platforms in one pass like I used to) will > pop up stack already open dialogs and ask me to ignore or purge (no > uninitiated user wants to "purge" any of his stacks it's quite unnerving > the first time you see it). > > So I always QUIT LC, and relaunch to avoid any stack already open errors. > What I think is happening is that the copys of the stacks in the standalone > are being left open, so subsequent opening of the stacks produces this > error. Otherwise, subsequent opening of the stacks are opening the > standalone versions instead of the originals because LC gets confused about > stack name references. > > That's just me blind guessing though. > > Bob S > > > > On Sep 20, 2018, at 04:40 , Ali Lloyd via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Just out of interest, what sorts of things are causing problems in > > openStack while building a standalone that do not happen when opening > > stacks for the first time in the IDE? To put it another way, is it simply > > the re-running of openStack that is causing problems, or is something > going > > wrong? Something like a ‘cascade of errors’ sounds like the latter. > > > > On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> > >> Brian: > >> > >>> What about a front script for the build process that would > >>> intercept and discard these messages? > >> > >> There you go! That might be a smooth solution. Or close the stack during > >> build, and offer a user preference of whether to automatically reopen. > >> > >> Usually there are some fairly good solutions possible, better than > >> doubling-down on a dilemma and the lesser of two evils. This could turn > >> out rather nicely. :) > >> > >> Best wishes, > >> > >> Curry Kenworthy > >> > >> Custom Software Development > >> LiveCode Training and Consulting > >> http://livecodeconsulting.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 ___ 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: SVG to image
I just did a little bit of comparison of the path before and after your widget translated it. The path data is quite a bit different (besides just going to 6 decimal places). Something about how the path is adjusted makes it work better with the path compiler, but it does increase the compiled image size. On Tue, Sep 18, 2018 at 12:11 AM Brian Milby wrote: > Ok, so your results should be the same as the "trimmed" version of the > icons in this repo: > https://github.com/leungwensen/svg-icon > > For most of the icons on that site, the removal of pad is fine. There are > a few where the pad is actually important since there are multiple icons > where some are designed to have blank space. The best examples that I can > find are the WiFi strength icons in the Metro set. > https://leungwensen.github.io/svg-icon/#metro > > Since the repo contains the full SVG of the icons (in both trimmed and > untrimmed versions), if anyone needs one of these icons untrimmed, they can > go to the repo and use the full SVG file directly. I only mention this > because when I originally wrote the SvgIconTool I noticed that some of the > icons looked odd due to the padding removal. > > That demo stack and widget are very effective. I switched over to a > couple different icon sets from that site and everything works great. What > is interesting is that some of the compiled icons look better when compiled > using the template compared to the SVG file on the site. I'll need to look > at that some more to see if I can figure out why. One difference is that > the files use viewBox instead of H & W. > > Thanks for another useful widget! > > On Mon, Sep 17, 2018 at 9:56 AM hh via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> > Brian wrote: >> > I'll need to take your stack/widget and see how what it generates >> > compares to conversions from the source svg file (for the Font >> > Awesome stuff). Since you are adding back information that was >> > stripped when converting to an icon, my guess is that the results >> > should be pretty much the same. >> >> There ARE changes; >> I translate the path to have a bounding box with topleft 0,0 and >> use this translated path. >> This prevents horizotal and especially vertical offsets (which >> is often present and effectively adds unneeded transparency at top). >> >> ___ >> 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: Standalone build workaround
When I build a standalone, I use a splash stack, which when run in a standalone opens the mainStack. I do not typically have the mainstack already open, because as has been mentioned multiple times, any stacks already open after a build, say when building for a separate platform (I still cannot build for multiple platforms in one pass like I used to) will pop up stack already open dialogs and ask me to ignore or purge (no uninitiated user wants to "purge" any of his stacks it's quite unnerving the first time you see it). So I always QUIT LC, and relaunch to avoid any stack already open errors. What I think is happening is that the copys of the stacks in the standalone are being left open, so subsequent opening of the stacks produces this error. Otherwise, subsequent opening of the stacks are opening the standalone versions instead of the originals because LC gets confused about stack name references. That's just me blind guessing though. Bob S > On Sep 20, 2018, at 04:40 , Ali Lloyd via use-livecode > wrote: > > Just out of interest, what sorts of things are causing problems in > openStack while building a standalone that do not happen when opening > stacks for the first time in the IDE? To put it another way, is it simply > the re-running of openStack that is causing problems, or is something going > wrong? Something like a ‘cascade of errors’ sounds like the latter. > > On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> >> Brian: >> >>> What about a front script for the build process that would >>> intercept and discard these messages? >> >> There you go! That might be a smooth solution. Or close the stack during >> build, and offer a user preference of whether to automatically reopen. >> >> Usually there are some fairly good solutions possible, better than >> doubling-down on a dilemma and the lesser of two evils. This could turn >> out rather nicely. :) >> >> Best wishes, >> >> Curry Kenworthy >> >> Custom Software Development >> LiveCode Training and Consulting >> http://livecodeconsulting.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
Re: Standalone build workaround
Just out of interest, what sorts of things are causing problems in openStack while building a standalone that do not happen when opening stacks for the first time in the IDE? To put it another way, is it simply the re-running of openStack that is causing problems, or is something going wrong? Something like a ‘cascade of errors’ sounds like the latter. On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode < use-livecode@lists.runrev.com> wrote: > > Brian: > > > What about a front script for the build process that would > > intercept and discard these messages? > > There you go! That might be a smooth solution. Or close the stack during > build, and offer a user preference of whether to automatically reopen. > > Usually there are some fairly good solutions possible, better than > doubling-down on a dilemma and the lesser of two evils. This could turn > out rather nicely. :) > > Best wishes, > > Curry Kenworthy > > Custom Software Development > LiveCode Training and Consulting > http://livecodeconsulting.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
