date:20211007


Curry Kenworthy wrote:

> (I never have, and never will,
> quote the entire post. Misguided trend.)

I edit down to the relevant portions, so people have the opportunity to 
know what I'm replying to.


--
 Richard Gaskin
 Fourth World Systems

___
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: Stack with the same name loop

Thank you for confirming that the engine does not throw an error when 
encountering stacks of the same name.

At the heart of the issue seems to be a difference in how short stack 
names are resolved vs things like topstack.

Though related to the duplicate stack name issue, the core underlying 
cause is a separate item logged here:

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

If brought into parity with so many of the functions we safely rely on 
like topstack (instead of the load order that's been there since the old 
MC days), so much IDE code and our workflows could become simplified.

Your notes in Comment 9 in that report are especially helpful.  Thanks 
for the recon.

--
 Richard Gaskin
 Fourth World Systems

Brian Milby wrote:

Yes, but it does not add anything else.  If you do it two times you end up with 
2 identically named stacks.  You can save them to disk with different long 
names and end up with multiple stacks with the same short name but different 
long name.  My demo is on bug 18793.  It works in the IDE.

Sent from my iPhone

On Oct 7, 2021, at 1:58 PM, Richard Gaskin via use-livecode  wrote:

Brian Milby wrote:

> Clone stack avoids the check.  It is not that hard to get
> multiple stacks with the same short name but different
> long names in memory (in a standalone).

Clone alters the name of the new clone stack.  The engine prepends it with "Copy of 
".

AFAIK it's done that since 1998.

FWIW I did some extensive research on duplicate stack names issues about four 
years ago, attempting to pin down how the engine behaves and what the IDE does.
https://quality.livecode.com/show_bug.cgi?id=1061#c20

TL/DR: The engine has no problem with duplicate short stack names, but some IDE 
needs will be compromised until there is an adjustment to how the engine 
internally resolves short stack name references;

Currently the old MC implementation remains in place in which those are 
resolved by load order (which is almost never what any scripter needs), but 
more useful would be layer/message path order (which is what most scripts and 
esp IDE tools need).

--
Richard Gaskin
Fourth World Systems

___
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: Hot Folders solution for Windows with LC

2021-10-07 Thread Paul Dupuis via use-livecode

The only way I know to to that in LiveCode is by polling the folder at 
some interval.


You get the detailed files (for the last modification date)
filter to PDFs
output them to pdf/1-1b's
Save this initial detail list of PDF files (in a variable or property or 
field)

Then send a message to yourself in x minutes

That message get the detailed files and compares the new list to the 
save list

Any new or updated file is sent to Ghostscript
Then the save list is updated
Send a message to myself in X minutes

That's pretty much it.

On 10/7/2021 3:39 PM, matthias rebbe via use-livecode wrote:

Hi,

before i reinvent the wheel...

Has anyone on the list already created a solution for monitoring a folder on 
Windows (server) for new files and to do some action on that new files?

I need to create a tool that monitors a folder on Windows Server 2019  and if a 
new pdf file is in the folder, the tool shall convert that pdf to pdf/a-1b with 
Ghostscript in an destination folder and rename the original one.

Is there anything i should keep in mind? Are there any pitfalls?

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

Re: Hot Folders solution for Windows with LC

2021-10-07 Thread matthias rebbe via use-livecode

Thanks Paul,

that's the way i was planning to do it. But i will move the original file into 
a subfolder, so that the hot folder only contains new unprocessed files.

I was more looking to rule out any known problems that might occur when doing 
this. 

Matthias

> Am 07.10.2021 um 22:32 schrieb Paul Dupuis via use-livecode 
> :
> 
> The only way I know to to that in LiveCode is by polling the folder at some 
> interval.
> 
> You get the detailed files (for the last modification date)
> filter to PDFs
> output them to pdf/1-1b's
> Save this initial detail list of PDF files (in a variable or property or 
> field)
> Then send a message to yourself in x minutes
> 
> That message get the detailed files and compares the new list to the save list
> Any new or updated file is sent to Ghostscript
> Then the save list is updated
> Send a message to myself in X minutes
> 
> That's pretty much it.
> 
> On 10/7/2021 3:39 PM, matthias rebbe via use-livecode wrote:
>> Hi,
>> 
>> before i reinvent the wheel...
>> 
>> Has anyone on the list already created a solution for monitoring a folder on 
>> Windows (server) for new files and to do some action on that new files?
>> 
>> I need to create a tool that monitors a folder on Windows Server 2019  and 
>> if a new pdf file is in the folder, the tool shall convert that pdf to 
>> pdf/a-1b with Ghostscript in an destination folder and rename the original 
>> one.
>> 
>> Is there anything i should keep in mind? Are there any pitfalls?
>> 
>> 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


___
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: OT: Priorities (was: Re: Stack with the same name loop)

2021-10-07 Thread Curry Kenworthy via use-livecode




My two pesos, following these comments

Sean:
> they leave something as *basic as this
> unrepaired for EIGHTTEENYEARS !?!

Jacqueline:
> they have to make considered choices in what to address
> at any given time given the resources available to them.

Bernard:
> At least the new licensing model should allow LC to prioritise
> based on what customers use.
> IMO the open source initiative was the single biggest mistake

Bob:
> I survived the age of freeware.

Richard:
> Heather politely called cheese on this topic some time ago.
> May we please respect the wishes of the list owner?

(Curry:)

I propose reducing the attempts to silence one another?

That cheese remark doesn't sound like a very accurate portrayal;
that license change topic had simply been discussed enough.

No need to conflate that with this tiny celebration
of better priorities. If we outlaw positive feedback too,
what will be left? Maybe you'll direct us what to say?

My apologies if I'm wrong (been sick going on 2 months,
haven't read everything) but all of the comments
on priorities, and the same-name parent topic
make really good points as far as I've read.
(Including Richard's on the parent thread.)

Reality is a complex world. We need to respect
the limitations of real people and resources.
LC can't be everything to everyone for 99 cents.
They've done some great things.

But we also need to respect a variety of opinions.
Otherwise we handicap ourselves, as we've learned.

There was a time not long ago when this list
was dominated by only a handful of people.
90% of the time we heard only a few voices.

Result? For those few people, maybe it was OK.
Their own personal needs drove their priorities
and they drove conversation around their desires.
For everyone else, maybe not quite so great.

I like hearing different views. You learn things.
A big +1 from me to a lot of varied comments.
Different people have different needs and priorities.
Let's be willing to listen more.

I'll shut up now and go back to read/lurk/work. :)

(I'm gradually doing a WordLib update ... still sick.
Fairly low chance of me monitoring any replies here;
this is intended as my single post for the week.)

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: Stack with the same name loop


On 10/7/21 10:38 AM, J. Landman Gay via use-livecode wrote:
For me, the confusion would be resolved if the Save button was renamed 
to "Save and Purge". I was never quite sure what that button saved, 
though in retrospect it's pretty obvious.


How about a fourth option to rename the stack in memory and continue?

--
 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: OT: Priorities (was: Re: Stack with the same name loop)

2021-10-07 Thread Curry Kenworthy via use-livecode




Richard:

> And in this here-and-now, I don't have an opinion
> on the conversation between Jacque and Sean,
> which is why I didn't reply to them.

Jacque and Sean made good points.
As did Bob and Bernard.
Which is why I quoted them too.

All of them made great points
on Priorities, the thread topic.

(I never have, and never will,
quote the entire post. Misguided trend.)

Have a good week! :)

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: Hot Folders solution for Windows with LC

2021-10-07 Thread Paul Dupuis via use-livecode

I've done a lot with lists of files and moving and renaming files and 
folders.


I've run into no 'gotchas' other my my fat fingers making typos in my 
code ;-)



On 10/7/2021 5:00 PM, matthias rebbe via use-livecode wrote:

Thanks Paul,

that's the way i was planning to do it. But i will move the original file into 
a subfolder, so that the hot folder only contains new unprocessed files.

I was more looking to rule out any known problems that might occur when doing 
this.

Matthias


Am 07.10.2021 um 22:32 schrieb Paul Dupuis via use-livecode 
:

The only way I know to to that in LiveCode is by polling the folder at some 
interval.

You get the detailed files (for the last modification date)
filter to PDFs
output them to pdf/1-1b's
Save this initial detail list of PDF files (in a variable or property or field)
Then send a message to yourself in x minutes

That message get the detailed files and compares the new list to the save list
Any new or updated file is sent to Ghostscript
Then the save list is updated
Send a message to myself in X minutes

That's pretty much it.

On 10/7/2021 3:39 PM, matthias rebbe via use-livecode wrote:

Hi,

before i reinvent the wheel...

Has anyone on the list already created a solution for monitoring a folder on 
Windows (server) for new files and to do some action on that new files?

I need to create a tool that monitors a folder on Windows Server 2019  and if a 
new pdf file is in the folder, the tool shall convert that pdf to pdf/a-1b with 
Ghostscript in an destination folder and rename the original one.

Is there anything i should keep in mind? Are there any pitfalls?

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


___
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: OT: Priorities (was: Re: Stack with the same name loop)


Curry:

> Richard:
>>   Heather politely called cheese on this topic some time ago.
>>   May we please respect the wishes of the list owner?
>
> I propose reducing the attempts to silence one another?
>
> That cheese remark doesn't sound like a very accurate portrayal;
> that license change topic had simply been discussed enough.

Agreed, of course, as is clear when you read my reply to see what I was 
-- and wasn't -- replying to.


For the avoidance of doubt, I included the full text of both replies I 
was responding to - my complete post is here:

http://lists.runrev.com/pipermail/use-livecode/2021-October/265845.html

Relevant portions include:
> IMO the open source initiative was the single biggest mistake LC Ltd
> made.
...
> +1. Gave me the heebie jeebies when they announced the Open Source
> model.
>
> I survived the age of freeware. There were a LOT of people back then
> who opined that ALL software ought to be free! It was staggering.


LC's open source is gone, and cannot return. What's done is done.

All I'm asking is that we leave the past where it is, behind us, and 
live in the here-and-now.


And in this here-and-now, I don't have an opinion on the conversation 
between Jacque and Sean, which is why I didn't reply to them.


Lumping my comment in with theirs suggests a more complete reading may 
be useful before rushing to reply.



> My apologies if I'm wrong (been sick going on 2 months,
> haven't read everything) ...

I hope you're feeling better soon.

--
 Richard Gaskin
 Fourth World Systems


___
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

Hot Folders solution for Windows with LC

2021-10-07 Thread matthias rebbe via use-livecode

Hi,

before i reinvent the wheel...

Has anyone on the list already created a solution for monitoring a folder on 
Windows (server) for new files and to do some action on that new files?

I need to create a tool that monitors a folder on Windows Server 2019  and if a 
new pdf file is in the folder, the tool shall convert that pdf to pdf/a-1b with 
Ghostscript in an destination folder and rename the original one.

Is there anything i should keep in mind? Are there any pitfalls?

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

Re: Stack with the same name loop


On 10/7/21 6:40 AM, Mark Waddingham via use-livecode wrote:

The correct behavior of that dialog is precisely what you would expect 
from the button names:


   1) Cancel - the loading of the new stack does not happen.
   2) Purge - the existing stack of the same name is removed from memory 
without saving first, and the new stack is loaded.
   3) Save - the existing stack of the same name is saved and then 
removed from memory, and the new stack is loaded.




Mark-

Thanks muchly for the longish explanation.
The main problem, as I see it, is the lack of any context for what the 
buttons do when that dialog appears. My reading of the reloadStack code 
more or less agrees with your explanation above, although there seem to 
be extra calls to "delete stack" which still don't give me warm fuzzies. 
I do what everyone else does when that dialog appears: panic, quit and 
restart.


Maybe a different dialog that explains what the various options do?

--
 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: Stack with the same name loop

On 7 Oct 2021, at 17:28, Mark Waddingham via use-livecode 
 wrote:
> 
> So the first thing to ask is, is the recipe as simple as:
> 
>  1) Select stack you want to 'Save As'
>  2) File > Save As
>  3) Give a different name and Save
>  4) Duplicate name Save/Purge/Cancel dialog appears?
> 
> Or is there any more to the recipe?

Quite right. I make sure it’s the main stack selected and that all other 
stacks, inspectors and editors are closed just in case. Then, as you have it 
laid out in steps 2 to 4 and 4 and 4 ad infinitum. :)

That’s all there is to it. 

There is nothing, as I am aware, that is loading any other external stacks at 
all. They only reference to substacks of the main. 

What do we check next?

Sean

___
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: Stack with the same name loop

2021-10-07 Thread Neville Smythe via use-livecode

Jaque wrote

> On 8 Oct 2021, at 7:54 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> For me, the confusion would be resolved if the Save button was renamed to 
> "Save and Purge". I was never quite sure what that button saved, though in 
> retrospect it's pretty obvious.

And ...

if the dialog could inform the user as to the filename of the stack which is 
about to be opened, the filename of the stack currently in memory (or “not yet 
saved"), and whether the current stack has unsaved changes. This would make it 
clearer what the consequences are in each of the options.

It seems to me in Sean’s case the stack being loaded was not the stack one 
might expect (ie was it attempting to reload the the original or the renamed 
stack?)

Neville 

___
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: Stack with the same name loop


On 10/7/21 12:54 PM, Richard Gaskin via use-livecode wrote:

Though related to the duplicate stack name issue, the core underlying 
cause is a separate item logged here:

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


Note that you can use the property inspector to change the name of a 
stack to the name of another stack also in memory. The IDE gets quite 
confused at that point, and quitting the IDE is the best option.


--
 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: Stack with the same name loop


On 10/7/21 1:08 PM, Mark Wieder via use-livecode wrote:

How about a fourth option to rename the stack in memory and continue?


...replying to myself...
I fixed reloadStack to allow a rename and be a little less scary.
I just edited the livecodescript file on disk and it so far seems to 
work in all my tests.


on reloadStack pStackName, pFileName
   if the filename of stack pStackName is pFileName then
  toplevel pStackName
   else
  set the defaultStack to pStackName

  local tFilePath, tFileLongPath
  put the effective fileName of stack pStackName into tFilePath
  put tFilePath into tFileLongPath
if tFileLongPath is empty then
put pStackName into tFileLongPath
put comma && pStackName & "?" after tFilePath
else
put pStackName & "?" into tFilepath
end if
  answer warning "A stack with the name"&&&"is already 
open." & cr & "Before loading" && pFileName & ", what do you want to do 
with stack:" & cr & tFilePath with "Rename" or "Save" or "Purge" or "Cancel"

local tAction
put it into tAction
  if gREVSuppressMessages then
 lock messages
 send "revInsertMessageBlock" to me in 100 milliseconds
 revInternal__UnloadLibrary "revNoMessagesLibrary"
  end if

 local tLockMessages
  put the lockMessages into tLockMessages

 switch tAction
case "Cancel"
exit reloadStack
case "Rename"
ask "rename the stack in memory to"
if it is not empty and it is not pStackName then
set the name of stack tFileLongPath to it
end if
set the lockMessages to tLockMessages
go stack pFileName
break
case "Save"
 if the filename of stack pStackName is empty then
revSaveAs pStackName
 else
revSave pStackName
 end if
case "Purge"
 revAOUpdateForDeleteStack pStackName
 lock messages
 delete stack pStackName
 set the lockMessages to tLockMessages
 go stack pFileName
break
end switch
   end if

   if there is a stack "revApplicationOverview" then
  send "revNewStack the short name of stack pFileName" to stack 
"revApplicationOverview"

   end if
end reloadStack

--
 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: Stack with the same name loop


On 2021-10-07 20:12, Pi Digital via use-livecode wrote:

Quite right. I make sure it’s the main stack selected and that all
other stacks, inspectors and editors are closed just in case. Then, as
you have it laid out in steps 2 to 4 and 4 and 4 ad infinitum. :)

That’s all there is to it.

There is nothing, as I am aware, that is loading any other external
stacks at all. They only reference to substacks of the main.

