Re: IAP in App Store

2021-09-19 Thread Curry Kenworthy via use-livecode



Jacqueline:

> If the third param is omitted, the script compiles okay
> but apparently aborts with no error message
> and no information when the app runs on the device.

Hey LC Team: This may be not merely a bug,
but also a "bad habit" in coding practice.
A habit that leads to multiple bugs.

I've seen similar "aborts" that halt execution
but otherwise fail without warning or info.

The LCS equivalent would be a tendency
to overuse "exit to top" in situations
where a "return" or an error bailout
would be more appropriate.

Perhaps only intended as a temporary placeholder
and forgotten, but either way, a better habit
would reduce the number of future bugs/glitches
that follow this pattern. Thanks

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: IAP in App Store

2021-09-19 Thread J. Landman Gay via use-livecode
Even a note in the documentation would help. I spent two weeks trying to 
figure out the problem. Was it my store setup? The iPhone? My script, which 
was based on the lesson example? Did I set up my store products wrong? Just 
where should I look?


By the time I posted here I was a walking mass of frustration and my 
husband knew to hide in a closet.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On September 19, 2021 2:24:18 AM Curry Kenworthy via use-livecode 
 wrote:



Jacqueline:

> If the third param is omitted, the script compiles okay
> but apparently aborts with no error message
> and no information when the app runs on the device.

Hey LC Team: This may be not merely a bug,
but also a "bad habit" in coding practice.
A habit that leads to multiple bugs.

I've seen similar "aborts" that halt execution
but otherwise fail without warning or info.

The LCS equivalent would be a tendency
to overuse "exit to top" in situations
where a "return" or an error bailout
would be more appropriate.

Perhaps only intended as a temporary placeholder
and forgotten, but either way, a better habit
would reduce the number of future bugs/glitches
that follow this pattern. Thanks

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





___
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 IDE Menu suddenly is slow / responds slowly

2021-09-19 Thread Tom Glod via use-livecode
Things seem better when the message window is closed . I also disabled
all the script autocompletion options.
So its one or more of those things.  Will test more later.



On Fri, Sep 17, 2021 at 1:37 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Have you checked the pendingMessages? A while ago Swami posted a slowdown
> that showed dozens and dozens of repeating IDE messages.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On September 17, 2021 3:28:12 AM matthias rebbe via use-livecode
>  wrote:
>
> > Hi,
> >
> > i am currently noticing a massive slow down of the LC 9.6.4 IDE menu.
> Not
> > right away after opening Livecode IDE, but after some time of usage.
> > I never noticed that in 9.6.3. Clicking on an main menu entry takes then
> > about 2 or 3 seconds until i can see the submenu
> >
> > But I am not sure if this is really only an LC problem or due to the
> fact
> > that i upgraded to Big Sur around the same time as LC 9.6.4 was released.
> >
> > Currently i only notice this slow down of the menu in 9.6.4 and i am not
> > able to see this in 9.6.3. But maybe i am a little bit to impatient and
> my
> > testing is too short.
> >
> > In the activity monitor i cannot see anything unusual. Now large memory
> > consumption of LC and no high CPU usage.
> >
> > After a restart of LC the IDE menu behaves normal, but some time later
> it
> > slows down.
> >
> >
> > Is anyone else experiencing the same or a similar behavior?
> >
> >
> > Regards,
> >
> > Matthias
> >
> >
> >
> >
> > ___
> > 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
>


-- 
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Mobile:647.562.9411
___
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: Android SDK lesson

2021-09-19 Thread Bernard Devlin via use-livecode
Hi Lagi

I'd suggest following the Lesson as the most straightforward route.  Let us
know if that doesn't work.

Regards, Bernard

On Sat, Sep 18, 2021 at 8:17 PM Lagi Pittas via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> I will look for a thread by you and expect that it should be the latest
> unless you say otherwise - you didn't say if it works on the latest yet
> though - which version of indy should I use?
>
> Regards Lagi
>
>
>
___
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


How to suppress the Modal Purge dialog? -- Name space conflict

2021-09-19 Thread R.H. via use-livecode
Hi everyone

I have a need to programmatically open about 200 stacks, do something, and
the close them. In this case, for documentation reasons, I take a
screenshot from every stack, every card, and every substack and their cards
to export it.

My problem is that there are number of stacks that have the same stack name
(apart from a different file name), and loading them into memory (opening
them) sometimes creates a naming conflict if a stack with the same name
already is loaded -- and these are library stacks, etc.

The known modal dialog appears to allow to purge such stack. This dialog
seems to appear before even any error message could be intercepted.

Can this purging be automated and the dialog be suppressed? I found no way
(using the "try" construct, locking messages, etc.) to suppress this dialog
and just do the purge from script.

I assume that it could eventually be done messing with the strack in the
IDE that generates the dialog. But I do not really want to do this for
principle reasons.

Another way is to make sure that there are never same stack names (which
are only known after opening), but that is almost impossible to control and
might break certain stack relationships -- and I am not just talking about
my own stacks, but also stacks from third parties, and opens sources.

Of course, I can make sure that there are is never more than the main stack
in memory before opening any other stack -- except the IDE stacks. But in
my special case this is not a good solution as the app relies heavily on a
number of open stacks. At least, I am still trying to find a better
solution.

