Re: Remote debugging - expected behavior

On 9/28/17 8:54 PM, Monte Goulding via use-livecode wrote: On 29 Sep 2017, at 7:13 am, J. Landman Gay via use-livecode wrote: Thanks. One more question: should remote debugging work with script-only stacks that are part of the app? I have several breakpoints

Re: MacOS 10.13 crashes LC after color dialog

It has been like this since the second developer beta of MacOS 10.13. In the very first developer beta of MacOS 10.13, LC would crash before it managed to open the color picker. Tore Nilsen > 29. sep. 2017 kl. 07:22 skrev Roger Guay via use-livecode > : > >

Re: MacOS 10.13 crashes LC after color dialog

Yup, same for me on Macbook Pro Retina. Roger > On Sep 28, 2017, at 10:11 PM, hh via use-livecode > wrote: > > MacOS 10.13, LC 6.7.11/ 7.1.4/ 8.1.6/ 9.0.0-dp9 > (here on Mac mini/late 2012 2.5 GHz i5, Intel Grahics HD 4000) > > When using the color dialog from

MacOS 10.13 crashes LC after color dialog

MacOS 10.13, LC 6.7.11/ 7.1.4/ 8.1.6/ 9.0.0-dp9 (here on Mac mini/late 2012 2.5 GHz i5, Intel Grahics HD 4000) When using the color dialog from the Property Inspector or via "answer color", every latest LC version, from LC 6.7.11 up to LC 9.0.0-dp9, crashes immediately. Hopefully the LC-team can

Re: Remote debugging - expected behavior

> On 29 Sep 2017, at 7:13 am, J. Landman Gay via use-livecode > wrote: > > Thanks. One more question: should remote debugging work with script-only > stacks that are part of the app? I have several breakpoints set but none of > them trigger in a test build.

Re: Remote debugging - expected behavior

This sounds similar to a problem I have building apps. I have a login stack that I call modally when the main stack is opened. When I build the app it OPENS THE LOGIN APP MODALLY as though it is actually RUNNING my scripts, and since it is modal I have to manually set the stack to top-level for

Re: find name of handler that triggered current handler

Should be line -2 of the executionContexts. Bob S > On Sep 28, 2017, at 13:35 , Tom Glod via use-livecode > wrote: > > i think this will do thanks Mike ___ use-livecode mailing list

Re: Remote debugging - expected behavior

well, now it's there, so I commented on it, there. On Thu, Sep 28, 2017 at 5:34 PM, J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > I just opened a new report before I read your post: > http://quality.livecode.com/show_bug.cgi?id=20487 > > I'm not currently testing

Re: Remote debugging - expected behavior

I just opened a new report before I read your post: http://quality.livecode.com/show_bug.cgi?id=20487 I'm not currently testing script errors, I'm testing other things and I don't need remote debugging right now. It's getting in the way. On 9/28/17 3:32 PM, Mike Kerner via use-livecode wrote:

Re: Remote debugging - expected behavior

Thanks. One more question: should remote debugging work with script-only stacks that are part of the app? I have several breakpoints set but none of them trigger in a test build. On 9/28/17 2:16 PM, panagiotis merakos via use-livecode wrote: Hi Jacque, This is the expected behaviour. The

Re: [ANN] IPA Build Tool for iOS

Sean: Thanks for the info. It saves me a bunch of frustrating time. Best, Bill > On Sep 28, 2017, at 11:57 AM, Sean Cole (Pi) via use-livecode > wrote: > > It won't work as it will be an encrypted binary with a checksum of some > kind (right at the end of the xml

Re: find name of handler that triggered current handler

i think this will do thanks Mike On Thu, Sep 28, 2017 at 3:18 PM, Mike Bonner via use-livecode < use-livecode@lists.runrev.com> wrote: > Look at executionContexts in the dictionary, it should do what you want. > > On Thu, Sep 28, 2017 at 1:15 PM, Tom Glod via use-livecode < >

Re: Remote debugging - expected behavior