What do we check next?


So we need to try and work out what is causing the load of a stack with 
the same name of that in memory (my hunch is that there is a filename 
reference to a stack somewhere, which is being triggered, and reloading 
the stack which has just been saved-as from it original location).


If you:

  edit script of stack "revbackscriptlibrary"

Find the `reloadStack` handler and then add:

  put the executionContexts

At the very top of the handler - then you should get the backtrace of 
what handlers are executing at the point the reloadStack message is sent 
which should help pinpoint the culprit.


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

LC apps crashing on devices running iOS 15.x

2021-10-07 Thread HENRY LOWE via use-livecode

Fernando and I have submitted a bug report 
(https://quality.livecode.com/show_bug.cgi?id=23364 ) after confirming that 
previously stable LC iOS apps are intermittently crashing at launch on devices 
(iPhone & iPad) running iOS 15.x. We have submitted crash logs to LC. The issue 
has been confirmed but, so far, it is unclear what is causing the crashes.
What we appear to know so far:

1. Seems to be an iOS 15.x issue on a device only (no simulator crash).

2. Crash on launch only - I have seen no crashes once app successfully launches.

3. No splash screen is shown, so crashing early in the launch process.

4. Crash on launch is intermittent.

5. Does not crash on first launch after installation.

6. Leaving the app in the background long enough for it to be killed by iOS? 
seems a necessary condition for a subsequent crash on launch.

7. Crash logs show KERN_INVALID_ADDRESS. The crashed thread accessed unmapped 
memory, either by accessing data or an instruction fetch.
Is anyone else seeing intermittent app crashes on launch under iOS 15? If so, 
can you provide any additional information and/or crash logs to LC? In my case 
the iOS App Store app is written using LC 9.6.4 (Stable) on macOS 10.14.

I have some very unhappy users and would love to submit an app update fixing 
this issue.

Thanks,

Henry

Ascriva Health Informatics

Https://www.ascriva.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: OT: Priorities (was: Re: Stack with the same name loop)

> On 7 Oct 2021, at 05:49, J. Landman Gay wrote:
> 
> In the larger picture, what would you address first:

Firstly the fundamentals
Closely followed by UX

These are the foundation upon which ALL software AND hardware are based. 
Without them everything else is a waste. 

Sure, a wheel can have pretty callipers and spokes, fancy tyres with run-flat 
technology, but if it can’t turn because the bearings are exposed or the lug 
nuts rust easily meaning you have to drill them out (an irritating workaround) 
to replace a damaged one, then what’s the point of all the fancy stuff?

An ‘irritating’ workaround that’s been in place for “18 YEARS” is seen as 
acceptable. However kind a person is, putting their core users through that 
torture goes to show what lies at the heart of them. Gently water boarding. 
Leathal injection given in nano-ounces every day/week/month. A noose tightened 
gradually and gently while slowly pushing the stool from under you. You get the 
picture. It sounds kind but ultimately winds up killing us all in the end. 

Everybody ‘seems’ kind and genuine. Without exception, everyone are not, not 
entirely. Every single one at their core is self-serving. That leads to 
protective behaviours. This is developed from childhood, impressed upon by 
parenting and society, then ingrained by experience and environment. Some get 
pampered and groomed into not seeing the maltreatment, believing that all or 
some are benevolent and beyond reproach. That is either illusionary or 
delusionary. 

I HAVE met a lot of the people at LC. Visited three of their bases. They all 
‘seemed’ nice. But, unfortunately, we are all flawed and are all inconsistent. 
All affected and feel the effects of time and events. It’s inescapable. If we 
have a nerve touched we respond, as did you to my last post. Those reactions 
are only a natural reflex to how we have been trained to respond based on our 
past. You’ve been trained to accept things that others find uncomfortable. I 
respond badly, partly because of the chemicals, but mostly by the scars of 
mistreatment over a long period that have enabled me to see people in a 
different light, sometimes distorted, but more often in their true nature, and 
choose not to accept it’s discomfort. I can be nice, but my nerves are exposed 
and raw. 

I don’t mean to offend, but offence is inevitable no matter what is said in 
this day and age of woke mentality. So I apologise to those who have been 
offended now. That sounds nice but, at it’s core, is false because I don’t care 
if you are offended - I had something to say about how I feel and so said it. 
Which is only fair because a lot of what has been said here over the past few 
weeks has deeply offended me but I’ve said nothing. Because, so what if I’m 
offended. :) 

Now loop back to paragraph three and four and read in context. 

___
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: Stack with the same name loop

2021-10-07 Thread Craig Newman via use-livecode

RE: the “purge/save/cancel” thing.

I see this exactly twice whenever I build a standalone for a particular 
project. Even in a new session, if the first thing I do is build a standalone 
from the splash stack, I will twice get a dialog during the process asking me 
the three questions. I always “purge”, and always everything works out fine.

But the only stack I open in that new session is the splash stack itself, 
running the build directly from there. 

The splash stack opens a mainStack in normal operation, and this may have 
something to do with the presentation of the dialog.

Craig

> On Oct 7, 2021, at 9:40 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2021-10-06 22:30, Mark Wieder via use-livecode wrote:
>> That's what I do as well. Kill, then go do something else for a bit.
>> Reading the code that invokes this dialog (the reloadstack handler in
>> revbackscriptlibrary.livecodescript) isn't much help. It's only the
>> IDE that can't handle this, not the engine.
>> This would all be moot if the IDE used the long id of the stack
>> instead of just the short name of the stack, but that would require
>> work.
> 
> That isn't true - the problem is a lot deeper than that.
> 
> Most 'stack' related engine syntax works with the short name of stacks e.g. 
> defaultStack, topStack, stackFiles.
> 
> The IDE is built using the engine, so has to work within the limitations the 
> engine has.
> 
> Internally the engine references stacks by 'weak handles' (basically pointers 
> which 'know' when the thing they are pointing at has been deleted) - it does 
> not use names... However the way stacks are referenced by script (as 
> mentioned above) do use the short name - to keep things simple.
> 
> Of course it would be possible to add new syntax and such - and it would be 
> possible to update the IDE to use it (and thus the 'irksome' dialog could be 
> removed).
> 
> However, the reality is that, that endeavour (which would be a very large 
> amount of work) would only shift the problem - onto users themselves.
> 
> If user code did not use the new syntax, then chances are they would end up 
> causing really hard to track down issues in their own code due to having two 
> stacks with the same name. This is regardless of whatever resolution order 
> was chosen to resolve conflicts - unless user code also uses unique stack 
> references, there is no choice which would not stop problems from happening.
> 
> I'd like to point out that this is not me copping out here - it is merely 
> pointing out that simplicity does come with restrictions - and as it stands, 
> one of these restrictions (with livecode) is uniquely named stacks.
> 
> I'd further point out that 'critical things having unique name' isn't that 
> rare. For example, you can't have two files with the same name in a folder 
> for example (even though on UNIX systems, every file has an internal unique 
> integer id - the inode number) and you can't have two handlers, variables, 
> methods, types (or any named thing) with the same name (in the same 
> namespace) in any language that I know of.
> 
> So, may I suggest, the problem to solve is to figure out why the dialog which 
> spawned this thread does not work correctly in some circumstances?
> 
> I say some circumstances, because it does work precisely as advertised in a 
> (fresh) IDE after it has been started:
> 
>  1) Create a stack "Foo" - save it as "FooEmpty.livecode" and remove from 
> memory
>  2) Create another stack "Foo" - place a button on it and save it as 
> "FooButton.livecode"
>  3) Load FooEmpty.livecode from the menu - ask to Purge. FooEmpty appears 
> (and FooButton goes)
>  4) Add a tab control to FooEmpty.
>  5) Load FooButton.livecode from the menu - ask to Save, FooEmpty is saved 
> and FooButton appears.
>  6) Load FooEmpty.livecode from the menu - ask to Purge, FooEmpty appears 
> (now with tab control) and FooButton has gone.
> 
> The correct behavior of that dialog is precisely what you would expect from 
> the button names:
> 
>  1) Cancel - the loading of the new stack does not happen.
>  2) Purge - the existing stack of the same name is removed from memory 
> without saving first, and the new stack is loaded.
>  3) Save - the existing stack of the same name is saved and then removed from 
> memory, and the new stack is loaded.
> 
> The effect observed (the looping) could be an interaction with a component in 
> the IDE (which somehow causes the stack which should be being removed to be 
> reloaded), or it could be some code pattern in user stacks which cause much 
> the same problem. In the former case, we need to fix the IDE to be 'purge 
> safe in this case', in the latter case we need to understand the pattern so 
> that we can change the mechanism to not be affected by it.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
>

