iOS 16.4.1 breaks connection with LiveCode test feature

[Mark Talluto via use-livecode]

Hello everyone,

There may be a problem with iOS devices updated to 16.4 or 16.4.1 and Xcode 
14.2 as a working combination. The issue between them is that devices may fail 
to prepare for development (error from Xcode).

https://developer.apple.com/forums/thread/727270

Of course, you can continue to build iOS apps with Xcode 14.2 if you 
accidentally allow your device to upgrade to 16.4.1. You cannot test your app 
directly from the LiveCode IDE using the test button if your device has been 
updated to iOS 16.4 or 16.4.1.

You can build for TestFlight and run your app on your device that way. But, it 
is more cumbersome than direct testing from the LiveCode IDE.

I hope this public service announcement is useful to iOS developers using 
LiveCode. The short of it is do not allow your iOS devices to update to 16.4.1 
for now.


Best regards,
Mark Talluto

appli.io 
livecloud.io 
nursenotes.net 
canelasoftware.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: Weird window behavior

[Marty Knapp via use-livecode]

Bingo - it was “raiseWindows” being set to true. Setting that to false has 
resolved the issue. Weird that it works fine on previous macOSes previous to 
Ventura.
---
Marty Knapp

> On Apr 27, 2023, at 2:35 PM, Mark Waddingham via use-livecode 
>  wrote:
> 
> Okay that is strange - but the fact it is happening when levure is loaded 
> suggests it is some property or mechanism it is adding.
> 
> The engine only really has three things (that I can think of) which change 
> window stacking order…
> 
> The backdrop - which makes the engine *try* to keep all the windows next to 
> each other, with the backdrop window immediately behind the bottom one; 
> 
> The ‘raiseWindows’ global property which is basically the same as the 
> backdrop feature - except the backdrop has zero width and height.
> 
> The go command which raises a stack to the top (amongst those with same mode).
> 
> So i’m not sure how a script in levure could cause that effect - unless it’s 
> setting ‘the raiseWindows’ to true (thus making the problem you are seeing 
> the same as the backdrop issues that others are on Ventura).
> 
> Anyway, the fact it requires levure to be loaded for it to happen means we 
> can track it down!
> 
> Warmest Regards,
> 
> Mark.
> 
> Sent from my iPhone
> 
>> On 27 Apr 2023, at 19:58, Marty Knapp via use-livecode 
>>  wrote:
>> 
>> No, not using the backdrop feature. I did try the suggestion on bug 24200 
>> to change the system setting "Group Windows By Application" in the "Desktop 
>> and Dock System Setting" preference pane to true. Same behavior, even after 
>> a restart. And it is happening in both the IDE and in a standalone. The 
>> standalone is built with the Levure framework. In the IDE the issue only 
>> happens *after* I’ve loaded the Levure framework.
>> ---
>> Marty Knapp
>> 
>>> On Apr 27, 2023, at 9:39 AM, Mark Waddingham via use-livecode 
>>>  wrote:
>>> 
 On 2023-04-19 19:25, Marty Knapp via use-livecode wrote:
 Ever since I updated to Ventura on my Mac I've had this weird behavior 
 both in the IDE and in two different standalones - if I have more than one 
 stack open, when I click on a stack that is behind another stack to bring 
 it to the front, it very briefly comes to the front (flashes), then goes 
 back behind everything, even windows from other apps. If I click on the 
 title bar it does not do this. In the menubar is still indicates that I'm 
 in my app. It's not happening with any non-Livecode apps and it's 
 occurring on two different Macs. I’m not seeing this behavior on OSes 
 previous to Ventura.
 Am I going crazy?
>>> 
>>> Do you (or anyone else who has chimed in on this list) have the backdrop 
>>> feature enabled?
>>> 
>>> The reason I ask is that the behavior you describe is similar to this 
>>> report https://quality.livecode.com/show_bug.cgi?id=24199 (I think at 
>>> least) - which has now reduced to being due to the backdrop - 
>>> https://quality.livecode.com/show_bug.cgi?id=24200.
>>> 
>>> Warmest Regards,
>>> 
>>> Mark.
>>> 
>>> -- 
>>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>>> LiveCode: Build Amazing Things
>>> 
>>> ___
>>> 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: Custom property retrieval incorrect

