Re: Stacks not removed from memory?
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. Which way is better? I'd say #1 is superior. That's my ideal too. Truly fixing it is much better than putting on a field dressing. BUT... (!) What's the caveat? New LC code is usually buggy and glitchy. Some issues are solved quickly, others take many years, or never. Thus, unfortunately "#1" versus "#2" might not a real choice. Actual choice, if quality is desired: "#2" versus "#1 PLUS #2." It shouldn't work that way, but unfortunately it has, so far. Anyway, good idea! I would be happy if LC does either. Just do it well. Besides the more obvious name conflict issues, we also have SE sometimes becoming dis-associated from the control whose script is being edited. That one is pretty fun to keep people on their toes while coding! Also, it's pretty crazy when standalone mishaps embed LC stacks in user stacks, and then the IDE makes it a little bit more difficult to remove the offending substacks due to the name conflicts. Similar: With certain project organization habits, it can add to the mayhem when name conflicts join the new messages-on Standalone Builder dance. Purge dialogs galore! Easy enough to work around, but a robust SB process that doesn't conflict with itself would be a big boost for LC. > 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. "This" habit? Which habit was that? (J/K) :) Thanks for promoting this solution. Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.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: Stacks not removed from memory?
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 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. I agree this should work but until it does, a workaround might be to use "the topstack" rather than "this stack". -- 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: Stacks not removed from memory?
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 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 ___ 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?
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
Re: Stacks not removed from memory?
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
Re: Really need In App Purchasing for macOS
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 Nethery via use-livecode > : > > 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?
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=22460 > > Kind regards > Bern > ___ ___ 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?
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 subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Stacks not removed from memory?
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 doesn't actually exist in the engine: https://quality.livecode.com/show_bug.cgi?id=1061 LOL. That bug report (still driving developers up the wall after 18 years) has my favorite team comment (#13): Re-assigning to engine team for future re-assignment. -- 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: Stacks not removed from memory?
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 > On May 14, 2021, at 10:05 AM, Richard Gaskin via use-livecode > wrote: > > 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, but I > > haven’t been able to come up with a reliable recipe. It’s a problem > > that I would like to nail down and squash. > > 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 doesn't > actually exist in the engine: > > https://quality.livecode.com/show_bug.cgi?id=1061 > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.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: Stacks not removed from memory?
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, but I > haven’t been able to come up with a reliable recipe. It’s a problem > that I would like to nail down and squash. 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 doesn't actually exist in the engine: https://quality.livecode.com/show_bug.cgi?id=1061 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Stacks not removed from memory?
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 the Save - Purge - Cancel dialog. I would report it, but I haven’t been able to come up with a reliable recipe. It’s a problem that I would like to nail down and squash. - Devin > On Apr 28, 2021, at 12:40 PM, Marty Knapp via use-livecode > wrote: > > Is anybody else experiencing with LC 9.6.2 rc5 that stacks with destroyStack > set to true are not always removed from memory when they're closed? It's been > happening to me in the IDE and standalones but not every time. And even when > I specifically go to another stack, set that stack to the defaultStack, that > any script with “of this stack” throws an error because it thinks "this > stack" it's the stack I just closed. > > 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 Devin Asay Director Office of Digital Humanities Brigham Young University ___ 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: Really need In App Purchasing for macOS
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 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.) 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. 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
Really need In App Purchasing for macOS
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