Re: Stack with the same name loop

Hi Mark (both :) )

Thanks for your explanation. Very thorough. 

What I don’t understand is why the engine needs to delete the old reference 
(weak handle) when invoking a ‘save as’. Is it not just a matter of resaving 
you a new location and making the pointer to the storage device for that 
instance? Why does it need to save it and then remove from memory at all? Just 
carry on with what is already in memory without the need to reload. That’s why 
we use a ‘save as’ anyway. 

Thanks again. 

Sean


> On 7 Oct 2021, at 14:40, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2021-10-06 22:30, Mark Wieder via use-livecode wrote:
>> That's what I do as well. Kill, then go do something else for a bit.
>> Reading the code that invokes this dialog (the reloadstack handler in
>> revbackscriptlibrary.livecodescript) isn't much help. It's only the
>> IDE that can't handle this, not the engine.
>> This would all be moot if the IDE used the long id of the stack
>> instead of just the short name of the stack, but that would require
>> work.
> 
> That isn't true - the problem is a lot deeper than that.
> 
> Most 'stack' related engine syntax works with the short name of stacks e.g. 
> defaultStack, topStack, stackFiles.
> 
> The IDE is built using the engine, so has to work within the limitations the 
> engine has.
> 
> Internally the engine references stacks by 'weak handles' (basically pointers 
> which 'know' when the thing they are pointing at has been deleted) - it does 
> not use names... However the way stacks are referenced by script (as 
> mentioned above) do use the short name - to keep things simple.
> 
> Of course it would be possible to add new syntax and such - and it would be 
> possible to update the IDE to use it (and thus the 'irksome' dialog could be 
> removed).
> 
> However, the reality is that, that endeavour (which would be a very large 
> amount of work) would only shift the problem - onto users themselves.
> 
> If user code did not use the new syntax, then chances are they would end up 
> causing really hard to track down issues in their own code due to having two 
> stacks with the same name. This is regardless of whatever resolution order 
> was chosen to resolve conflicts - unless user code also uses unique stack 
> references, there is no choice which would not stop problems from happening.
> 
> I'd like to point out that this is not me copping out here - it is merely 
> pointing out that simplicity does come with restrictions - and as it stands, 
> one of these restrictions (with livecode) is uniquely named stacks.
> 
> I'd further point out that 'critical things having unique name' isn't that 
> rare. For example, you can't have two files with the same name in a folder 
> for example (even though on UNIX systems, every file has an internal unique 
> integer id - the inode number) and you can't have two handlers, variables, 
> methods, types (or any named thing) with the same name (in the same 
> namespace) in any language that I know of.
> 
> So, may I suggest, the problem to solve is to figure out why the dialog which 
> spawned this thread does not work correctly in some circumstances?
> 
> I say some circumstances, because it does work precisely as advertised in a 
> (fresh) IDE after it has been started:
> 
>  1) Create a stack "Foo" - save it as "FooEmpty.livecode" and remove from 
> memory
>  2) Create another stack "Foo" - place a button on it and save it as 
> "FooButton.livecode"
>  3) Load FooEmpty.livecode from the menu - ask to Purge. FooEmpty appears 
> (and FooButton goes)
>  4) Add a tab control to FooEmpty.
>  5) Load FooButton.livecode from the menu - ask to Save, FooEmpty is saved 
> and FooButton appears.
>  6) Load FooEmpty.livecode from the menu - ask to Purge, FooEmpty appears 
> (now with tab control) and FooButton has gone.
> 
> The correct behavior of that dialog is precisely what you would expect from 
> the button names:
> 
>  1) Cancel - the loading of the new stack does not happen.
>  2) Purge - the existing stack of the same name is removed from memory 
> without saving first, and the new stack is loaded.
>  3) Save - the existing stack of the same name is saved and then removed from 
> memory, and the new stack is loaded.
> 
> The effect observed (the looping) could be an interaction with a component in 
> the IDE (which somehow causes the stack which should be being removed to be 
> reloaded), or it could be some code pattern in user stacks which cause much 
> the same problem. In the former case, we need to fix the IDE to be 'purge 
> safe in this case', in the latter case we need to understand the pattern so 
> that we can change the mechanism to not be affected by it.
> 
> 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

Re: Stack with the same name loop


On 2021-10-07 15:26, Pi Digital via use-livecode wrote:

Hi Mark (both :) )

Thanks for your explanation. Very thorough.

What I don’t understand is why the engine needs to delete the old
reference (weak handle) when invoking a ‘save as’. Is it not just a
matter of resaving you a new location and making the pointer to the
storage device for that instance? Why does it need to save it and then
remove from memory at all? Just carry on with what is already in
memory without the need to reload. That’s why we use a ‘save as’
anyway.


This isn't related to 'Save As' - nor is the engine doing anything here 
beyond sending a message - which is enforcing the 'only one main stack 
with a given (short) name exists in memory at any one time' invariant.


When a stack is deserialized from the on-disk file - before it is 
'hooked up' to anything (i.e. added to the list of things considered for 
any sort of search), it sweeps through all loaded mainStacks and checks 
to see if there is a name conflict (i.e. short name of new stack matches 
that of old).


If there is (and the filenames are different) then it deletes what it 
has just loaded and sends a 'reloadStack' message. Otherwise, it hooks 
the new loaded stack up to the internal list of things considered actual 
stacks.


The IDE handles the reloadStack message - it shows the dialog in 
question.


If you choose 'Cancel' it takes no action - so nothing changes (no new 
stack loaded, no old stack deleted).


If you choose 'Purge' the IDE does its best to remove the current stack 
in memory and *then* trys to load the new stack (from the different 
filepath) - as (in principal) there is no longer any stack in memory 
with the conflicting name, then engine loads it and things carry on.


If you choose 'Save' the IDE does the same as above except that *before* 
it tries to remove the current stack from memory, it saves (save as, if 
the current stack has no filename).


So the looping problem here lies somewhere in the process removing the 
existing stack from memory / saving it.


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: Stack with the same name loop

2021-10-07 Thread matthias rebbe via use-livecode

I am using a little plugin for this. It allows me to save the stack file under 
an other name. 

For those who are interested...
https://dl.qck.nu/?dl=copyStack.livecode 


When it opens it displays the name of the current top stack. If you want to 
copy an other opened stack then switch to that stack and click into the plugin 
window to get the name of the "new" top stack.
To save a copy of that stack press the little icon. You'll then see a Save As 
dialog.

I am sure it could be improved, but it does what i want to achieve with it.

Regards,

Matthias


