Dismiss Keyboard on Mobile

[Sannyasin Brahmanathaswami via use-livecode]

I have a drop down search panel with radio buttons and a search field.

the search string field is grouped with the search icon (magnify glass icon)

this small group of two objects has  behavior attached. When the user hits the 
search icon, the string and readio buttons all form and run a dbase query.

Works fine on desktop

But on mobile the keyboard remains "stuck" and I have no way to dismiss it.
How do you give the user the option to be "done" with text entry

I have "select empty" in mouseup of the search behavior.  I thought this would 
get the cursor out of the field and cause the keyboard to go away and the 
mouseup Handler would proceed… but not go… I don't think the touch event even 
gets through as long as the cursor is still in the field and the keyboard is up…




___
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: AcceleratedRendering States When Opening and Closing Stacks

[Sannyasin Brahmanathaswami via use-livecode]

It's not set for "everything" only scrolling groups.

How can it be drawing too much? if there is only one scrolling group on the 
card and all other cards, stacks etc are closed or not in view, how does having 
the layermode set in an unopened stack start to "draw too much"

??



Jonathan Lynch wrote:

It seems like having the layermode set to scrolling for everything forces 
it to draw too much stuff. What happens if you only do one at a time?

Mark W would know more. But, I have found one at a time means it only gives 
extra power where it is needed.

___
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: AcceleratedRendering States When Opening and Closing Stacks

[Jonathan Lynch via use-livecode]

It seems like having the layermode set to scrolling for everything forces it to 
draw too much stuff. What happens if you only do one at a time?

Mark W would know more. But, I have found one at a time means it only gives 
extra power where it is needed.

Sent from my iPhone

> On Sep 29, 2017, at 9:11 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Jonathan:
> 
> The layermode of the scrolling groups is preset to "scrolling" 
> 
> The question is about the sequence as it relates to visual layer rendering
> 
> Open Stack A, turn on acceleratedRendering
> Open Stack B, which also turns on its "own" acceleratedRendering
> Close Stack A, *after* having open B "on top of Stack A
> 
> What are the issues, if any, with turning AcceleratedRendering On and off in 
> the above sequence, especially on Android. 
> 
> a) do we need a "super-nuanced" on and off with careful timing? Seems way too 
> difficult for any newbie unless we have very good documentation.
> 
> OR
> 
> b) is just this simple: 
> 
> acceleratedRendering only affects the visible stack on top and the engine, 
> the vRam/visible view that the user sees of the top stack is totally 
> unaffected by the state of the acceleratedRending of stack A above *during 
> and while* Stack B is opened and rendered on the device
> 
> the latter seems to be the case on iOS, on Android we are seeing a lot of 
> oddities. Debugging is virtually impossible since it works on iOS and 
> Desktop.. 
> 
> On Android, you can start throwing query dialogs.  after opening Stack B and 
> Closing Stack, you do
> 
> put the short name of the top stack into tTopStack
> 
> Answer tTopStack with "OK"
> 
> and you get "B" (the one just opened) but on screen we see Stack A (the one 
> just closed)
> 
> 
> 
> 
> 
> On 9/29/17, 11:34 AM, "use-livecode on behalf of Jonathan Lynch via 
> use-livecode"  use-livecode@lists.runrev.com> wrote:
> 
>Hi Swami,
> 
>I turn accelerated rendering on and off depending on which group the user 
> opens up. 
> 
>Are you setting the layermode of each group as you go?
> 
> ___
> 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: AcceleratedRendering States When Opening and Closing Stacks

[Sannyasin Brahmanathaswami via use-livecode]

Jonathan:

The layermode of the scrolling groups is preset to "scrolling" 

The question is about the sequence as it relates to visual layer rendering

Open Stack A, turn on acceleratedRendering
Open Stack B, which also turns on its "own" acceleratedRendering
Close Stack A, *after* having open B "on top of Stack A
 
What are the issues, if any, with turning AcceleratedRendering On and off in 
the above sequence, especially on Android. 

a) do we need a "super-nuanced" on and off with careful timing? Seems way too 
difficult for any newbie unless we have very good documentation.

OR

b) is just this simple: 

acceleratedRendering only affects the visible stack on top and the engine, the 
vRam/visible view that the user sees of the top stack is totally unaffected by 
the state of the acceleratedRending of stack A above *during and while* Stack B 
is opened and rendered on the device

