Richard:
> Because if it's just the stack name conflict thang,
> I'd rather we solve that at the root by being done
> with that IDE-imposed limitation
Yes, good idea. I would be happy if LC either:
1. Solves it at the root, per RG suggestion.
2. Fixes what they already have, in the IDE.
Whic
On 5/14/21 2:49 PM, Marty Knapp via use-livecode wrote:
When you close a stack that has its destroyStack set to true, it should not remain in memory. In my case it
also seems to get stuck as the default stack. Even if my preference stack did not remove from memory as it
should, specifically goi
Thanks.
So many things can legitimately change the value of "this" I generally
prefer more explicit references.
Maybe with this apparent bug there's one more reason I'm grateful to
have adopted this habit.
--
Richard Gaskin
Fourth World Systems
When you close a stack that has its destr
When you close a stack that has its destroyStack set to true, it should not
remain in memory. In my case it also seems to get stuck as the default stack.
Even if my preference stack did not remove from memory as it should,
specifically going to stack "XYZ" and setting it as the defaultStack, one
Thanks, Marty.
I used to use stacks for preferences, but I found arrays to be simpler
in addition to being slightly faster.
But it seems the core of your issue isn't so much about LC's cache
management as with object referencing with "this" - do I understand the
issue correctly?
--
Richar
As LC currently does not support In App Purchase for macOS, why not offering a
free "lite" version and a "pro" version that can be purchased.
Instead of an In App Purchase option in the free version you could link to the
pro version in the app store.
> Am 14.05.2021 um 17:27 schrieb Kee Nethe
It’s happening for me in standalone. And I should mention that my tests were on
Mac only (Mojave).
Marty
> On May 14, 2021, at 10:59 AM, Niggemann, Bernd via use-livecode
> wrote:
>
> If the Project Browser is open then it may be related to
>
> https://quality.livecode.com/show_bug.cgi?id=22
If the Project Browser is open then it may be related to
https://quality.livecode.com/show_bug.cgi?id=22460
Kind regards
Bern
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your sub
On 5/14/21 10:05 AM, Richard Gaskin via use-livecode wrote:
Is this to avoid stack name conflicts, or is there some other reason to
use this feature?
Because if it's just the stack name conflict thang, I'd rather we solve
that at the root by being done with that IDE-imposed limitation that
d
In my case it's not a name conflict. Lets say I have a main stack "XYZ" and
then I query a separate Preference stack:
put the cpCustomProperty of stack "full_path_to_pref_stack" into tPref
close stack "pref_stack"
(my preference stack has destroyStack set to true)
Now thinking that I'm back in
Devin Asay wrote:
> I have seen what you’re describing on all of the recent releases—9.5 -
> 9.6.x; i.e., a stack with destroyStack set to true, then closed, is
> not always removed from memory. Sometimes this has caused an infinite
> loop with the Save - Purge - Cancel dialog. I would report it,
Marty,
I had intended to respond to this, but got busy with other things.
I have seen what you’re describing on all of the recent releases—9.5 - 9.6.x;
i.e., a stack with destroyStack set to true, then closed, is not always removed
from memory. Sometimes this has caused an infinite loop with t
Hi Kee,
IAP in the Apple World only applies to iOS apps in their environment for now as
I understand it.
That may change in the future as Apple starts making iOS Apps available for
macOS.
To implement what you want, you would probably have to add a link to your
website in your Mac App.
At your
Any suggestions? Each month my app gets 800+ views on the App Store and 1
purchase. With IAP I could convert so many more into paying customers. Any
suggestions on how to add IAP to a Mac app?
Kee Nethery
___
use-livecode mailing list
use-livecode@lis
14 matches
Mail list logo