> Am 07.10.2021 um 05:27 schrieb J. Landman Gay via use-livecode 
> :
> 
> I do something similar but it's a lot less trouble.
> 
> Save the stack.
> Go to Finder /Explorer and duplicate it. Rename the copy.
> Go back to LC and carry on with the original. You can update the name or any 
> properties there.
> 
> Occasionally as I work I realize that I've implemented a lot of changes that 
> I may not want to keep. So before I save the stack, I duplicate it in Finder 
> so I have a copy of the one I'm working on as it was before I wrote myself 
> into a corner. That's come in handy.
> 
> I don't have much trouble with the duplicate stack dialog because I always 
> hit the Purge button which removes the first one from memory and opens the 
> second one. I don't remember ever actually seeing a loop. If I want to work 
> with two same-named stacks together I have two methods.
> 
> 1. Open one of them in another copy of LC. I always have at least 3 different 
> versions running at the same time, and yes, you have to be careful when you 
> do that. I usually choose this method because most often I just want to copy 
> a handler or a control.
> 
> 2. Temporarily rename the first one slightly, open the second, do what you 
> want, then close and remove the second one from memory and set the name of 
> the first one back to normal.
> 
> None of this has ever required me to quit LC. I suppose now that I've 
> mentioned it, something will happen...
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On October 6, 2021 7:04:07 PM "Brian K. Duck via use-livecode" 
>  wrote:
> 
>> My process has become:
>> Save the file in LiveCode.
>> Close the file from LiveCode, purge from memory.
>> Switch to Finder (Mac) or Windows Explorer, or QUIT LiveCode,
>> Duplicate and rename the file,
>> Open the new file,
>> Return to LiveCode,
>> Rename the file in stack properties, if there isa version number in the 
>> stack name.
>> 
>> It may be needless to say, this is usually a 1x or 2x a day process.
>> 
>> TL;DR: don’t ’save as,’ save, close, quit LC, duplicate in finder / windows 
>> explorer, open new file, rename stack in stack properties - if there is a 
>> version no in the stack name.
>> 
>> Even then, I occasionally see the message. Then i repeat and QUIT LiveCode.
>> 
>> Sent from my iPad,
>> Brian Duck
>> 
>> 
>> 
>> Sent from my iPad
>>> On Oct 6, 2021, at 12:57 PM, Sean Cole (Pi) via use-livecode 
>>>  wrote:
>>> 
>>> Hi all,
>>> Can someone give the definitive answer as to what to choose when I save my
>>> stack with a save as to create a new iterative version and it comes up with
>>> the prompt :
>>> A stack with the same name as the one you are trying to load is
>>> already open.
>>>   SavePurgeCancel
>> 
>> Option 4: avoid the hassle.
>> ___
>> 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

Re: Stack with the same name loop


On 2021-10-06 22:30, Mark Wieder via use-livecode wrote:

That's what I do as well. Kill, then go do something else for a bit.

Reading the code that invokes this dialog (the reloadstack handler in
revbackscriptlibrary.livecodescript) isn't much help. It's only the
IDE that can't handle this, not the engine.

This would all be moot if the IDE used the long id of the stack
instead of just the short name of the stack, but that would require
work.


That isn't true - the problem is a lot deeper than that.

Most 'stack' related engine syntax works with the short name of stacks 
e.g. defaultStack, topStack, stackFiles.


The IDE is built using the engine, so has to work within the limitations 
the engine has.


Internally the engine references stacks by 'weak handles' (basically 
pointers which 'know' when the thing they are pointing at has been 
deleted) - it does not use names... However the way stacks are 
referenced by script (as mentioned above) do use the short name - to 
keep things simple.


Of course it would be possible to add new syntax and such - and it would 
be possible to update the IDE to use it (and thus the 'irksome' dialog 
could be removed).


However, the reality is that, that endeavour (which would be a very 
large amount of work) would only shift the problem - onto users 
themselves.


If user code did not use the new syntax, then chances are they would end 
up causing really hard to track down issues in their own code due to 
having two stacks with the same name. This is regardless of whatever 
resolution order was chosen to resolve conflicts - unless user code also 
uses unique stack references, there is no choice which would not stop 
problems from happening.


I'd like to point out that this is not me copping out here - it is 
merely pointing out that simplicity does come with restrictions - and as 
it stands, one of these restrictions (with livecode) is uniquely named 
stacks.


I'd further point out that 'critical things having unique name' isn't 
that rare. For example, you can't have two files with the same name in a 
folder for example (even though on UNIX systems, every file has an 
internal unique integer id - the inode number) and you can't have two 
handlers, variables, methods, types (or any named thing) with the same 
name (in the same namespace) in any language that I know of.


So, may I suggest, the problem to solve is to figure out why the dialog 
which spawned this thread does not work correctly in some circumstances?


I say some circumstances, because it does work precisely as advertised 
in a (fresh) IDE after it has been started:


  1) Create a stack "Foo" - save it as "FooEmpty.livecode" and remove 
from memory
  2) Create another stack "Foo" - place a button on it and save it as 
"FooButton.livecode"
  3) Load FooEmpty.livecode from the menu - ask to Purge. FooEmpty 
appears (and FooButton goes)

  4) Add a tab control to FooEmpty.
  5) Load FooButton.livecode from the menu - ask to Save, FooEmpty is 
saved and FooButton appears.
  6) Load FooEmpty.livecode from the menu - ask to Purge, FooEmpty 
appears (now with tab control) and FooButton has gone.


The correct behavior of that dialog is precisely what you would expect 
from the button names:


  1) Cancel - the loading of the new stack does not happen.
  2) Purge - the existing stack of the same name is removed from memory 
without saving first, and the new stack is loaded.
  3) Save - the existing stack of the same name is saved and then 
removed from memory, and the new stack is loaded.


The effect observed (the looping) could be an interaction with a 
component in the IDE (which somehow causes the stack which should be 
being removed to be reloaded), or it could be some code pattern in user 
stacks which cause much the same problem. In the former case, we need to 
fix the IDE to be 'purge safe in this case', in the latter case we need 
to understand the pattern so that we can change the mechanism to not be 
affected by it.


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: OT: Priorities (was: Re: Stack with the same name loop)

2021-10-07 Thread Bernard Devlin via use-livecode

At least the new licensing model should allow LC to prioritise based on
what customers use.

IMO the open source initiative was the single biggest mistake LC Ltd made.
With that drain on resources over hopefully they can get to work on fixing
some of the outstanding deficiencies.
___
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: Stack with the same name loop

2021-10-07 Thread Bernard Devlin via use-livecode

I guess it comes down to what different people are doing with LC.

I get the erroneous "this script has been altered externally" message about
3 times a year.
I never get the "A stack with the same name as the one you are trying to
load" unless I really am opening two stacks with the same name.

In my own work I always try to work with the long ID of every control. It's
the least ambiguous thing one can do. The IDE should do the same.

On Thu, Oct 7, 2021 at 12:45 AM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On the bright side, it isn't as confusing as the one that tells you the
> script has been changed in an external editor, even if it wasn't, and then
> you don't know whether to keep what you're looking at or take a chance and
> reload. You can lose work by choosing the wrong button.
>
> --
> Jacqueline Landman Gay | jac...@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: Stack with the same name loop



> On 7 Oct 2021, at 15:38, Mark Waddingham via use-livecode 
>  wrote:
> 
> So the looping problem here lies somewhere in the process removing the 
> existing stack from memory / saving it.

Like what, for example?

Thanks. 

___
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: Stack with the same name loop

Clone stack avoids the check.  It is not that hard to get multiple stacks with 
the same short name but different long names in memory (in a standalone).  The 
engine makes sane choices when referencing the top stack in that case.  Any 
individual stack can be referenced via the long name.

Sent from my iPhone

> On Oct 7, 2021, at 10:38 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2021-10-07 15:26, Pi Digital via use-livecode wrote:
>> Hi Mark (both :) )
>> Thanks for your explanation. Very thorough.
>> What I don’t understand is why the engine needs to delete the old
>> reference (weak handle) when invoking a ‘save as’. Is it not just a
>> matter of resaving you a new location and making the pointer to the
>> storage device for that instance? Why does it need to save it and then
>> remove from memory at all? Just carry on with what is already in
>> memory without the need to reload. That’s why we use a ‘save as’
>> anyway.
> 
> This isn't related to 'Save As' - nor is the engine doing anything here 
> beyond sending a message - which is enforcing the 'only one main stack with a 
> given (short) name exists in memory at any one time' invariant.
> 
> When a stack is deserialized from the on-disk file - before it is 'hooked up' 
> to anything (i.e. added to the list of things considered for any sort of 
> search), it sweeps through all loaded mainStacks and checks to see if there 
> is a name conflict (i.e. short name of new stack matches that of old).
> 
> If there is (and the filenames are different) then it deletes what it has 
> just loaded and sends a 'reloadStack' message. Otherwise, it hooks the new 
> loaded stack up to the internal list of things considered actual stacks.
> 
> The IDE handles the reloadStack message - it shows the dialog in question.
> 
> If you choose 'Cancel' it takes no action - so nothing changes (no new stack 
> loaded, no old stack deleted).
> 
> If you choose 'Purge' the IDE does its best to remove the current stack in 
> memory and *then* trys to load the new stack (from the different filepath) - 
> as (in principal) there is no longer any stack in memory with the conflicting 
> name, then engine loads it and things carry on.
> 
> If you choose 'Save' the IDE does the same as above except that *before* it 
> tries to remove the current stack from memory, it saves (save as, if the 
> current stack has no filename).
> 
> So the looping problem here lies somewhere in the process removing the 
> existing stack from memory / saving it.
> 
> 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