the latter seems to be the case on iOS, on Android we are seeing a lot of 
oddities. Debugging is virtually impossible since it works on iOS and Desktop.. 

On Android, you can start throwing query dialogs.  after opening Stack B and 
Closing Stack, you do

put the short name of the top stack into tTopStack

Answer tTopStack with "OK"

and you get "B" (the one just opened) but on screen we see Stack A (the one 
just closed)



 

On 9/29/17, 11:34 AM, "use-livecode on behalf of Jonathan Lynch via 
use-livecode"  wrote:

Hi Swami,

I turn accelerated rendering on and off depending on which group the user 
opens up. 

Are you setting the layermode of each group as you go?

___
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: AcceleratedRendering States When Opening and Closing Stacks

[Jonathan Lynch via use-livecode]

Hi Swami,

I turn accelerated rendering on and off depending on which group the user opens 
up. 

Are you setting the layermode of each group as you go?

Sent from my iPhone

> On Sep 29, 2017, at 1:41 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> We continue struggle with our app on Android and between mobile controls 
> being instantiated or deleted + oddities with acceleratedRendering, + remote 
> bugging not *really* working, it's a bit of a fishing expedition when 
> everything works on desktop and iOS.
> 
> A complete document on accelerated rendering, what it does, impact on the 
> engine, optimal usage etc would be useful. Right now my best option is to 
> look for "acceleratedRendering" Mark Waddington in this list. Maybe we should 
> compile all his replies and submit as a guide addition.
> 
> if your goal is to just improve the performance of mobile scrolling fields 
> and groups, and all cards in stack will have one of both or both of these… 
> then it makes sense to turn on acceleratedRendering in the preopenstack 
> handler… or course there are bugs there and work arounds, wait 200 seconds, 
> Panos "fixIt" … the fact that LC on Android will crash if you go home or app 
> switcher and the acceleratedRendering is on.
> 
> Setting all the above aside, assuming we implement the necessary 
> "hackarounds" questions today are
> 
> 1) Do we need to do this
> 
> on closeStack
> set the acceleratedRendering of this stack to false
> end close stack
> 
> or if you close the stack are all the mysterious overheads "costs" of 
> acceleratedRendering for that stack "wiped" from the engines brain, whether 
> you turn it off or no, with no residual impact on the rendering of views?
> 
> 2) assuming you do run that at close stack…if you open a stack B *before* 
> closing the stack A which has acceleratedRendering set to true   is there a 
> cost in terms of the engine ability to render everything in the newly opened 
> stack, remember we have not closed stack A yes. but stack B is now open "on 
> top"
> 
> OK simple version then is: what is best practice for this scenario
> 
> 1) stack "apples" is open, with acceleratedRendering set to true
> 2) we open stack "oranges" and set the acceleratedRendering of stack this 
> stack (now "oranges") to true
> 3) we close stack "apples"
> 
> how is this best handled, given that we see no problems with this in iOS?
> 
> Brahmanathaswami
> 
> 
> 
> ___
> 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

AcceleratedRendering States When Opening and Closing Stacks

[Sannyasin Brahmanathaswami via use-livecode]

We continue struggle with our app on Android and between mobile controls being 
instantiated or deleted + oddities with acceleratedRendering, + remote bugging 
not *really* working, it's a bit of a fishing expedition when everything works 
on desktop and iOS.

A complete document on accelerated rendering, what it does, impact on the 
engine, optimal usage etc would be useful. Right now my best option is to look 
for "acceleratedRendering" Mark Waddington in this list. Maybe we should 
compile all his replies and submit as a guide addition.

if your goal is to just improve the performance of mobile scrolling fields and 
groups, and all cards in stack will have one of both or both of these… then it 
makes sense to turn on acceleratedRendering in the preopenstack handler… or 
course there are bugs there and work arounds, wait 200 seconds, Panos "fixIt" … 
the fact that LC on Android will crash if you go home or app switcher and the 
acceleratedRendering is on.

Setting all the above aside, assuming we implement the necessary "hackarounds" 
questions today are

1) Do we need to do this

on closeStack
set the acceleratedRendering of this stack to false
end close stack