Maybe a good feature for future would be to support name spaces as in other
development environments so that such naming conflicts may be avoided.
Stacks and other resources could then share a name space, and then there is
only the need to have unique names within such name space. Some people
(including myself) already mimic this using prefixes to a name. But that is
just a starting point and difficult to control. The concept of name spaces
goes beyond that.

Any ideas ? )))

have fun...
Roland
___
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: How to suppress the Modal Purge dialog? -- Name space conflict

2021-09-19 Thread Tom Glod via use-livecode
Hmmm...first thing that comes to mind.

Can you check if the same name is already open and then rename the existing
one before you try to open the second one?



On Sun, Sep 19, 2021 at 5:54 PM R.H. via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi everyone
>
> I have a need to programmatically open about 200 stacks, do something, and
> the close them. In this case, for documentation reasons, I take a
> screenshot from every stack, every card, and every substack and their cards
> to export it.
>
> My problem is that there are number of stacks that have the same stack name
> (apart from a different file name), and loading them into memory (opening
> them) sometimes creates a naming conflict if a stack with the same name
> already is loaded -- and these are library stacks, etc.
>
> The known modal dialog appears to allow to purge such stack. This dialog
> seems to appear before even any error message could be intercepted.
>
> Can this purging be automated and the dialog be suppressed? I found no way
> (using the "try" construct, locking messages, etc.) to suppress this dialog
> and just do the purge from script.
>
> I assume that it could eventually be done messing with the strack in the
> IDE that generates the dialog. But I do not really want to do this for
> principle reasons.
>
> Another way is to make sure that there are never same stack names (which
> are only known after opening), but that is almost impossible to control and
> might break certain stack relationships -- and I am not just talking about
> my own stacks, but also stacks from third parties, and opens sources.
>
> Of course, I can make sure that there are is never more than the main stack
> in memory before opening any other stack -- except the IDE stacks. But in
> my special case this is not a good solution as the app relies heavily on a
> number of open stacks. At least, I am still trying to find a better
> solution.
>
> Maybe a good feature for future would be to support name spaces as in other
> development environments so that such naming conflicts may be avoided.
> Stacks and other resources could then share a name space, and then there is
> only the need to have unique names within such name space. Some people
> (including myself) already mimic this using prefixes to a name. But that is
> just a starting point and difficult to control. The concept of name spaces
> goes beyond that.
>
> Any ideas ? )))
>
> have fun...
> Roland
> ___
> 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
>


-- 
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Mobile:647.562.9411
___
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: How to suppress the Modal Purge dialog? -- Name space conflict

2021-09-19 Thread Tom Glod via use-livecode
Sorry, right you mentioned that in one of the paragraphs. but there is
a way to get all the stacks opened... but making sure that before a
stack is processed, the name is returned to what it must be to be exported
and work.

Just making the assumption that you can only process one open stack at a
time.

Or are the stacks all running code outside of being "opened"?


On Sun, Sep 19, 2021 at 6:12 PM Tom Glod  wrote:

> Hmmm...first thing that comes to mind.
>
> Can you check if the same name is already open and then rename the
> existing one before you try to open the second one?
>
>
>
> On Sun, Sep 19, 2021 at 5:54 PM R.H. via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Hi everyone
>>
>> I have a need to programmatically open about 200 stacks, do something, and
>> the close them. In this case, for documentation reasons, I take a
>> screenshot from every stack, every card, and every substack and their
>> cards
>> to export it.
>>
>> My problem is that there are number of stacks that have the same stack
>> name
>> (apart from a different file name), and loading them into memory (opening
>> them) sometimes creates a naming conflict if a stack with the same name
>> already is loaded -- and these are library stacks, etc.
>>
>> The known modal dialog appears to allow to purge such stack. This dialog
>> seems to appear before even any error message could be intercepted.
>>
>> Can this purging be automated and the dialog be suppressed? I found no way
>> (using the "try" construct, locking messages, etc.) to suppress this
>> dialog
>> and just do the purge from script.
>>
>> I assume that it could eventually be done messing with the strack in the
>> IDE that generates the dialog. But I do not really want to do this for
>> principle reasons.
>>
>> Another way is to make sure that there are never same stack names (which
>> are only known after opening), but that is almost impossible to control
>> and
>> might break certain stack relationships -- and I am not just talking about
>> my own stacks, but also stacks from third parties, and opens sources.
>>
>> Of course, I can make sure that there are is never more than the main
>> stack
>> in memory before opening any other stack -- except the IDE stacks. But in
>> my special case this is not a good solution as the app relies heavily on a
>> number of open stacks. At least, I am still trying to find a better
>> solution.
>>
>> Maybe a good feature for future would be to support name spaces as in
>> other
>> development environments so that such naming conflicts may be avoided.
>> Stacks and other resources could then share a name space, and then there
>> is
>> only the need to have unique names within such name space. Some people
>> (including myself) already mimic this using prefixes to a name. But that
>> is
>> just a starting point and difficult to control. The concept of name spaces
>> goes beyond that.
>>
>> Any ideas ? )))
>>
>> have fun...
>> Roland
>> ___
>> 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
>>
>
>
> --
> Tom Glod
> Founder & Developer
> MakeShyft R.D.A (www.makeshyft.com)
> Mobile:647.562.9411
>


-- 
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Mobile:647.562.9411
___
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