___
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: Stack with the same name loop


On 2021-10-07 15:57, Brian Milby via use-livecode wrote:

Clone stack avoids the check.  It is not that hard to get multiple
stacks with the same short name but different long names in memory (in
a standalone).  The engine makes sane choices when referencing the top
stack in that case.  Any individual stack can be referenced via the
long name.


Yes indeed, you don't actually need to even use clone stack - just 'set 
the name of' will do it.


However, the fact you can do that from script is a different case from 
what the IDE should let you do in the normal course of things (and 
indeed, perhaps we should plug the holes in the engine which let it 
happen) in (a perhaps vain?) attempt to stop people tying themselves 
into too many knots.


Things like the 'topStack' and 'defaultStack' are only sane references 
to the actual underlying stack if they are used as direct syntax (where 
they resolve to the internal pointer). As soon as they are rendered to a 
string (e.g. when passed as an argument) that link is gone - further, if 
a stack has not been saved then there is no way to distinguish one from 
the other with any string-based reference (a stack's long id is only 
different from its name / long name if it has a filename).


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: Stack with the same name loop

> On 7 Oct 2021, at 15:49, Mark Waddingham via use-livecode 
>  wrote:
> 
> Indeed, is this a multi-stack system which you are working on? Is there a way 
> your code (which is being triggered somehow after save) is referencing the 
> stack you just saved as, by its original filename?

It is a multi-stack system for sure. 114 substacks, 840 cards, 90,039 objects 
and counting. 

The stacks and cards only every reference themselves as ‘me’ or ‘this’. The 
preopenstack has a bunch of references to ‘start using stack “whatever”’ to run 
as libraries I’ve written. And then the openstack uses a dispatch to run a 
script from one of these libraries, closely followed by a ‘send “blah” to 
“aLib” in 0 sec with messages’ just to finish up. 

There is a preclosestack which is intentionally empty. The preopenCard and 
openCard of the first card in the mainStack only recall data from one of the 
library stacks into globals. Then runs a centreMe handler from the mainStack 
script which is just a ‘set the loc of this stack to the screenloc’. 

And that is it. No closeStack handler. 

I can reproduce it every time I do a saveAs. 

The ‘save/purge/cancel’ is only intuitive to you it seems because you 
understand the background. It doesn’t seem to make sense to us (and certainly 
not a newcomer) because we have only our experience from other software to go 
on and how we expect it to work. If we do a saveAs in any other ware, we would 
never see a purge option. Maybe just an ‘are you sure’ or a ‘this will have 
this kind of effect’ warning. So we would never expect this kind of behaviour 
from software and know what to do with it. Hence the immediate initial 
responses to my OP (which were hilarious by the way, much needed light relief). 

Thanks yet again. 

Sean

___
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: OT: Priorities (was: Re: Stack with the same name loop)

2021-10-07 Thread Bob Sneidar via use-livecode

+1. Gave me the heebie jeebies when they announced the Open Source model. 

I survived the age of freeware. There were a LOT of people back then who opined 
that ALL software ought to be free! It was staggering. There were great 
repositories of commerial titles, and I mean the big stuff, that had been 
cracked so that they no longer required a license key. I knew people I worked 
with back then who made ample use of these. 

Maybe in the imaginary world of Star Trek, there is no more money and everyone 
just works for the joy of it, receiving nothing more than food, shelter, 
clothing and gratitude, but in the real world, people need to obtain those 
things for themselves. 

I say the people at Livecode LTD. deserve all the recompense they can get, and 
by the way, we should be thankful to Steve Jobs who gave us Hypercard (and 
actually convinced Apple to give it away for free!) 

Bob S

> On Oct 7, 2021, at 03:04 , Bernard Devlin via use-livecode 
>  wrote:
> 
> At least the new licensing model should allow LC to prioritise based on
> what customers use.
> 
> IMO the open source initiative was the single biggest mistake LC Ltd made.
> With that drain on resources over hopefully they can get to work on fixing
> some of the outstanding deficiencies.

___
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: Stack with the same name loop

I would be more of a fan of lowering the engine check to just a warning vice a 
hard error/prohibition.  Like you said, if you don’t use the long name then 
most of the time you are going to reference the earliest opened version of the 
stack (based on the linked list of open stacks).  But if you reference an 
object within the same stack (or at least the visible card), it can reference 
by short name.  I guess I should expand my test stack to check that.

I can see a couple of ways to implement this where it would not impact existing 
code.  First would be a global flag to enable opening of files with the same 
name (default to off/false).  The second would be a “force” parameter to the 
open command which would bypass the check.

Sent from my iPhone

> On Oct 7, 2021, at 11:17 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2021-10-07 15:57, Brian Milby via use-livecode wrote:
>> Clone stack avoids the check.  It is not that hard to get multiple
>> stacks with the same short name but different long names in memory (in
>> a standalone).  The engine makes sane choices when referencing the top
>> stack in that case.  Any individual stack can be referenced via the
>> long name.
> 
> Yes indeed, you don't actually need to even use clone stack - just 'set the 
> name of' will do it.
> 
> However, the fact you can do that from script is a different case from what 
> the IDE should let you do in the normal course of things (and indeed, perhaps 
> we should plug the holes in the engine which let it happen) in (a perhaps 
> vain?) attempt to stop people tying themselves into too many knots.
> 
> Things like the 'topStack' and 'defaultStack' are only sane references to the 
> actual underlying stack if they are used as direct syntax (where they resolve 
> to the internal pointer). As soon as they are rendered to a string (e.g. when 
> passed as an argument) that link is gone - further, if a stack has not been 
> saved then there is no way to distinguish one from the other with any 
> string-based reference (a stack's long id is only different from its name / 
> long name if it has a filename).
> 
> 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

___
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: Stack with the same name loop


On 2021-10-07 15:38, Mark Waddingham via use-livecode wrote:

On 2021-10-07 15:26, Pi Digital via use-livecode wrote:

Hi Mark (both :) )

Thanks for your explanation. Very thorough.

What I don’t understand is why the engine needs to delete the old
reference (weak handle) when invoking a ‘save as’. Is it not just a
matter of resaving you a new location and making the pointer to the
storage device for that instance? Why does it need to save it and then
remove from memory at all? Just carry on with what is already in
memory without the need to reload. That’s why we use a ‘save as’
anyway.


This isn't related to 'Save As' - nor is the engine doing anything
here beyond sending a message - which is enforcing the 'only one main
stack with a given (short) name exists in memory at any one time'
invariant.


Sorry Sean this thread had gone on through several things that I missed 
what you said in your original post...


You explicitly said you were getting that dialog when doing a 'Save As' 
(presumably from the file menu)... There must be more to it than that 
though.


The 'Save As' menu item in the IDE uses (with a bit of cruft around it) 
'save stack ... as ' - all that does is serialize the stack 
(as it is in memory) to the new file, and update the filename of the 
stack in memory.


There should be no reloadStack mechanism (as outlined above) going on 
*unless* something is causing a message to fire which is trying to load 
the stack from the previous filename.


Indeed, is this a multi-stack system which you are working on? Is there 
a way your code (which is being triggered somehow after save) is 
referencing the stack you just saved as, by its original filename?


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: Stack with the same name loop

2021-10-07 Thread Bob Sneidar via use-livecode

Mark, 