Then why not remove remote debugger from the (cluttered) inclusions list and only include it if the developer chooses 'test' (similar to what Monte was wondering in that QR). It seems weird and unnecessary, and possibly insecure to do it otherwise (insecure because if you forget to remove it from

Re: Remote debugging - expected behavior

Hi Jacque, This is the expected behaviour. The remote debugger is included in the standalone when you click on the Test button, even if you don't select it in the Inclusions (the same applies to Android Internet permission). See the discussion in this bug report:

RE: IPad Mini reports "not supported

I ran into this and had to de-select the GPS and only select Location Services to make the app available on non-GPS devices. I can still get lat/lon cords. What I am unclear about is if the GPS chip is used on devices that have them. Ralph DiMola IT Director Evergreen Information Services

Re: find name of handler that triggered current handler

Look at executionContexts in the dictionary, it should do what you want. On Thu, Sep 28, 2017 at 1:15 PM, Tom Glod via use-livecode < use-livecode@lists.runrev.com> wrote: > Hi folks, > > How do i find the name and location of a handler that triggered the current > handler? somehow it seems

find name of handler that triggered current handler

Hi folks, How do i find the name and location of a handler that triggered the current handler? somehow it seems like it should be possible and necessary, but i can't seem to find any reference to it. Thanks, Tom ___ use-livecode mailing list

Re: [ANN] IPA Build Tool for iOS

It won't work as it will be an encrypted binary with a checksum of some kind (right at the end of the xml stuff. It's really easy to create the PPs, though, so I'm not sure what the benefit would be in trying to edit it. Just go to your dev account, add in the IDs and remake the profile. The old

Remote debugging - expected behavior

What is the expected behavior of remote debugging? I'm not sure if what I see is how it is supposed to work, or a bug. I have an app that does not have the remote debugger included in the Inclusions pane. Looking at the revStandaloneSettings custom properties, it is (correctly) not in there

Re: A modest proposal for a new property

On 9/28/17 11:53 AM, hh via use-livecode wrote: JLG wrote: The original issue that influenced this one was how to provide a larger hit zone on an SVG widget... Yet another option. You can use my iconGrid widget for that. Use a 1x1 grid with your SVG icon as property. It informs you whether

Re: IPad Mini reports "not supported

I've been having a similar problem with an app that I just never got around to debugging. After looking at that device compatibility matrix, I think my problem is that GPS is selected as a required provision (trying to get latitude/longitude from user when a certain function is executed).

Re: A modest proposal for a new property

> JLG wrote: > The original issue that influenced this one was > how to provide a larger hit zone on an SVG widget... Yet another option. You can use my iconGrid widget for that. Use a 1x1 grid with your SVG icon as property. It informs you whether the used SVG icon itself or the enlarged

Re: [ANN] IPA Build Tool for iOS

Sean: I am curious if it is a reasonable idea to edit the provisioning profile directly using BBEdit to add UDID’s for beta testing, without going to the Apple Developer site to add beta testers. I see a lot of “?” characters when I open the provisioning profile in BBEdit, so I wonder if it is

Re: macOS 10.13 and xCode 9 compatibility?

Thanks Panos! > On Sep 28, 2017, at 10:04 AM, panagiotis merakos via use-livecode > wrote: > > Hi Steve, > > Yes, that support will be rolled into the next DP release of 8.2 and 9.0 as > well. > > Regarding macOS High Sierra, I had installed one of its betas in

Re: macOS 10.13 and xCode 9 compatibility?

Hi Steve, Yes, that support will be rolled into the next DP release of 8.2 and 9.0 as well. Regarding macOS High Sierra, I had installed one of its betas in a partition, and I did not notice any issues. I think several community members use 10.13 and have no issues so far. Best regards, Panos

Re: macOS 10.13 and xCode 9 compatibility?

Hi Panos, Thanks for the quick reply! I take it that support will be rolled into the next DP release of 9.0 as well? Note to all, keep a copy of xCode 8.x and rename it before updating to xCode 9. Any word on macOS 10.13? Anyone have issues with AFPS? Best, Steve MacLean > On Sep 28, 2017,

Re: macOS 10.13 and xCode 9 compatibility?

Hi Stephen, No, support for Xcode9 has not been added yet. We have a pending PR for that, so it will appear in the next 8.1.7 RC2 release. Important note: You do NOT need to rebuild your apps with xcode 9 if you want them to run on iOS 11. This will happen seamlessly (remember that in the

macOS 10.13 and xCode 9 compatibility?

Hi All, Just checking on macOS 10.13 and xCode 9 compatibility… Anyone run into any issues with 10.13 and AFPS? Has LC been updated for compatibility with xCode 9? TIA, Steve MacLean ___ use-livecode mailing list use-livecode@lists.runrev.com