That's exactly what I saw. I changed the script of a completely unrelated
control elsewhere and the login graphic started working again. I wish I'd
saved the bad stack to send to the team.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
I have run into that same scenario more than once. In most cases, over time as
I continue to change things, these situations resolve themselves so that
toggling acceleratedRendering is no longer needed. But what exactly changed is
a mystery :- )
> On Jun 2, 2020, at 10:46 PM, J. Landman Gay
In my case all groups that use a scroller have scrolling layermode set.
They work. The primary problem for me is that regular LC controls stop
getting messages and responding to taps.
All these controls are set to static layermode, so I'm not sure how
acceleratedRendering could affect them.
On the test device (an iPhone 6s) it was reporting a compositorCacheLimit of
67108864 (64Mb?) and I increased it by 16Mbs to 83886080 which solved the
problem. I didn’t try to find where the edge was. After looking at the
layerMode of underlying groups and changing ones that obviously should
How much did you increase the compositorCacheLimit?
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 2, 2020 7:57:58 PM scott--- via use-livecode
wrote:
Hello Randy,
Adjusting the compositorCacheLimit (instead of toggling the
I had two different scrolling groups on a card where I found it necessary to
toggling acceleratedRendering. I just discovered that neither of these groups
had the layerMode set to “scrolling” (they were both “static”). Though they
appeared to scroll smoothly on all my test devices, changing
Hello Randy,
Adjusting the compositorCacheLimit (instead of toggling the
acceleratedRendering) also seems to fix my most recent encounter. It is good to
have work-arounds but frustrating to have the issue crop up.
—
Scott
> On Jun 2, 2020, at 5:20 AM, Randy Hengst via use-livecode
> wrote:
I haven’t found that using touch messages instead of mouse messages makes any
difference.
--
Scott
> On Jun 1, 2020, at 1:19 PM, matthias rebbe via use-livecode
> wrote:
>
>
> I am not sure if this will solve your problem, but did you try the touch
> messages instead?
>
> Matthias
>
>
>>
On 6/1/20 3:19 PM, matthias rebbe via use-livecode wrote:
I am not sure if this will solve your problem, but did you try the touch
messages instead?
It may have changed since I last tried that, which was years ago, but I found that if you have
both mouse and touch messages, you get both
Did you increase the compositorCacheLimit in addition to toggling acceleratedRendering, or does
the adjustment work by itself?
Also, were you able to find a good compromise for the increated limit that would work on any
i-thing?
On 6/2/20 7:20 AM, Randy Hengst via use-livecode wrote:
I have
I have an iOS app that uses many graphics with movement… in addition to doing
as Scott suggested (toggling acceleratedRendering on an off) I also messed with
adjusting the compositorCacheLimit. Raising the limit helped. Doing this also
helped with some screen redraw issues I saw that sounds
On 6/1/20 11:30 PM, Mark Wieder via use-livecode wrote:
On 6/1/20 9:15 PM, J. Landman Gay via use-livecode wrote:
Oh my gosh, I *never* would have guessed that fullscreenMode was the culprit. That's kind of
screwy isn't it? Why would it block taps? And not consistently either.
WTF?
My
I meant acceleratedRendering, sorry. I was talking to someone about fullscreenMode right before
I answered you and had a think-o. I do have acceleratedRendering enabled in my app.
I also ran into the problem you described below -- taps went through but the screen did not
redraw so the content
And it seems that, at least in my last run-in, the taps were actually going
through… it is just that they weren't being drawn on the screen. I had
displayed a group with a visual effect inside a rect… only controls inside the
rect appeared unresponsive. When put away using unlock the screen
I don’t use fullscreenMode. Is acceleratedRendering a default requirement of
fullscreenMode?
I’ve been unable to create a simple recipe. In my cases I am suspicious that it
has something to do with overlapping groups… but obviously it is more than that.
—
Scott
> On Jun 1, 2020, at 9:15 PM, J.
On 6/1/20 9:15 PM, J. Landman Gay via use-livecode wrote:
Oh my gosh, I *never* would have guessed that fullscreenMode was the
culprit. That's kind of screwy isn't it? Why would it block taps? And
not consistently either.
WTF?
--
Mark Wieder
ahsoftw...@gmail.com
Oh my gosh, I *never* would have guessed that fullscreenMode was the culprit. That's kind of
screwy isn't it? Why would it block taps? And not consistently either.
I'm very glad you knew what was wrong, I was completely at a loss. Thank you. It seems like
this needs a bug report but there's no
For me, when I run across this (and I have several times… including one just
last week) it is almost always acceleratedRendering.
I usually end up toggling it off and on and then all works fine.
Sometimes I wrap code between these but sometimes I just put this at the end of
the handler that
I am not sure if this will solve your problem, but did you try the touch
messages instead?
Matthias
> Am 01.06.2020 um 21:50 schrieb J. Landman Gay via use-livecode
> :
>
> Has anyone seen this problem? On an iOS build, normal LC controls sometimes
> do not respond to mouseUp events.
Has anyone seen this problem? On an iOS build, normal LC controls sometimes do not respond to
mouseUp events. There are no native controls involved -- the worst offender is a regular LC
graphic that serves as a login button. Sometimes it just doesn't trigger. Other times it's a
locked LC field
20 matches
Mail list logo