Yes, building standalones is a huge problem. I think that when a single 
platform standalone is created, the state Livecode ends up in ought to be the 
state Livecode started in before you built the standalone. This does not seem 
to be the case. Stacks opened during the build process seem to remain open, but 
are the versions that were saved when building the standalone, and NOT the ones 
belonging to the project. Try building a Windows AND a MacOS standalone in a 
single pass. 

Of course, it's easy for me to imagine how this could be done, but I suppose 
like most things, it's harder than I imagine. 

Bob S

> On Oct 7, 2021, at 07:26 , Craig Newman via use-livecode 
>  wrote:
> 
> RE: the “purge/save/cancel” thing.
> 
> I see this exactly twice whenever I build a standalone for a particular 
> project. Even in a new session, if the first thing I do is build a standalone 
> from the splash stack, I will twice get a dialog during the process asking me 
> the three questions. I always “purge”, and always everything works out fine.
> 
> But the only stack I open in that new session is the splash stack itself, 
> running the build directly from there. 
> 
> The splash stack opens a mainStack in normal operation, and this may have 
> something to do with the presentation of the dialog.
> 
> Craig
> 

___
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: OT: Priorities (was: Re: Stack with the same name loop)

Heather politely called cheese on this topic some time ago. May we
please respect the wishes of the list owner?

--
Richard Gaskin
Fourth World Systems

Bob Sneidar wrote:

+1. Gave me the heebie jeebies when they announced the Open Source model.

I survived the age of freeware. There were a LOT of people back then who opined that ALL software ought to be free! It was staggering. There were great repositories of commerial titles, and I mean the big stuff, that had been cracked so that they no longer required a license key. I knew people I worked with back then who made ample use of these.

Maybe in the imaginary world of Star Trek, there is no more money and everyone just works for the joy of it, receiving nothing more than food, shelter, clothing and gratitude, but in the real world, people need to obtain those things for themselves.

I say the people at Livecode LTD. deserve all the recompense they can get, and by the way, we should be thankful to Steve Jobs who gave us Hypercard (and actually convinced Apple to give it away for free!)

Bob S

On Oct 7, 2021, at 03:04 , Bernard Devlin via use-livecode wrote:

At least the new licensing model should allow LC to prioritise based on
what customers use.

IMO the open source initiative was the single biggest mistake LC Ltd made.
With that drain on resources over hopefully they can get to work on fixing
some of the outstanding deficiencies.

___
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: Stack with the same name loop


On 2021-10-07 17:10, Pi Digital via use-livecode wrote:

The ‘save/purge/cancel’ is only intuitive to you it seems because you
understand the background. It doesn’t seem to make sense to us (and
certainly not a newcomer) because we have only our experience from
other software to go on and how we expect it to work. If we do a
saveAs in any other ware, we would never see a purge option. Maybe
just an ‘are you sure’ or a ‘this will have this kind of effect’
warning. So we would never expect this kind of behaviour from software
and know what to do with it. Hence the immediate initial responses to
my OP (which were hilarious by the way, much needed light relief).


As I said, this isn't anything to do with 'Save As' specifically - 'Save 
As' is doing precisely what you would expect... i.e. Saving the 
stackfile to a different file, and just as when you do that in any other 
application the filename of the stack changes to be the new filename.


What you are seeing is the mechanism which is in place to prevent two 
mainstacks of the same name being loaded into memory at once. That 
mechanism *only* occurs *if* something has attempted to load a stack 
into memory when there is already one with the same name (but a 
different filename).


The question to ask is why, in your case, 'everytime you do a Save As' 
is that mechanism triggered? i.e. There must be some script that is 
running somewhere (whether it be IDE, plugin, or code in one of the 
project's stacks) which is causing it.


So the first thing to ask is, is the recipe as simple as:

  1) Select stack you want to 'Save As'
  2) File > Save As
  3) Give a different name and Save
  4) Duplicate name Save/Purge/Cancel dialog appears?

Or is there any more to the recipe?

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: Stack with the same name loop


On 2021-10-07 17:25, Brian Milby via use-livecode wrote:

I would be more of a fan of lowering the engine check to just a
warning vice a hard error/prohibition.  Like you said, if you don’t
use the long name then most of the time you are going to reference the
earliest opened version of the stack (based on the linked list of open
stacks).  But if you reference an object within the same stack (or at
least the visible card), it can reference by short name.  I guess I
should expand my test stack to check that.


I'm not quite sure how the engine would give a warning - the behavior 
being discussed in this thread is the way the IDE deals with how the 
engine deals with a specific case...


In general, the engine will either let something happen or it won't. In 
this specific case, it doesn't let implicit opens of stacks (which is 
what all initial openings of stacks are when you use a 'stack ' 
chunk are - given the potential disconnect between what  is, and 
what stackfile might actually be loaded) proceed if there is already a 
stack with the same name in memory...


However it *does* send a message 'reloadStack' that can be handled so 
script can decide what to do.


Indeed, this handler could happily let things go ahead:

  on reloadStack pStackName, pPath
local tOldFilename
set the name of stack pStackName to (pStackName & "~")
put the filename of stack pStackName into tOldFilename
set the filename of stack pStackName to "this is a unique name"
go stack pPath
set the name of stack "this is a unique name" to pStackName
  end reloadStack

The IDE chooses not to do this to stop the large number of other issues 
which could arise from having multiple stacks in memory with the same 
name (in an environment where it might happen 'by accident', rather than 
for any particularly controlled reason as might be the case in a 
standalone environment written to cope with it).



I can see a couple of ways to implement this where it would not impact
existing code.  First would be a global flag to enable opening of
files with the same name (default to off/false).  The second would be
a “force” parameter to the open command which would bypass the check.


I guess my real question here is what would be the purpose of that? i.e. 
What problem does it solve?


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: Stack with the same name loop

2021-10-07 Thread J. Landman Gay via use-livecode

For me, the confusion would be resolved if the Save button was renamed to 
"Save and Purge". I was never quite sure what that button saved, though in 
retrospect it's pretty obvious.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 7, 2021 9:39:43 AM Mark Waddingham via use-livecode 
 wrote:


If you choose 'Cancel' it takes no action - so nothing changes (no new
stack loaded, no old stack deleted).

If you choose 'Purge' the IDE does its best to remove the current stack
in memory and *then* trys to load the new stack (from the different
filepath) - as (in principal) there is no longer any stack in memory
with the conflicting name, then engine loads it and things carry on.

If you choose 'Save' the IDE does the same as above except that *before*
it tries to remove the current stack from memory, it saves (save as, if
the current stack has no filename).




___
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: Stack with the same name loop

Standalone building needs to be a separate process.

In the olden days, standalones were build by merging the stack file on 
disk with the engine, with no changes or additions to objects inside the 
stack.

When new features were introduced which requiring adding library button 
inside a newly-created group on the mainstack's first card, then later 
adding more options to add and separate substacks/other stack files, the 
build process became much more complex.

In the olden days you could be deep in your work context, running your 
app with specific windows open with certain data set up just as you need 
it to observe what you're working on, then select "Build Standalone" and 
nothing you've so carefully arranged is at all altered; the standalone 
is quickly built in a second or so and you can continue with what you're 
doing.

Accommodating the newer stack-altering features has created a world in 
which you lose your work context, windows appear and disappear in a 
dizzying display, it sometimes takes a very long time, and when 
everything settles down if it all goes well and the jostling finally 
subsides, you're left with a work context that has your mainstack open 
but everything else you've carefully arranged is gone.

Tons of code have been added to the IDE to account for the many 
implications that come along with attempting to make copies of stacks in 
memory, initializing them to be able to add/modify them, doing those 
mods, and then attempting to restore at least the bare minimum of the 
work context you'd had.

Along the way, all that added IDE code has led to side-effects, like 
those discussed in this thread.

As a separate process, the Standalone Builder need not bother with any 
concern about duplicate stacks at all, because there wouldn't be any.

But the biggest benefit is restoring the smooth, enjoyable workflows we 
once had, back when we didn't have to pause to ask ourselves if we 
really need to make that test build, because doing so will dramatically 
alter our workspace.

Bonus that new users won't have to watch the parade of stacks flashing 
about during the sometimes-lengthy process.

