Re: Really need In App Purchasing for macOS

[kee nethery via use-livecode]

> On May 14, 2021, at 9:32 AM, Rick Harrison via use-livecode 
>  wrote:
> 
> 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.

https://developer.apple.com/in-app-purchase/
“… Users can make in‑app purchases on iOS, iPadOS, macOS, watchOS, and tvOS. …"

> To implement what you want, you would probably have to add a link to your 
> website in your Mac App.
> At your website you can offer the user a chance to upgrade to another version 
> of your app.
> (Of course Apple may not like this because at this point you might be cutting 
> them out of the equation
> and it might violate your terms with Apple.  You will have to research that.)

My understanding is that for a free downloaded app from the app store that has 
in-app purchasing, they want to manage that process and collect their cut.

> 
> You may even just refer them to another Mac App on the Apple Store which 
> would not violate anything
> in your terms because Apple will still be able to take their cut.
> 
> The old strategy was to give the users a cheap or free version of your 
> product, and then provide a link
> to the Pro-version or SuperPro or Ultra-Pro version of your software with 
> more capability each time.

I’ll ponder two versions. Crippled / free, and Pro / costing money. I currently 
deploy the “pro / costing money” version. Want to have a free version that 
demonstrates what it does as a teaser. 

Thanks,
kee

> 
> Please let us know how you solve your problem, and what extra success you had 
> with the strategy.
> 
> Good luck!
> 
> Rick
> 
> 
>> On May 14, 2021, at 11:27 AM, Kee Nethery via use-livecode 
>>  wrote:
>> 
>> 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@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: Stacks not removed from memory?

[J. Landman Gay via use-livecode]

On 5/15/21 9:56 AM, Bob Sneidar via use-livecode wrote:

I agree that when a handler refers to this stack, it should ALWAYS refer to the 
stack the script object belongs to.


That would be a catasrophe when the handler is in a library or a backscript. I use "this stack" 
in those. It would be good to get some guidance though on how the engine determines which stack 
is "this stack." I don't usually have a problem with it, but once in a while it fools me.


--
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: LC puts stuff in the trash upon quit!

[matthias rebbe via use-livecode]

There is a bug report for this already

https://quality.livecode.com/show_bug.cgi?id=21233



> Am 15.05.2021 um 15:46 schrieb Rick Harrison via use-livecode 
> :
> 
> I have noticed this oddity for a long time.
> No other program that I own does this.
> 
> Why is LC so dirty?
> 
> Rick
> 
> ___
> 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: LC puts stuff in the trash upon quit!

[Klaus major-k via use-livecode]

Hi Rick,

> Am 15.05.2021 um 15:46 schrieb Rick Harrison via use-livecode 
> :
> 
> I have noticed this oddity for a long time.
> No other program that I own does this.

this is a known bug:


> Why is LC so dirty?

Must have to do with cheese...

> Rick

Best

Klaus

--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
kl...@major-k.de


___
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: LC puts stuff in the trash upon quit!

[Richmond via use-livecode]

On which operating system is this?

I have not noticed it on MacOS or Xubuntu Linux.

Richmond.

On 15.05.21 16:46, Rick Harrison via use-livecode wrote:

I have noticed this oddity for a long time.
No other program that I own does this.

Why is LC so dirty?

Rick

___
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: Stacks not removed from memory?

[Bob Sneidar via use-livecode]

This issue is so pervasive that I ended up converting all of my relative 
references to absolute ones. I wrote two handlers, getParentCard and 
getParentStack, so when I need absolute references I put getParentCard() into 
tParentCard and then use of tParentCard after any object I need to absolutely 
reference. I NEVER use this stack anymore. 

I agree that when a handler refers to this stack, it should ALWAYS refer to the 
stack the script object belongs to. 

Bob S


> On May 14, 2021, at 12: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 going to stack "XYZ" and setting it as the defaultStack, one 
> would expect "this stack" to be be "XYZ" but it is not.
> 
> As mentioned I am now querying revLoadedStacks and manually deleting from 
> memory the preference stack and that seems to have taken care of it. But it 
> makes me nervous that the same issue may unexpectedly arise elsewhere in my 
> code. This is an app that has been working fine for years and this has not 
> been an issue till now.
> 
> Marty
> 
>> On May 14, 2021, at 12:35 PM, Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> 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?
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> 
>> 
>>> 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 my main stack "XYZ" I do something like:
>>> put tPref into fld "123" of this stack
>>> This worked fine for me for years. In LC 9.6.2 rc 5, it would fail most of 
>>> the time. Curious, I inserted code to find out what LC thought was "this 
>>> stack" only to discover that *sometimes* it's the preference stack that I 
>>> just closed.
>>> Then after closing the preference stack, I tried "go stack "XYZ" and "set 
>>> the default stack to "XYZ" But "this stack" would still (most of the time) 
>>> report my supposedly closed preference stack.
>>> So now I'm having to query for revLoadedStacks and if my preference stack 
>>> is listed then I delete it from memory.
>>> I did file a bug report (#23194 ) but as it does not always happen I have 
>>> not provided a test stack.
>>> Marty
>> 
> 
> 
> ___
> 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

LC puts stuff in the trash upon quit!

[Rick Harrison via use-livecode]

I have noticed this oddity for a long time.
No other program that I own does this.

Why is LC so dirty?

Rick

___
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