or if you close the stack are all the mysterious overheads "costs" of 
acceleratedRendering for that stack "wiped" from the engines brain, whether you 
turn it off or no, with no residual impact on the rendering of views?

2) assuming you do run that at close stack…if you open a stack B *before* 
closing the stack A which has acceleratedRendering set to true   is there a 
cost in terms of the engine ability to render everything in the newly opened 
stack, remember we have not closed stack A yes. but stack B is now open "on top"

OK simple version then is: what is best practice for this scenario

1) stack "apples" is open, with acceleratedRendering set to true
2) we open stack "oranges" and set the acceleratedRendering of stack this stack 
(now "oranges") to true
3) we close stack "apples"

how is this best handled, given that we see no problems with this in iOS?

Brahmanathaswami



___
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: IPad Mini reports "not supported

[Sannyasin Brahmanathaswami via use-livecode]

Surprise, at least this is new news for some of us: assuming the device 
supports one or another, all those services are indeed actually available, 
whether you check those boxes or not or so I'm told via another grapevine. 

ergo: you only want to check them in the SA builder if your app really, really 
MUST have those functions. So you are making an "up down" decision that you so 
not what your app installed on any device that will not support those functions.

So for example, if you think it's good that the user can use a flash when they 
take a photo, but not mission critical to your app's functionality… then, well, 
that's already included on those devices that have a flash = do nothing in the 
SA builder… if they put your app on an iPad that does not have advanced camera 
features, they just don’t a flash. 

GPS and some other mobile features will be trickier.  let's say have, as we do, 
an app that can do all kinds of "tricks" you do want the users to be able to 
install on any device, but you do also need to find out what capabilities there 
are, so …  this means a bit more preopenstack 'forensics" on the device … so I 
headed off the dictionary…so, there are tools for this job:  

mobileCanTrackLocation

oddly for some reason, even though GPS I in the summary, a search for "GPS" in 
tinyDictionary did not return this entry… on a hunch, I searchedLocation and 
then scanned for the mobile commands and found it.


 

On 9/28/17, 9:20 AM, "use-livecode on behalf of Ralph DiMola via use-livecode" 
 wrote:

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.

___
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: Remote debugging - expected behavior

[J. Landman Gay via use-livecode]

Oh right. I should have thought of that.

On September 29, 2017 7:20:29 AM Trevor DeVore via use-livecode 
 wrote:



What I do is type the word “breakpoint” in script only stacks.

Trevor DeVore
ScreenSteps


--
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: MacOS 10.13 crashes LC after color dialog

[hh via use-livecode]

> > Reported, of course, #20490. 
> Fixed, of course, https://github.com/livecode/livecode/pull/6012.

-:))

___
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: A modest proposal for a new property

[hh via use-livecode]

@Quentin L.

Hopefully the following citation can help all of us to understand
better what's going on. Especially point (1) relates to our current
discussion:

Posted by Mark Waddingham in a long thread (2015) in the LC Builder
forum, not hard to find. It still describes at about the current state.

"Okay so there are two things here... How things work at the moment (1)
and how I propose things should evolve (2).