--
 Richard Gaskin
 Fourth World Systems

Bob Sneidar wrote:

> Yes, building standalones is a huge problem. I think that when a
> single platform standalone is created, the state Livecode ends up
> in ought to be the state Livecode started in before you built the
> standalone. This does not seem to be the case. Stacks opened during
> the build process seem to remain open, but are the versions that were
> saved when building the standalone, and NOT the ones belonging to the
> project. Try building a Windows AND a MacOS standalone in a single
> pass.
>
> Of course, it's easy for me to imagine how this could be done, but I
> suppose like most things, it's harder than I imagine.

___
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-10-07 Thread Ralph DiMola via use-livecode

"complete" status only means that the process is complete. A purchase is
only complete if "complete" is preceded by a "paymentReceived" or in the
case of a user with a new device "restored". At least that's the way I
understand it. This logic has worked for me.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay via use-livecode
Sent: Wednesday, October 06, 2021 4:33 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: IAP in App Store

I'm confused about how the purchase flow works so my question is probably
incorrect. There is no error when I see the "complete" status, it only shows
up in my logging file. After adding additional logging, it looks like
"complete" is sent after every transaction. But if something goes wrong,
like asking for a product that isn't in the Play Store yet, there are no
status reports except "complete." The app doesn't receive any other info and
Android doesn't display any dialog. Seems like I should get an "invalid sku"
status error.

Here's part of the log where I made a successful test purchase (product ID
obscured):

***
Wed, 6 Oct 2021 14:12:55 -0500 BEGIN IAP PURCHASE: 
   -- purchaseStateUpdate logs this:
Wed, 6 Oct 2021 14:13:15 -0500 Purchase state:  paymentReceived
| PurchaseID: 3

   -- fullfillment handler logs this and sends info to back end server:
Wed, 6 Oct 2021 14:13:15 -0500 Purchase complete: true |  |
paymentReceived Wed, 6 Oct 2021 14:13:15 -0500 queryServer about to query
for newPurchase Wed, 6 Oct 2021 14:13:15 -0500 newPurchase params:
{"packageid": "","transaction_id": "3","source": "android"}

   -- and finally purchaseStateUpdate returns "complete":
Wed, 6 Oct 2021 14:13:15 -0500 Purchase state:  complete |
PurchaseID: 3
***

I'm working in the internal test track and the choices in the test purchase
dialog do not include a Cancel button. To cancel, I tap outside the dialog
and it goes away. Sometimes I get an email about my "purchase" (which is
normal) and usually it verifies a cancellation. But one email had some
additional test info:

"This test purchase was cancelled because it was not acknowledged. You
should ensure all purchases are acknowledged so they are not subject to
refunds. For more information see
https://developer.android.com/google/play/billing/integrate#process.;

I just repeated the same cancellation method just now and did not get that
warning in email. I didn't actually get an email at all.

One faintly amusing thing is that Google is counting my unpaid test
purchases as real ones in their Play Points history, and yesterday I
acquired enough points to rent a free movie and advance to level Silver for
additional benefits. :)

Given how complex their IAP store setup is, I think that's only fair.

On 10/6/21 11:40 AM, panagiotis m via use-livecode wrote:
> Hello Jacque,
> 
> What is the exact error that causes purchaseStateUpdate to be sent 
> with a "complete" status?
> Google is supposed to show its own notification in most cases, so 
> that's fine, but then the purchaseStateUpdate should be sent with an 
> appropriate status anyway.
> 
> Kind regards,
> Panos
> --
> 
> 
> 
> On Tue, 5 Oct 2021 at 20:54, J. Landman Gay via use-livecode < 
> use-livecode@lists.runrev.com> wrote:
> 
>> I guess this is for @Panos.
>>
>> Now that I have IAP working I noticed another thing. I'm building for 
>> Android with LC 9.6.5
>> RC-1 which includes the new billing library. My script has a 
>> purchaseStateUpdate handler that logs every response and sends the 
>> info to a IAPPurchaseComplete handler that manages the purchase or 
>> the error. If there is an error this handler puts up a dialog 
>> informing the user.
>>
>> I notice any error is not received by the handler, instead Google 
>> puts up its own notification and the status returns as "complete". My 
>> notification never runs. That's fine and it looks better than my own 
>> but I'm curious whether something has changed in the new billing 
>> library, and if so, what.
>>
>> --
>> 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
>>
> ___
> 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
> 

-- 
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing

Re: Stack with the same name loop

Brian Milby wrote:

> Clone stack avoids the check.  It is not that hard to get
> multiple stacks with the same short name but different
> long names in memory (in a standalone).

Clone alters the name of the new clone stack.  The engine prepends it 
with "Copy of ".

AFAIK it's done that since 1998.

FWIW I did some extensive research on duplicate stack names issues about 
four years ago, attempting to pin down how the engine behaves and what 
the IDE does.

https://quality.livecode.com/show_bug.cgi?id=1061#c20

TL/DR: The engine has no problem with duplicate short stack names, but 
some IDE needs will be compromised until there is an adjustment to how 
the engine internally resolves short stack name references;

Currently the old MC implementation remains in place in which those are 
resolved by load order (which is almost never what any scripter needs), 
but more useful would be layer/message path order (which is what most 
scripts and esp IDE tools need).

--
 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: Stack with the same name loop

I was not aware of the rename possibility, so it would be possible to produce a 
plug-in that would use your code snip to allow a duplicate named stack to open.

The only time I’ve really run into this is with “Untitled 1” stacks.  I’ve done 
something quick and saved it without changing the stack name.  Then opening two 
of those such stacks is an issue.  This is about the only time I would want to 
have two same name stacks open (and would probably rename them anyway once both 
were open).

I think this falls in the realm of something that could be done but there isn’t 
much real reason that it is needed.  That does assume that the engine isn’t 
changed to remove the options that currently exist.  I only really started 
looking at it due to the old bug reports that come up every year or two.

Thanks for your comments Mark!  Very enlightening.

Brian

Sent from my iPhone

> On Oct 7, 2021, at 12:44 PM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2021-10-07 17:25, Brian Milby via use-livecode wrote:
>> I would be more of a fan of lowering the engine check to just a
>> warning vice a hard error/prohibition.  Like you said, if you don’t
>> use the long name then most of the time you are going to reference the
>> earliest opened version of the stack (based on the linked list of open
>> stacks).  But if you reference an object within the same stack (or at
>> least the visible card), it can reference by short name.  I guess I
>> should expand my test stack to check that.
> 
> I'm not quite sure how the engine would give a warning - the behavior being 
> discussed in this thread is the way the IDE deals with how the engine deals 
> with a specific case...
> 
> In general, the engine will either let something happen or it won't. In this 
> specific case, it doesn't let implicit opens of stacks (which is what all 
> initial openings of stacks are when you use a 'stack ' chunk are - 
> given the potential disconnect between what  is, and what stackfile 
> might actually be loaded) proceed if there is already a stack with the same 
> name in memory...
> 
> However it *does* send a message 'reloadStack' that can be handled so script 
> can decide what to do.
> 
> Indeed, this handler could happily let things go ahead:
> 
>  on reloadStack pStackName, pPath
>local tOldFilename
>set the name of stack pStackName to (pStackName & "~")
>put the filename of stack pStackName into tOldFilename
>set the filename of stack pStackName to "this is a unique name"
>go stack pPath
>set the name of stack "this is a unique name" to pStackName
>  end reloadStack
> 
> The IDE chooses not to do this to stop the large number of other issues which 
> could arise from having multiple stacks in memory with the same name (in an 
> environment where it might happen 'by accident', rather than for any 
> particularly controlled reason as might be the case in a standalone 
> environment written to cope with it).
> 
>> I can see a couple of ways to implement this where it would not impact
>> existing code.  First would be a global flag to enable opening of
>> files with the same name (default to off/false).  The second would be
>> a “force” parameter to the open command which would bypass the check.
> 
> I guess my real question here is what would be the purpose of that? i.e. What 
> problem does it solve?
> 
> 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

___
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: Stack with the same name loop