[Bob Sneidar via use-livecode]

Well... ;-)


Thanks for tracking it down, Mark. I'm not crazy after all.

--
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: Custom property retrieval incorrect

[J. Landman Gay via use-livecode]

Those are exactly the two values I get too. The earliest version of LC I currently have 
installed is 9.6.7 and it happens there and in three newer versions after that.


A custom property named "cVers" works okay. But I've been using "cVersion" for years and years, 
so not sure what the ripple effect may be if I update my older apps (which is how I found this 
one.) For now I can change the name of the property, I guess.


Thanks for tracking it down, Mark. I'm not crazy after all.

On 4/27/23 5:09 PM, Mark Wieder via use-livecode wrote:


The 1.0.4 cVersion comes from com.livecode.library.i18n.1.0.4
The 3.0.9 cVersion comes from com.livecode.library.smartcrumbsvcw.3.0.9

Unfortunately the scripts for both are locked, so there's no workaround other than not using 
the cVersion custom property.




--
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: Custom property retrieval incorrect

[Mark Wieder via use-livecode]

On 4/27/23 14:18, Mark Waddingham via use-livecode wrote:

Intriguing - my guess is that something in the message path in your IDEs has a 
getProp cVersion handler.

Now it could be something built into the IDE - although I’m not sure what - or 
it could be a plug-in or extension.

An easy way to find out is to temporarily rename the ‘My LiveCode’ folder and 
restart the IDE to see if it still happens…


The 1.0.4 cVersion comes from com.livecode.library.i18n.1.0.4
The 3.0.9 cVersion comes from com.livecode.library.smartcrumbsvcw.3.0.9

Unfortunately the scripts for both are locked, so there's no workaround 
other than not using the cVersion custom property.


--
 Mark Wieder
 ahsoftw...@gmail.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: Problem using AppleScript of "system events" to click a location on screen

[Mark Waddingham via use-livecode]

You didn’t mention the kind of mac you are running and whether either the 
standalone or ide is running in rosetta or not :)

To be fair, that part was about the exec error rather than the expected outcome 
though…

The reason you are seeing the effect you are when not doing the request from a 
separate process is that executing applescript is a modal operation (Ie you 
can’t get an application to use AppleScript to control itself) - and I suspect 
the accessibility framework is timing out internally and just doing the best it 
can in that situation.

Warmest Regards,

Mark.

Sent from my iPhone