The code you write in LCB (let's call it the 'widget implementation') 
sits at the same level as the C++ code in the engine which controls 
the 'legacy' controls. There's a C++ wrapper control in the engine 
(MCWidget) which provides a host environment for the LCB code. It 
manipulates and marshals various parts of the event stream and other 
aspects of the engine to give a reasonably 'clean' set of events 
which the widget implementation sees. From the high-level perspective 
you have a widget object on which you can set a script (let's call 
this the 'script object'). You can think of it as the script object 
being the realization of a widget implementation in the LiveCode 
environment.

(1) At the moment widget implementations are entirely responsible for 
dispatching all messages to their script object. This means that if a 
widget implementation does not react to, or post the mouse event 
messages, the script object will not see them. This mirrors how the 
legacy controls are written in the engine - they, for the most part, 
individually control what event messages are sent to the script 
objects and when.

(2) My proposal is to change this slightly to ensure there is a 
reasonable level of 'default behavior' in widgets, generalizing and 
improving the current (although not entirely consistent) default 
behavior amongst the existing legacy controls. Using a mouse click as 
an example, here is my current suggestion of how it would work:

The engine receives a mouseDown event on a widget.
A mouseDown message is sent to the script object of the widget.
If the mouseDown message is handled (and not passed) then the script 
object will have been considered to have 'grabbed' the mouse click 
gesture and will then receive the mouseUp / mouseRelease message at 
some later date - the widget implementation will not see the 
OnMouseDown event or the subsequent OnMouseUp.
If, on the other hand, the mouseDown message is not handled then the 
widget will receive the OnMouseDown event and subsequently the 
OnMouseUp event. In this case script would still receive the 
mouseUp / mouseRelease message *after* the widget has processed the 
OnMouseUp event - this is to ensure that (just like widgets) the 
script object always gets matched pairs of mouseDown / mouseUp.

With this logic, the script of a widget can choose to 'block' the 
widget implementation from processing the mouse click gesture but if 
it chooses not to then the widget will handle it.

For the other mouse events, such as mouseEnter / mouseLeave / 
mouseMove then they are just notifications so script and the widget 
will get the events to process.

This logic should mean that any widget which does not handle mouse 
click events will still allow the script object to handle them 
(without any additional work); and widgets that do handle mouse click 
events still generate the script messages which you might expect.

Let's take an example of a push button widget. I'm imagining here 
that the push button widget will dispatch a 'clicked' message to 
script when a mouseUp event is received within its bounds. The order 
of events would be as follows:

In the case the script object passes (or does not handle) the 
mouseDown event:
mouseDown to script object
OnMouseDown to widget
...
OnMouseUp to widget
clicked to script object
mouseUp to script object

In the case the script object handles (and does not pass) the 
mouseDown event:
mouseDown to script object
...
mouseUp to script object

This hopefully gives the best of both worlds - script can control 
whether widgets handle the mouse gestures, and still get notification 
about significant points in the gesture; whilst widgets are 
guaranteed to get a mouse gesture to process in entirety (if script 
decides it should be so) and thus an opportunity to reinterpret the 
gesture as a higher-level event (such as clicked, or 'barClicked' in 
the example of a graphing widget as suggested by Trevor)."

___
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: MacOS 10.13 crashes LC after color dialog

[Mark Waddingham via use-livecode]

On 2017-09-29 16:15, hh via use-livecode wrote:

Reported, of course, #20490.


Fixed, of course, https://github.com/livecode/livecode/pull/6012.

This patch will be back-ported to 8.1.6 as 8.1.6-gm-3 - this will appear 
as soon as we can get it built and uploaded - it will appear in the auto 
updater when it is done. (The build number will be 14034).


It will next appear in 8.1.7-rc-2 (which currently has an ETA of Monday 
all being well), then subsequently in 8.2.0-dp-2 and 9.0.0-dp-10.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: A modest proposal for a new property

[Quentin Long via use-livecode]

sez hh :
> > > JLG wrote:
> > > The original issue that influenced this one was how to provide a
> > > larger hit zone on an SVG widget.
> > > How would this property work for that?
> 
> > Quentin L. wrote:
> > I?m thinking that a single line of code would suffice:
> >
> > set the clickableRegion of widget ?Fred? to ListOfPoints
> >
> > As i?ve noted previously, the engine *already* handles clickable
> > regions for *every* control ... 
> 
> No. Sadly (or luckily, depending on one's point of view) a widget is
> not an ordinary control. This has to be implemented in the widget.
Hold it. I don't--can't--believe that the engine *does not* take care of 
deciding when a given mouse-click does or doesn't land on a widget. Unless 
you're saying that the mouse-click might trigger *either* the widget itself, 
*or* the widget's script, depending on exactly what location the mouse-click is 
at?

> To see this write one that handles only the mouse events, not to
> speak of a clickable region.
> Even this is hard to control: who gets first which mouseEvent, the
> widget's script or the widget.
I don't see what difference it makes whether a mouse-click causes mouse events 
to be sent to the *widget proper*, or, instead, to the *widget's script*. 
Either way, *something* has to determine whether the dingus is triggered by a 
mouse-click at an arbitrary screen location, right? And if it's not the engine 
which does that… what *is* doing that?

   
"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"

Read the webcomic at [ http://www.atarmslength.net ]!

If you like "At Arm's Length", support it at [ 
http://www.patreon.com/DarkwingDude ].

___
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: MacOS 10.13 crashes LC after color dialog

[hh via use-livecode]

Reported, of course, #20490.

___
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: MacOS 10.13 crashes LC after color dialog

[Trevor DeVore via use-livecode]

On Fri, Sep 29, 2017 at 12:11 AM, hh via use-livecode <
use-livecode@lists.runrev.com> 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 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 repair this soon.
>

I see the same crash. Is there a bug report filed for this?

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: Remote debugging - expected behavior

[Mike Kerner via use-livecode]

Even when I use breakpoint, I'm having issues with remote debugging, which
is QR...something.

On Fri, Sep 29, 2017 at 8:18 AM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Fri, Sep 29, 2017 at 12:56 AM J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > 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 <
> > use-livecode@lists.runrev.com> 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.
> > >
> > > Hmm… the issue here is script only stacks will not retain breakpoints
> as
> > they are stored in custom properties. I guess this is something that
> needs
> > some thought in general as the breakpoints should be retained between
> > sessions in the IDE too.
> >
> > Makes sense. I could have used it today, this app has virtually no
> > scripts anywhere in any stacks, but has dozens of script-only stacks
> > used as libraries and behaviors. That's where the breakpoints had to be.
> >
> > With the introduction of the Levure framework, more people will be using
> > this method now too.
>
>
> What I do is type the word “breakpoint” in script only stacks.
>
> Trevor DeVore
> ScreenSteps
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Remote debugging - expected behavior

[Trevor DeVore via use-livecode]

On Fri, Sep 29, 2017 at 12:56 AM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 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 <
> use-livecode@lists.runrev.com> 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.
> >
> > Hmm… the issue here is script only stacks will not retain breakpoints as
> they are stored in custom properties. I guess this is something that needs
> some thought in general as the breakpoints should be retained between
> sessions in the IDE too.
>
> Makes sense. I could have used it today, this app has virtually no
> scripts anywhere in any stacks, but has dozens of script-only stacks
> used as libraries and behaviors. That's where the breakpoints had to be.
>
> With the introduction of the Levure framework, more people will be using
> this method now too.


What I do is type the word “breakpoint” in script only stacks.

Trevor DeVore
ScreenSteps
___
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: MacOS 10.13 crashes LC after color dialog

[hh via use-livecode]

Yes. Probably such bugs as the color picker issue are the reason
for not offering the upgrade via the built-in AppStore updater?

Though it is possible to work around: The GraphicConverter upgraded
yesterday, it has a working color picker.

___
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: MacOS 10.13 crashes LC after color dialog

[panagiotis merakos via use-livecode]

Oops :)

Hmm that's strange, my Mac running 10.12.6 does not offer me to upgrade to
10.13 when I "Check for updates".

Anyway, I will upgrade using your link.

So it looks like the color picker issue is something *we* have to address.

Best regards,
Panos
--

On Fri, Sep 29, 2017 at 9:34 AM, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Panos wrote:
> > MacOS 10.13 is still in beta
>
> No. Official version since Sept 25, 2017.
> https://www.apple.com/macos/high-sierra/
>
> ___
> 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: MacOS 10.13 crashes LC after color dialog

[hh via use-livecode]

> Panos wrote:
> MacOS 10.13 is still in beta

No. Official version since Sept 25, 2017.
https://www.apple.com/macos/high-sierra/

___
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: MacOS 10.13 crashes LC after color dialog

[panagiotis merakos via use-livecode]

Hi all,

MacOS 10.13 is still in beta, and several other apps have problems with the
system color picker:

https://www.reddit.com/r/MacOS/comments/6mu94y/anyone_else_noticed_that_on_high_sierra_using_the/
https://vimeo.com/234359128

I am not sure if this is something that Apple plans to fix, or something
that we (LiveCode) and all the other affected apps have to patch.

Best,
Panos
--

PS: @Hermann thanks for the bug report

On Fri, Sep 29, 2017 at 6:31 AM, Tore Nilsen via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 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 <
> use-livecode@lists.runrev.com>:
> >
> > Yup, same for me on Macbook Pro Retina.
> >
> > Roger
> >
> >> On Sep 28, 2017, at 10:11 PM, hh via use-livecode <
> use-livecode@lists.runrev.com> 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 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 repair this soon.
> >>
> >>
> >>
> >> ___
> >> 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