> On 27 Apr 2023, at 19:22, Ben Rubinstein via use-livecode 
>  wrote:
> 
> Update to note:
> 
> 1) Difference in LiveCode versions.
> 
> Under the IDE in LiveCode 9.6.7 behaviour is as per the standalone; no click, 
> and 'the result' is the path to the control.  Under the IDE in LiveCode 9.6.8 
> or LiveCode 10.0.0dp5, 'the result' is "execution error".
> 
> 2) The browser widget is a red herring; relevant only insofar as if it was 
> some other spot on the stack, I could just the LiveCode "click at ". 
> Whether over the browser widget or some other part of the stack window, 
> invoking the applescript returns the identity of the control at that 
> location, rather than clicking it (in LC 9.6.7 IDE, or standalone built from 
> any version); or execution error in later IDEs.
> 
>> On 27/04/2023 16:42, Ben Rubinstein via use-livecode wrote:
>> I had a need to click on an element in a web page loaded in a browser widget 
>> on a card.
>> There might be an elegant way to do this using javascript injected into the 
>> widget, but I'm too ignorant to figure it out.
>> So to save time (hah!), I though I could use the accessibility functionality 
>> to just click on that bit of the screen. I could get the location to click 
>> within the stack, then use globalLoc to convert it to screen coordinates.
>> (This is just a personal stack to achieve an objective, nothing that's ever 
>> going to be shared with anyone else, so any filthy/fragile method is OK if 
>> it works.)
>> I tested this in Script Debugger:
>> tell application "System Events"
>> click at {917, 667}
>> end tell
>> It worked fine.
>> So then I tried the same script in my stack, via
>> do ... as "applescript"
>> And after a brief spinning pizza, got the dry result "execution error".
>> I expected that this would happen because I needed to give it permission to 
>> control the computer; but after granting that in System Preferences, there 
>> was no change.
>> Just for fun, I tried building a standalone from my stack. This demonstrated 
>> a different effect: first I got the same result "execution error". Then I 
>> granted it permission for this standalone app to 'control the computer'. 
>> Now, there's still no evidence that it sends a click; but it gives a 
>> different result, which I think is the path to the UI element corresponding 
>> to that location. If the point is over a native control in the stack, it's 
>> something like
>>  window "Ben Test Stack (1)" of application process "Ben Test Stack"
>> of application "System Events"
>> (I don't think LiveCode controls are recognisable by the accessibility 
>> system.) If the point is over the browser widget, 'the result' is something 
>> like:
>> group 2 of UI element 1 of scroll area 1 of group 1 of group 1
>>  of window "Ben Test Stack (1)" of application process "Ben Test Stack"
>> of application "System Events"
>> ("Ben Test Stack" is the name of my stack and of the standalone. My guess 
>> about the complicated control path is that it reflects the complicated web 
>> page loaded in the browser widget.)
>> So that does suggest that there is something which doesn't quite work about 
>> giving the IDE permission to use the Accessibility Framework, but which does 
>> for a standalone. But still doesn't explain what the problem is.
>> I finally solved my problem with an even uglier hack: compiling the script 
>> from Script Debugger as an 'application', and then in my stack, instead of 
>> executing the applescript directly, using "launch" on that application. 
>> Yeuchh.
>> Can anyone shed light, either on how to grant the IDE permission to use the 
>> Accessibility controls; or on why the applescript wouldn't work?
>> TIA,
>> Ben
>> ___
>> 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

Re: Weird window behavior

[Mark Waddingham via use-livecode]

Okay that is strange - but the fact it is happening when levure is loaded 
suggests it is some property or mechanism it is adding.

The engine only really has three things (that I can think of) which change 
window stacking order…

The backdrop - which makes the engine *try* to keep all the windows next to 
each other, with the backdrop window immediately behind the bottom one; 

The ‘raiseWindows’ global property which is basically the same as the backdrop 
feature - except the backdrop has zero width and height.

The go command which raises a stack to the top (amongst those with same mode).

So i’m not sure how a script in levure could cause that effect - unless it’s 
setting ‘the raiseWindows’ to true (thus making the problem you are seeing the 
same as the backdrop issues that others are on Ventura).

Anyway, the fact it requires levure to be loaded for it to happen means we can 
track it down!

Warmest Regards,

Mark.

Sent from my iPhone

> On 27 Apr 2023, at 19:58, Marty Knapp via use-livecode 
>  wrote:
> 
> No, not using the backdrop feature. I did try the suggestion on bug 24200 to 
> change the system setting "Group Windows By Application" in the "Desktop and 
> Dock System Setting" preference pane to true. Same behavior, even after a 
> restart. And it is happening in both the IDE and in a standalone. The 
> standalone is built with the Levure framework. In the IDE the issue only 
> happens *after* I’ve loaded the Levure framework.
> ---
> Marty Knapp
> 
>> On Apr 27, 2023, at 9:39 AM, Mark Waddingham via use-livecode 
>>  wrote:
>> 
>>> On 2023-04-19 19:25, Marty Knapp via use-livecode wrote:
>>> Ever since I updated to Ventura on my Mac I've had this weird behavior both 
>>> in the IDE and in two different standalones - if I have more than one stack 
>>> open, when I click on a stack that is behind another stack to bring it to 
>>> the front, it very briefly comes to the front (flashes), then goes back 
>>> behind everything, even windows from other apps. If I click on the title 
>>> bar it does not do this. In the menubar is still indicates that I'm in my 
>>> app. It's not happening with any non-Livecode apps and it's occurring on 
>>> two different Macs. I’m not seeing this behavior on OSes previous to 
>>> Ventura.
>>> Am I going crazy?
>> 
>> Do you (or anyone else who has chimed in on this list) have the backdrop 
>> feature enabled?
>> 
>> The reason I ask is that the behavior you describe is similar to this report 
>> https://quality.livecode.com/show_bug.cgi?id=24199 (I think at least) - 
>> which has now reduced to being due to the backdrop - 
>> https://quality.livecode.com/show_bug.cgi?id=24200.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Build Amazing Things
>> 
>> ___
>> 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: Custom property retrieval incorrect

[Mark Waddingham via use-livecode]

Intriguing - my guess is that something in the message path in your IDEs has a 
getProp cVersion handler.

Now it could be something built into the IDE - although I’m not sure what - or 
it could be a plug-in or extension.

An easy way to find out is to temporarily rename the ‘My LiveCode’ folder and 
restart the IDE to see if it still happens…

Warmest Regards,

Mark

Sent from my iPhone

> On 27 Apr 2023, at 20:51, J. Landman Gay via use-livecode 
>  wrote:
> 
> I have a custom stack property called "cVersion" that is used to determine 
> update availability and is shown in an About stack. In LC 9.6.7, 9.6.9, and 
> 10.0.0 dp 5 the custom property is returned incorrectly.
> 
> I set the cVersion of the stack to 3.0.0 in the property inspector and also 
> tried from the message box and from a handler. In both the message box and in 
> a script it returns 3.0.9. I saved the stack, quit LC, relaunched and opened 
> the stack and it then reported 1.0.4. I don't know where these numbers are 
> coming from.
> 
> There are three substacks but none of them have any custom properties at all. 
> When I open the stack property inspector it does correctly say "3.0.0".
> 
> I deleted the custom property completely and then re-entered it. It still 
> says 3.0.9 on a new launch.
> 
> I created a new custom property called "cVers" and it does report 3.0.0 as 
> specified. Other custom stack properties also retrieve correctly, it is only 
> this particular one that fails.
> 
> Anyone seen this? Is there something special about a custom prop named 
> "cVersion"? This used to work fine, but that was about 2 years ago.
> 
> -- 
> 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


___
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: Custom property retrieval incorrect

[matthias rebbe via use-livecode]

I just created a stack in LC 10DP5 without setting any property and run  
put the cVersion of this stack
while the stack was show as the target in messagebox and it returned 1.0.4

When i do this in 9.6.9 it returns 3.0.9.

And now if i repeat it in 10DP5 it returns also 3.0.9

without having set cVersion.




> Am 27.04.2023 um 21:50 schrieb J. Landman Gay via use-livecode 
> :
> 
> I have a custom stack property called "cVersion" that is used to determine 
> update availability and is shown in an About stack. In LC 9.6.7, 9.6.9, and 
> 10.0.0 dp 5 the custom property is returned incorrectly.
> 
> I set the cVersion of the stack to 3.0.0 in the property inspector and also 
> tried from the message box and from a handler. In both the message box and in 
> a script it returns 3.0.9. I saved the stack, quit LC, relaunched and opened 
> the stack and it then reported 1.0.4. I don't know where these numbers are 
> coming from.
> 
> There are three substacks but none of them have any custom properties at all. 
> When I open the stack property inspector it does correctly say "3.0.0".
> 
> I deleted the custom property completely and then re-entered it. It still 
> says 3.0.9 on a new launch.
> 
> I created a new custom property called "cVers" and it does report 3.0.0 as 
> specified. Other custom stack properties also retrieve correctly, it is only 
> this particular one that fails.
> 
> Anyone seen this? Is there something special about a custom prop named 
> "cVersion"? This used to work fine, but that was about 2 years ago.
> 
> -- 
> 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


___
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: Custom property retrieval incorrect

[Mark Wieder via use-livecode]

On 4/27/23 12:50, J. Landman Gay via use-livecode wrote:

Anyone seen this? Is there something special about a custom prop named 
"cVersion"? This used to work fine, but that was about 2 years ago.


Verified here. cVersion is weird. I get 1.0.4 on all stacks.
I put all the properties for update checks etc in a custom propertyset 
and just access them from there. Never tried cVersion before.


--
 Mark Wieder
 ahsoftw...@gmail.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: Custom property retrieval incorrect

[Craig Newman via use-livecode]

Jacque.

Have you tried another name, Like “XYZ”?

Craig

> On Apr 27, 2023, at 3:50 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> I have a custom stack property called "cVersion" that is used to determine 
> update availability and is shown in an About stack. In LC 9.6.7, 9.6.9, and 
> 10.0.0 dp 5 the custom property is returned incorrectly.
> 
> I set the cVersion of the stack to 3.0.0 in the property inspector and also 
> tried from the message box and from a handler. In both the message box and in 
> a script it returns 3.0.9. I saved the stack, quit LC, relaunched and opened 
> the stack and it then reported 1.0.4. I don't know where these numbers are 
> coming from.
> 
> There are three substacks but none of them have any custom properties at all. 
> When I open the stack property inspector it does correctly say "3.0.0".
> 
> I deleted the custom property completely and then re-entered it. It still 
> says 3.0.9 on a new launch.
> 
> I created a new custom property called "cVers" and it does report 3.0.0 as 
> specified. Other custom stack properties also retrieve correctly, it is only 
> this particular one that fails.
> 
> Anyone seen this? Is there something special about a custom prop named 
> "cVersion"? This used to work fine, but that was about 2 years ago.
> 
> -- 
> 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


___
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

Custom property retrieval incorrect

[J. Landman Gay via use-livecode]

I have a custom stack property called "cVersion" that is used to determine update availability 
and is shown in an About stack. In LC 9.6.7, 9.6.9, and 10.0.0 dp 5 the custom property is 
returned incorrectly.


I set the cVersion of the stack to 3.0.0 in the property inspector and also tried from the 
message box and from a handler. In both the message box and in a script it returns 3.0.9. I 
saved the stack, quit LC, relaunched and opened the stack and it then reported 1.0.4. I don't 
know where these numbers are coming from.


There are three substacks but none of them have any custom properties at all. When I open the 
stack property inspector it does correctly say "3.0.0".


I deleted the custom property completely and then re-entered it. It still says 3.0.9 on a new 
launch.


I created a new custom property called "cVers" and it does report 3.0.0 as specified. Other 
custom stack properties also retrieve correctly, it is only this particular one that fails.


Anyone seen this? Is there something special about a custom prop named "cVersion"? This used to 
work fine, but that was about 2 years ago.


--
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: Weird window behavior

[Marty Knapp via use-livecode]

No, not using the backdrop feature. I did try the suggestion on bug 24200 to 
change the system setting "Group Windows By Application" in the "Desktop and 
Dock System Setting" preference pane to true. Same behavior, even after a 
restart. And it is happening in both the IDE and in a standalone. The 
standalone is built with the Levure framework. In the IDE the issue only 
happens *after* I’ve loaded the Levure framework.
---
Marty Knapp

> On Apr 27, 2023, at 9:39 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2023-04-19 19:25, Marty Knapp via use-livecode wrote:
>> Ever since I updated to Ventura on my Mac I've had this weird behavior both 
>> in the IDE and in two different standalones - if I have more than one stack 
>> open, when I click on a stack that is behind another stack to bring it to 
>> the front, it very briefly comes to the front (flashes), then goes back 
>> behind everything, even windows from other apps. If I click on the title bar 
>> it does not do this. In the menubar is still indicates that I'm in my app. 
>> It's not happening with any non-Livecode apps and it's occurring on two 
>> different Macs. I’m not seeing this behavior on OSes previous to Ventura.
>> Am I going crazy?
> 
> Do you (or anyone else who has chimed in on this list) have the backdrop 
> feature enabled?
> 
> The reason I ask is that the behavior you describe is similar to this report 
> https://quality.livecode.com/show_bug.cgi?id=24199 (I think at least) - which 
> has now reduced to being due to the backdrop - 
> https://quality.livecode.com/show_bug.cgi?id=24200.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Build Amazing Things
> 
> ___
> 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: Problem using AppleScript of "system events" to click a location on screen

[Ben Rubinstein via use-livecode]

Update to note:

1) Difference in LiveCode versions.

Under the IDE in LiveCode 9.6.7 behaviour is as per the standalone; no click, 
and 'the result' is the path to the control.  Under the IDE in LiveCode 9.6.8 
or LiveCode 10.0.0dp5, 'the result' is "execution error".


2) The browser widget is a red herring; relevant only insofar as if it was 
some other spot on the stack, I could just the LiveCode "click at ". 
Whether over the browser widget or some other part of the stack window, 
invoking the applescript returns the identity of the control at that location, 
rather than clicking it (in LC 9.6.7 IDE, or standalone built from any 
version); or execution error in later IDEs.


On 27/04/2023 16:42, Ben Rubinstein via use-livecode wrote:
I had a need to click on an element in a web page loaded in a browser widget 
on a card.


There might be an elegant way to do this using javascript injected into the 
widget, but I'm too ignorant to figure it out.


So to save time (hah!), I though I could use the accessibility functionality 
to just click on that bit of the screen. I could get the location to click 
within the stack, then use globalLoc to convert it to screen coordinates.


(This is just a personal stack to achieve an objective, nothing that's ever 
going to be shared with anyone else, so any filthy/fragile method is OK if it 
works.)


I tested this in Script Debugger:

 tell application "System Events"
     click at {917, 667}
 end tell

It worked fine.

So then I tried the same script in my stack, via
 do ... as "applescript"

And after a brief spinning pizza, got the dry result "execution error".

I expected that this would happen because I needed to give it permission to 
control the computer; but after granting that in System Preferences, there was 
no change.


Just for fun, I tried building a standalone from my stack. This demonstrated a 
different effect: first I got the same result "execution error". Then I 
granted it permission for this standalone app to 'control the computer'. Now, 
there's still no evidence that it sends a click; but it gives a different 
result, which I think is the path to the UI element corresponding to that 
location. If the point is over a native control in the stack, it's something like

  window "Ben Test Stack (1)" of application process "Ben Test Stack"
 of application "System Events"

(I don't think LiveCode controls are recognisable by the accessibility 
system.) If the point is over the browser widget, 'the result' is something like:

 group 2 of UI element 1 of scroll area 1 of group 1 of group 1
  of window "Ben Test Stack (1)" of application process "Ben Test Stack"
 of application "System Events"

("Ben Test Stack" is the name of my stack and of the standalone. My guess 
about the complicated control path is that it reflects the complicated web 
page loaded in the browser widget.)


So that does suggest that there is something which doesn't quite work about 
giving the IDE permission to use the Accessibility Framework, but which does 
for a standalone. But still doesn't explain what the problem is.


I finally solved my problem with an even uglier hack: compiling the script 
from Script Debugger as an 'application', and then in my stack, instead of 
executing the applescript directly, using "launch" on that application. Yeuchh.


Can anyone shed light, either on how to grant the IDE permission to use the 
Accessibility controls; or on why the applescript wouldn't work?


TIA,

Ben

___
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: Weird window behavior

[Mark Waddingham via use-livecode]

On 2023-04-19 19:25, Marty Knapp via use-livecode wrote:
Ever since I updated to Ventura on my Mac I've had this weird behavior 
both in the IDE and in two different standalones - if I have more than 
one stack open, when I click on a stack that is behind another stack to 
bring it to the front, it very briefly comes to the front (flashes), 
then goes back behind everything, even windows from other apps. If I 
click on the title bar it does not do this. In the menubar is still 
indicates that I'm in my app. It's not happening with any non-Livecode 
apps and it's occurring on two different Macs. I’m not seeing this 
behavior on OSes previous to Ventura.


Am I going crazy?


Do you (or anyone else who has chimed in on this list) have the backdrop 
feature enabled?


The reason I ask is that the behavior you describe is similar to this 
report https://quality.livecode.com/show_bug.cgi?id=24199 (I think at 
least) - which has now reduced to being due to the backdrop - 
https://quality.livecode.com/show_bug.cgi?id=24200.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things

___
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: Problem using AppleScript of "system events" to click a location on screen

[Mark Waddingham via use-livecode]

On 2023-04-27 16:42, Ben Rubinstein via use-livecode wrote:
Can anyone shed light, either on how to grant the IDE permission to use 
the Accessibility controls; or on why the applescript wouldn't work?


Not immediately - no :)

However, three questions... What version of LC are you using? Are you 
using an Apple architecture mac? If so, is the IDE running under 
Rosetta, and the standalone native, or vice-versa (or both the same)?


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things

___
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

Problem using AppleScript of "system events" to click a location on screen

[Ben Rubinstein via use-livecode]

I had a need to click on an element in a web page loaded in a browser widget 
on a card.


There might be an elegant way to do this using javascript injected into the 
widget, but I'm too ignorant to figure it out.


So to save time (hah!), I though I could use the accessibility functionality 
to just click on that bit of the screen. I could get the location to click 
within the stack, then use globalLoc to convert it to screen coordinates.


(This is just a personal stack to achieve an objective, nothing that's ever 
going to be shared with anyone else, so any filthy/fragile method is OK if it 
works.)


I tested this in Script Debugger:

tell application "System Events"
click at {917, 667}
end tell

It worked fine.

So then I tried the same script in my stack, via
do ... as "applescript"

And after a brief spinning pizza, got the dry result "execution error".

I expected that this would happen because I needed to give it permission to 
control the computer; but after granting that in System Preferences, there was 
no change.


Just for fun, I tried building a standalone from my stack. This demonstrated a 
different effect: first I got the same result "execution error". Then I 
granted it permission for this standalone app to 'control the computer'. Now, 
there's still no evidence that it sends a click; but it gives a different 
result, which I think is the path to the UI element corresponding to that 
location. If the point is over a native control in the stack, it's something like

window "Ben Test Stack (1)" of application process "Ben Test Stack"
of application "System Events"

(I don't think LiveCode controls are recognisable by the accessibility 
system.) If the point is over the browser widget, 'the result' is something like:

group 2 of UI element 1 of scroll area 1 of group 1 of group 1
of window "Ben Test Stack (1)" of application process "Ben Test Stack"
of application "System Events"

("Ben Test Stack" is the name of my stack and of the standalone. My guess 
about the complicated control path is that it reflects the complicated web 
page loaded in the browser widget.)


So that does suggest that there is something which doesn't quite work about 
giving the IDE permission to use the Accessibility Framework, but which does 
for a standalone. But still doesn't explain what the problem is.


I finally solved my problem with an even uglier hack: compiling the script 
from Script Debugger as an 'application', and then in my stack, instead of 
executing the applescript directly, using "launch" on that application. Yeuchh.


Can anyone shed light, either on how to grant the IDE permission to use the 
Accessibility controls; or on why the applescript wouldn't work?


TIA,

Ben

___
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: Are we talking about the Xavvi efforts here?

[Heather Laine via use-livecode]

Mark - 

April 27th is when the very best discounts on pledging expire.
The timeline for pledged licenses begins when we ship Xavvi.
Yes, we're adding a chatGPT connector for you to use within your apps.

I hope this helps,

Best Regards,

Heather

Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.com



> On 27 Apr 2023, at 01:58, Mark Rauterkus via use-livecode 
>  wrote:
> 
> Hi,
> 
> I have some questions.
> 
> What’s up with the April 27th offer?
> 
> When does the timeline begin. So, if a year license is obtained, when might
> that year begin? September 1?
> 
> Chat GPT is used for the creation of the app, but can the AI be used within
> the app too? That seems to me to be a huge benefit. So in the example with
> the doctor’s table, could the AI fill the data of Doctors within the county
> or a 50 mile area?
> 
> 
> Mark Rauterkus
> m...@rauterkus.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