Re: Smooth scrolling

2021-02-04 Thread Trevor DeVore via use-livecode
On Tue, Feb 2, 2021 at 4:25 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> JeeJeeStudio wrote:
>
>  > Panos wrote:
>  >> This bug report contains a workaround for smooth scrolling - hope it
>  >> helps.
>  >> https://quality.livecode.com/show_bug.cgi?id=19759
>  >
>  >
>  > Maybe it's me but i don't see any difference in scrolling between the
>  > left and right on win10
>
> The original description of the problem here lacks specificity. It's not
> just any scrolling that is affected, but scrolling that happens in
> response to a scroll wheel or trackpad gestures.
>
> The script Panos posted in the bug report has two gradations of scroll
> increment, based on the interval between keydown messages corresponding
> to the scroll wheel/trackpad gesture.
>

I came across this thread and thought I would add an additional comment.
The scrolling can be improved further by using the scroll event values
provided by the operating system.

On macOS it is simple enough to get the true scroll values from the scroll
event using NSEvent.scrollingDeltaX and NSEvent.scrollingDeltaY. It is
possible to get those values using LCB as demonstrated in the
mac_scroll_wheel.lcb extension that is included with the DataView control
I've made available. Here is a link to the source code:

https://github.com/trevordevore/levurehelper-dataview/blob/develop/mac_scroll_wheel.lcb

Anyone who is interested and running macOS can download the compiled
version of the extension and test it out in the sample stack.

1) Visit the following link and click the "Download" button

https://github.com/trevordevore/levurehelper-dataview/blob/develop/mac_scroll_wheel.lcm

2) Then run this in the Message Box and select the .lcm file to load it:

answer file "Select Extension";load extension from file it;put the result

3) Add this script to any field you want to test with:

on rawKeyDown pKey

  if pKey = "65308" or pKey = "65309" then
set the vscroll of me to the vscroll of me - item 2 of
macCurrentEventScrollValues(the effective linesize of me)
  else
pass rawKeyDown
  end if

end rawKeyDown

On my computer I see the best results in the test stack from the bug report
using this method. Ideally any engine improvements would tap into the
scroll wheel values provided by the OS.

-- 
Trevor DeVore
ScreenSteps
___
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: Double sided PDF Problem

2021-02-04 Thread Curry Kenworthy via use-livecode



Richard:

> they still offer a business card size with rounded corners -
> I'm taking it as a challenge to bring the card content
> down to just the essentials. ;)
> https://www.avery.com/products/cards/88220

Thanks for that link - good idea! Mini cards look great.

I doubt my own hands can manipulate that small size, though.
Maybe I'll use printed labels on blank playing cards for creative stage.
Then order the final design from a pro printing service.

Paul:

> I currently work for the company that owns that brand.

That's neat! I enjoyed your comments.

BTW, encourage 'em to restock some products like #4785!
(COVID may have increased the need for both DIY games and Ed, right?)

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: Close Stack Cleanup

2021-02-04 Thread Mark Wieder via use-livecode

On 2/4/21 6:33 PM, Curry Kenworthy via use-livecode wrote:


The preOpenStack handler is NOT ideal for this type of cleanup.
"Literally, to "clear the fields" of a stack."
(And now we also know, a "complex" stack.)
That is NOT something best done in preOpenStack.

A complex stack usually has multiple cards.
The user is going from one card to the other - perhaps more than once.
You need this type of cleanup triggered by preOpenCard!
Whereas preOpenStack and startup are better for general init.
Keep it modular; preOpenCard and Clear Form can call the same code.


Ah... quite right. I do stand corrected there.

--
 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: Close Stack Cleanup

2021-02-04 Thread Curry Kenworthy via use-livecode



Mark:
> I agree with others that this isn't a Good Idea,
> and a cleaning routine in preOpenStack would do the trick nicely.

Amen, Brother Mark! Good Idea to avoid Bad Habits.
(Agreed, except a small but crucial difference in details)

As Tore said:
> execute the necessary routines as part of a preOpenStack handler

Again, with a small but important difference:

The preOpenStack handler is NOT ideal for this type of cleanup.
"Literally, to "clear the fields" of a stack."
(And now we also know, a "complex" stack.)
That is NOT something best done in preOpenStack.

A complex stack usually has multiple cards.
The user is going from one card to the other - perhaps more than once.
You need this type of cleanup triggered by preOpenCard!
Whereas preOpenStack and startup are better for general init.
Keep it modular; preOpenCard and Clear Form can call the same code.

(You both already probably know that and do it.
Just making an explicit point for other readers who are learning.
People always tell me things they read here! They take it to heart.)

If you clean up fields in preOpenCard, you're ready for the end user.
But your saved stack may be very BLOATED at times!
Large amount data in a field, image, etc.

(And yes, in these days of interim-capacity SSDs, disk space matters.
Your stack will also be saved in a more cluttered state.)

To solve that easily, as I've said: use saveStackRequest!

That way your stack is SAVED clean and non-bloated.
You can freely test larger data samples.
Stacks are small for sharing within your dev team.

Your users will NEVER see your test data entries.
(Even if a preOpenX handler fails due to runtime bug,
which I've seen happen fairly often in stacks people make!
Potential embarrassments automatically averted.)
It's also perfect for simpler stacks with one card.

Bob:
> Back to the drawing board.

Not if you take the advice of myself and others!
Proven solutions, well-tested over time, reliable, that work TODAY.
(But I do like the IDE bug report; the IDE tramples some messages.)
Good topic! People will learn from it. Thanks for starting it.

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: Close Stack Cleanup

2021-02-04 Thread J. Landman Gay via use-livecode
I did a test before answering and the message was sent to the card of my 
otherwise blank stack, after dismissing the IDE dialog. That makes me think 
something is going on with your particular stack. What happens if you try 
it with a plain new stack?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 4, 2021 6:07:32 PM Bob Sneidar via use-livecode 
 wrote:


Thanks Ralph. Actually what I am looking for is a message that gets sent 
when the close button of a window gets clicked. The Message Watcher seems 
to indicate not (or rather fails to indicate). I think this is a bug, or at 
least an oversight. This means that anyone can close a stack, and 
closeStackRequest will not get triggered. This seems contrary to what 
closeStackRequest is for.


I will submit a feature request, but I suspect it’s going to be low on the 
totem pole.


Bob S


On Feb 4, 2021, at 3:53 PM, Ralph DiMola via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:


Is this what you're looking for?

revIDESetEdited pStackName
revIDESetUnedited pStackName

Interrogate it with: revIDEStackIsEdited pStackName

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

___
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: Close Stack Cleanup

2021-02-04 Thread J. Landman Gay via use-livecode
That looks like it would work though it isn't the variable I remember. 
Probably that's what changed. Nice sleuthing.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 4, 2021 5:52:14 PM Ralph DiMola via use-livecode 
 wrote:



Is this what you're looking for?

revIDESetEdited pStackName
revIDESetUnedited pStackName

Interrogate it with: revIDEStackIsEdited pStackName

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: Thursday, February 04, 2021 5:53 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: Close Stack Cleanup

There used to be a gREV* global variable that tracked the dirty status and 
if the stack was dirty it put up the "do you want to save?" dialog. I can't 
find it now so something has changed. When it existed, you could toggle 
that variable via script and the IDE wouldn't bother you.


The IDE does pass the closeStackRequest to your stack after it checks the 
stack status. The docs are correct that you don't get that message when a 
script closes the stack but you can use closeStack instead; however, first 
we need to find out where that variable went to. It used to be in the 
globals pane of the message watcher, and I'd recognize it if I saw it, but 
I can't remember now what it was.


On 2/4/21 12:59 PM, Bob Sneidar via use-livecode wrote:

Hi all.

I know we have tread this ground before, but I am trying to clean up my 
stack (i.e. clear the fields), then save it when I close it BY ANY MEANS. 
That means by script, by menu OR by clicking the red dot (of for WIN users 
the red X) in the title bar. I need this to work in the IDE as well as in 
standalone.


You would think closeStackRequest gets sent when I click the red dot or X. 
You would be mistaken.


The dictionary reads,

The closeStackRequest message is only sent if the request to close a stack 
is initiated by the user (eg by clicking file -> close in the LiveCode 
menu). If the request is initiated from a script (eg "close this stack" ) 
then the closeStackRequest message is not sent.


Apparently clicking the red dot is not considered, “initiated by the user.” 
It ought to be.


If I use “CloseStack” instead, I cannot save the stack because a script is 
currently running, and I do not want to be presented with the dialog to 
save, do not save, or cancel. I just want it to be saved. I can force quit 
if I mess something up.


Bob S

___
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 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: Close Stack Cleanup

2021-02-04 Thread Mark Wieder via use-livecode

On 2/4/21 4:19 PM, Bob Sneidar via use-livecode wrote:

NVM I found this bug has already been submitted… IN 2008! LOL! 
https://quality.livecode.com/show_bug.cgi?id=4617 Hey Kevin! 


Looking at that, here's a (completely untested) suggestion:

The revIDEHandleCloseStackRequest handler is in the IDE backscript, so 
it's ready to be overridden. If you don't override it then it executes a 
revSaveCheck before moving on. If you override this command then you 
might get what you want.


...at the risk of losing data...

so maybe in your stack script you have:
on revIDEHandleCloseStackRequest
  return "pass"
end revIDEHandleCloseStackRequest

That said, I agree with others that this isn't a Good Idea, and a 
cleaning routine in preOpenStack would do the trick nicely.


--
 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: Close Stack Cleanup

2021-02-04 Thread Bob Sneidar via use-livecode
NVM I found this bug has already been submitted… IN 2008! LOL! 
https://quality.livecode.com/show_bug.cgi?id=4617 Hey Kevin! 

Bob S


On Feb 4, 2021, at 4:05 PM, Bob Sneidar via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Thanks Ralph. Actually what I am looking for is a message that gets sent when 
the close button of a window gets clicked. The Message Watcher seems to 
indicate not (or rather fails to indicate). I think this is a bug, or at least 
an oversight. This means that anyone can close a stack, and closeStackRequest 
will not get triggered. This seems contrary to what closeStackRequest is for.

I will submit a feature request, but I suspect it’s going to be low on the 
totem pole.

Bob S

___
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: Close Stack Cleanup

2021-02-04 Thread Bob Sneidar via use-livecode
Thanks Ralph. Actually what I am looking for is a message that gets sent when 
the close button of a window gets clicked. The Message Watcher seems to 
indicate not (or rather fails to indicate). I think this is a bug, or at least 
an oversight. This means that anyone can close a stack, and closeStackRequest 
will not get triggered. This seems contrary to what closeStackRequest is for.

I will submit a feature request, but I suspect it’s going to be low on the 
totem pole.

Bob S


On Feb 4, 2021, at 3:53 PM, Ralph DiMola via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Is this what you're looking for?

revIDESetEdited pStackName
revIDESetUnedited pStackName

Interrogate it with: revIDEStackIsEdited pStackName

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

___
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: Close Stack Cleanup

2021-02-04 Thread Ralph DiMola via use-livecode
Is this what you're looking for?

revIDESetEdited pStackName
revIDESetUnedited pStackName

Interrogate it with: revIDEStackIsEdited pStackName

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: Thursday, February 04, 2021 5:53 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: Close Stack Cleanup

There used to be a gREV* global variable that tracked the dirty status and if 
the stack was dirty it put up the "do you want to save?" dialog. I can't find 
it now so something has changed. When it existed, you could toggle that 
variable via script and the IDE wouldn't bother you.

The IDE does pass the closeStackRequest to your stack after it checks the stack 
status. The docs are correct that you don't get that message when a script 
closes the stack but you can use closeStack instead; however, first we need to 
find out where that variable went to. It used to be in the globals pane of the 
message watcher, and I'd recognize it if I saw it, but I can't remember now 
what it was.

On 2/4/21 12:59 PM, Bob Sneidar via use-livecode wrote:
> Hi all.
> 
> I know we have tread this ground before, but I am trying to clean up my stack 
> (i.e. clear the fields), then save it when I close it BY ANY MEANS. That 
> means by script, by menu OR by clicking the red dot (of for WIN users the red 
> X) in the title bar. I need this to work in the IDE as well as in standalone.
> 
> You would think closeStackRequest gets sent when I click the red dot or X. 
> You would be mistaken.
> 
> The dictionary reads,
> 
> The closeStackRequest message is only sent if the request to close a stack is 
> initiated by the user (eg by clicking file -> close in the LiveCode menu). If 
> the request is initiated from a script (eg "close this stack" ) then the 
> closeStackRequest message is not sent.
> 
> Apparently clicking the red dot is not considered, “initiated by the user.” 
> It ought to be.
> 
> If I use “CloseStack” instead, I cannot save the stack because a script is 
> currently running, and I do not want to be presented with the dialog to save, 
> do not save, or cancel. I just want it to be saved. I can force quit if I 
> mess something up.
> 
> Bob S
> 
> ___
> 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 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: Close Stack Cleanup

2021-02-04 Thread Bob Sneidar via use-livecode
 Back to the drawing board. This does NOT work when clicking the red dot.

Bob S


On Feb 4, 2021, at 3:10 PM, Bob Sneidar via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Thanks for the reply Jacque. I ran the message watcher while clicking the red 
dot. None of the messages that appear have anything to do with closing the 
stack.

Here’s what I came up with. The closeStackRequest is NOT getting sent to the 
current card as the dictionary indicates, although the target IS the current 
card. It DOES get sent to the stack though. So I put this in the stack script 
and it DOES work with the red dot.

on closeStackRequest
  if the short name of the target is "Main” then — I have substacks but no 
other cards called Main
 dispatch resetMainForm to the target
  end if

  save this stack
  pass closeStackRequest
END closeStackRequest

Bob S

___
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: Close Stack Cleanup

2021-02-04 Thread Bob Sneidar via use-livecode
Thanks Curry. That works for the IDE, but not for the standalone. End Users do 
not save their stacks, as I give them no way to do so. The stacks in my app 
perform two functions: An interface to control the app and also a place to 
store persistent data i.e. properties. If a user force-quits my app for any 
reason, saving upon closing a sub stack ensures those updated properties are 
retained.

I could test for the IDE I know, but for my purposes, having lost so much form 
modifications in the past due to some kind of race condition or IDE lock up, I 
auto-save regularly, not just when I close a stack.

As an aside, this is what was slowing my Windows Standalones down so much. It 
has been well documented that the performance of saving a stack (especially one 
as complex as mine) in Windows is fairly oppressive. In a Windows Standalone I 
have to trap most of the times I save a stack, allowing only for saving upon 
close.

Bob S


On Feb 4, 2021, at 3:17 PM, Curry Kenworthy via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Me again:

Don't think "clean up and save." Keep the twain separate.
I choose when to save, it's a conscious choice, and it fires my cleanup.
My stack is almost always saved clean.

___
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: Close Stack Cleanup

2021-02-04 Thread Curry Kenworthy via use-livecode



Tore:

> I do not do any clean up at closing time. Instead I execute
> the necessary routines as part of a preOpenStack handler.
> I then do not have to consider which way the stack was closed.

Yes! Like you, for cleanup I also avoid that how-closed consideration.
Much easier to have a simpler single trap.

Yet I ALSO avoid saving user/test data!
That keeps my files smaller in their saved state.

And if opened with messages off, still cleaner

Bob:

> when I open the stack the next time I do not want to
> remains of what I was doing before to show.

You can! Several routes to choose. Presenting the easiest.

Me again:

> I perform cleanup when I save.

In other words, try saveStackRequest!
Don't "save" with your own code; let LC IDE do that.
Just perform your cleanup, then pass.
That way your cleaned-up stack is reliably saved.

You get the best of both - simple trap, reliable.

(However, your original method would work - if you finish it!
And while typing this, I see you already made progress; that's good.)

Tore again:

> By keeping it modular, the clean up script can also
> be started from other handlers if necessary.

Agreed!
Modularity increases performance, maintainability, and freedom.
Can't stress this enough.

Me again:

Don't think "clean up and save." Keep the twain separate.
I choose when to save, it's a conscious choice, and it fires my cleanup.
My stack is almost always saved clean.

Moreover I'm in the habit of saving (and backing up) BEFORE closing.
Habits are so important - they avoid needless suffering.

If I do forget my habit, the IDE will prompt me to save.
So I'm still OK - because I haven't disabled the system. It's my backup.
Nor do I rely primarily on that system. It's my backup. ;)

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: Close Stack Cleanup

2021-02-04 Thread Bob Sneidar via use-livecode
It’s my understanding that I am unable to reference objects on a card of a 
stack in a preOpenStack handler. Referencing an object in the stack opens the 
stack triggering a race condition which continually triggers preOpenStack. That 
is from memory though.

Bob S


On Feb 4, 2021, at 2:50 PM, Tore Nilsen via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Performing the clean up in preOpenStack makes it happen before the stack is 
visible, at least according to the dictionary.

"Unlike openStack <>, preOpenStack handlers <> are executed <> before the stack 
window <> appears. Because of this, the preOpenStack handler <> is a good place 
to put code that adjusts the size, position, and appearance of objects <>; the 
changes are made before the stack <> appears."

My experience is that this is true.


Tore

___
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: Close Stack Cleanup

2021-02-04 Thread Bob Sneidar via use-livecode
Thanks for the reply Jacque. I ran the message watcher while clicking the red 
dot. None of the messages that appear have anything to do with closing the 
stack.

Here’s what I came up with. The closeStackRequest is NOT getting sent to the 
current card as the dictionary indicates, although the target IS the current 
card. It DOES get sent to the stack though. So I put this in the stack script 
and it DOES work with the red dot.

on closeStackRequest
   if the short name of the target is "Main” then — I have substacks but no 
other cards called Main
  dispatch resetMainForm to the target
   end if

   save this stack
   pass closeStackRequest
END closeStackRequest

Bob S


On Feb 4, 2021, at 2:52 PM, J. Landman Gay via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

There used to be a gREV* global variable that tracked the dirty status and if 
the stack was dirty it put up the "do you want to save?" dialog. I can't find 
it now so something has changed. When it existed, you could toggle that 
variable via script and the IDE wouldn't bother you.

The IDE does pass the closeStackRequest to your stack after it checks the stack 
status. The docs are correct that you don't get that message when a script 
closes the stack but you can use closeStack instead; however, first we need to 
find out where that variable went to. It used to be in the globals pane of the 
message watcher, and I'd recognize it if I saw it, but I can't remember now 
what it was.

___
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: Codesigning & notarizing

2021-02-04 Thread matthias rebbe via use-livecode
Marty, 
do you experience this problem  also with your demo stack and Xcode 11.3? If 
so, could you create a new standalone from that demo stack and upload it 
somewhere, so i could download it and try to code sign it here?

Btw. Are you code signing for web distribution or Apple store?

Regards,

-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 04.02.2021 um 23:28 schrieb Marty Knapp via use-livecode 
> :
> 
> I just updated to Xcode 11.3 and still have the issue. With revzip included, 
> building with 9.6.2 it works fine *until* I codesign - either with the Levure 
> app packager or with AppWrapper (tried versions 3 and 4) As soon as it starts 
> to launch it crashes. If I take out revzip the app will open fine when code 
> signed.
> 
> If rev zip was damaged it would not work in the unsigned app. Anything else 
> that I should check? This is really frustrating.
> 
> Marty
> 
>> On Feb 4, 2021, at 1:09 PM, panagiotis merakos via use-livecode 
>>  wrote:
>> 
>> Thanks for testing Matthias :)
>> 
>> On Thu, 4 Feb 2021, 23:08 Paul Dupuis via use-livecode, <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> I should have added that we sign with entitlements (the same set LC uses)
>>> 
>>> On 2/4/2021 3:56 PM, panagiotis merakos via use-livecode wrote:
 @Marty
 
 If you have not done it already, it might be worth adding entitlements to
 the codesign.
 
 
>>> https://lessons.livecode.com/m/4071/l/1293515-entitlements-for-signed-and-notarized-apps
 
 I do not think it is the Xcode version that is the problem. I am on
>>> Mojave
 as well, so I can do a quick test if you send me the standalone that
 crashes. Also make sure you attach the stack to the bug report :)
 
 Kind regards,
 Panos
 --
 
 On Thu, 4 Feb 2021 at 22:47, Paul Dupuis via use-livecode <
 use-livecode@lists.runrev.com> wrote:
 
> I should add, we're not using Levure. We are using LC9.6.2rc2, we
> codesign via Terminal on Mohave using Xcode 10.2.1
> 
> On 2/4/2021 3:37 PM, Paul Dupuis via use-livecode wrote:
>> FYI - Our App includes the revZIP library. We codesign deep via
>> Terminal command and get no crashes. Codesign, notarize, and staple
>> without problems.
>> 
>> 
>> On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
>>> Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
>>> library (crashes when codesigned)
>>> 
>>> Just filed a bug report on this - 23083
>>> 
>>> Marty
>>> 
 On Feb 4, 2021, at 11:25 AM, Marty Knapp 
 wrote:
 
 I’ve narrowed this down to the “Revolution Zip” library. If I leave
 that out of Inclusions, I can build in 9.6.2 and codesign and all is
 well.
 
 marty
 
> On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode
>  wrote:
> 
> Hi Marty,
> 
> My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
> 
> I have only a cursory understanding of Levure. From what I read,
> Trevor has methods to codesign and even notarize inside of Levure’s
> framework.
> 
> If your testing with a basic stack works as expected, maybe some
> interaction is happening with the Levure Framework project. I am
> certain Trevor knows best what may be happening here.
> 
> When you find out, please post back what you learn.
> 
> Best regards,
> 
> Mark Talluto
> livecloud.io 
> nursenotes.net 
> canelasoftware.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
> 
> ___
> 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 mai

Re: Close Stack Cleanup

2021-02-04 Thread J. Landman Gay via use-livecode
There used to be a gREV* global variable that tracked the dirty status and if the stack was 
dirty it put up the "do you want to save?" dialog. I can't find it now so something has 
changed. When it existed, you could toggle that variable via script and the IDE wouldn't bother 
you.


The IDE does pass the closeStackRequest to your stack after it checks the stack status. The 
docs are correct that you don't get that message when a script closes the stack but you can use 
closeStack instead; however, first we need to find out where that variable went to. It used to 
be in the globals pane of the message watcher, and I'd recognize it if I saw it, but I can't 
remember now what it was.


On 2/4/21 12:59 PM, Bob Sneidar via use-livecode wrote:

Hi all.

I know we have tread this ground before, but I am trying to clean up my stack 
(i.e. clear the fields), then save it when I close it BY ANY MEANS. That means 
by script, by menu OR by clicking the red dot (of for WIN users the red X) in 
the title bar. I need this to work in the IDE as well as in standalone.

You would think closeStackRequest gets sent when I click the red dot or X. You 
would be mistaken.

The dictionary reads,

The closeStackRequest message is only sent if the request to close a stack is initiated by 
the user (eg by clicking file -> close in the LiveCode menu). If the request is initiated 
from a script (eg "close this stack" ) then the closeStackRequest message is not 
sent.

Apparently clicking the red dot is not considered, “initiated by the user.” It 
ought to be.

If I use “CloseStack” instead, I cannot save the stack because a script is 
currently running, and I do not want to be presented with the dialog to save, 
do not save, or cancel. I just want it to be saved. I can force quit if I mess 
something up.

Bob S

___
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 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: Close Stack Cleanup

2021-02-04 Thread Tore Nilsen via use-livecode
Performing the clean up in preOpenStack makes it happen before the stack is 
visible, at least according to the dictionary.

"Unlike openStack <>, preOpenStack handlers <> are executed <> before the stack 
window <> appears. Because of this, the preOpenStack handler <> is a good place 
to put code that adjusts the size, position, and appearance of objects <>; the 
changes are made before the stack <> appears."

My experience is that this is true.


Tore

> 4. feb. 2021 kl. 23:43 skrev Bob Sneidar via use-livecode 
> :
> 
> Thanks for the response Curry and Tore. 
> 
> The reason I clean up at close is because when I open the stack the next time 
> I do not want to remains of what I was doing before to show. It’s a small 
> point but it look cleaner if the first time opening the stack there is 
> nothing in the fields. All attempts to hide the stack then clear it before 
> making it visible have been iffy. 
> 
> I guess what I need is a message or series of messages that get generated 
> BEFORE the stack is closed. 
> 
> I have this in the only card in my stack: 
> 
> on closeStackRequest
>   resetMainForm
>   save this stack
>   pass closeStackRequest — this has a breakpoint
> end closeStackRequest
> 
> I have a breakpoint on the pass statement. When clicking the red dot I get 
> asked if I want to save the stack. For whatever reason, for me the 
> closeStackRequest is NOT getting sent to the current card! 
> 
> Bob S
> 
> 
>> On Feb 4, 2021, at 1:23 PM, Curry Kenworthy via use-livecode 
>>  wrote:
>> 
>> 
>> Bob:
>> 
>>> I am trying to clean up my stack (i.e. clear the fields),
>>> then save it when I close it
>> 
>> This is a good topic for LiveCode learners; I'm chiming in
>> 
>> I often do something similar - but with an important difference:
>> I perform cleanup when I save. I do NOT force an auto save.
>> (More on that later.)
>> 
>>> BY ANY MEANS. That means by script, by menu OR by clicking the red dot
>>> (of for WIN users the red X) in the title bar.
>>> I need this to work in the IDE as well as in standalone.
>> 
>> So, let's halt at this point and take inventory of your desires!
>> You want to trap at least 3 methods of initiating a close action.
>> (Tally: 3)
>> 
>> Furthermore, IDE versus Standalone is an extra complexity.
>> I don't like that, but it is the unfortunate reality.
>> So I'm accounting for that extra complexity via a "+" designation!
>> (Tally: "3+")
>> 
>> Now jumping ahead a bit to make a connection:
>> 
>>> If I use “CloseStack” instead
>> 
>> Remember our tally of "3+" Actions?
>> The word "instead" suggests you're assuming a SINGLE trap.
>> 
>> Everyone here should know my KISS philosophy: less is better.
>> 3 birds with one stone is superior; I'm always harping on that.
>> But then again, in this case you have 3+ birds! :)
>> 
>> I'd hazard a guess on 2 traps - that's my experience for similar cases.
>> (But if one will work, use one.)
>> 
>>> You would think closeStackRequest gets sent when I
>>> click the red dot or X. You would be mistaken.
>> 
>> Actually I would NOT be mistaken, as long as we're talking about the X,
>> and the stack has been named/saved at least once. Just tested it!
>> 
>> But among the "extra complexity" I mentioned, if the stack is dirty,
>> the IDE will trap the close action at the front, BEFORE you get it.
>> It can still fire, but AFTER you dance around a bit with the IDE.
>> (Important to note that's the IDE; closeStackRequest does respond.)
>> 
>> To succeed in the IDE, you may indeed need to use closeStack.
>> But that's probably "with" not "instead" of closeStackRequest!
>> 
>> We can still follow KISS and avoid duplicating code,
>> via modularity - the 2 traps can call a common set of code.
>> Using params or other means to handle the differences in the 2/3 cases.
>> 
>>> I just want it to be saved. I can force quit if I mess something up.
>> 
>> I DISCOURAGE using a custom auto-save and resorting to force quit.
>> If you implement an auto-save, do it very well.
>> (And done well, a force-quit would not likely be Plan A for reverting.)
>> 
>> But I encourage cleanup when saving or when closing. I do it constantly.
>> It just requires a set of trap(s) that does spring for the 3 actions.
>> You're half way there, just think "AND" not "instead" to finish it!
>> 
>> 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/mailm

Re: Close Stack Cleanup

2021-02-04 Thread Bob Sneidar via use-livecode
Thanks for the response Curry and Tore. 

The reason I clean up at close is because when I open the stack the next time I 
do not want to remains of what I was doing before to show. It’s a small point 
but it look cleaner if the first time opening the stack there is nothing in the 
fields. All attempts to hide the stack then clear it before making it visible 
have been iffy. 

I guess what I need is a message or series of messages that get generated 
BEFORE the stack is closed. 

I have this in the only card in my stack: 

on closeStackRequest
   resetMainForm
   save this stack
   pass closeStackRequest — this has a breakpoint
end closeStackRequest

I have a breakpoint on the pass statement. When clicking the red dot I get 
asked if I want to save the stack. For whatever reason, for me the 
closeStackRequest is NOT getting sent to the current card! 

Bob S


> On Feb 4, 2021, at 1:23 PM, Curry Kenworthy via use-livecode 
>  wrote:
> 
> 
> Bob:
> 
> > I am trying to clean up my stack (i.e. clear the fields),
> > then save it when I close it
> 
> This is a good topic for LiveCode learners; I'm chiming in
> 
> I often do something similar - but with an important difference:
> I perform cleanup when I save. I do NOT force an auto save.
> (More on that later.)
> 
> > BY ANY MEANS. That means by script, by menu OR by clicking the red dot
> > (of for WIN users the red X) in the title bar.
> > I need this to work in the IDE as well as in standalone.
> 
> So, let's halt at this point and take inventory of your desires!
> You want to trap at least 3 methods of initiating a close action.
> (Tally: 3)
> 
> Furthermore, IDE versus Standalone is an extra complexity.
> I don't like that, but it is the unfortunate reality.
> So I'm accounting for that extra complexity via a "+" designation!
> (Tally: "3+")
> 
> Now jumping ahead a bit to make a connection:
> 
> > If I use “CloseStack” instead
> 
> Remember our tally of "3+" Actions?
> The word "instead" suggests you're assuming a SINGLE trap.
> 
> Everyone here should know my KISS philosophy: less is better.
> 3 birds with one stone is superior; I'm always harping on that.
> But then again, in this case you have 3+ birds! :)
> 
> I'd hazard a guess on 2 traps - that's my experience for similar cases.
> (But if one will work, use one.)
> 
> > You would think closeStackRequest gets sent when I
> > click the red dot or X. You would be mistaken.
> 
> Actually I would NOT be mistaken, as long as we're talking about the X,
> and the stack has been named/saved at least once. Just tested it!
> 
> But among the "extra complexity" I mentioned, if the stack is dirty,
> the IDE will trap the close action at the front, BEFORE you get it.
> It can still fire, but AFTER you dance around a bit with the IDE.
> (Important to note that's the IDE; closeStackRequest does respond.)
> 
> To succeed in the IDE, you may indeed need to use closeStack.
> But that's probably "with" not "instead" of closeStackRequest!
> 
> We can still follow KISS and avoid duplicating code,
> via modularity - the 2 traps can call a common set of code.
> Using params or other means to handle the differences in the 2/3 cases.
> 
> > I just want it to be saved. I can force quit if I mess something up.
> 
> I DISCOURAGE using a custom auto-save and resorting to force quit.
> If you implement an auto-save, do it very well.
> (And done well, a force-quit would not likely be Plan A for reverting.)
> 
> But I encourage cleanup when saving or when closing. I do it constantly.
> It just requires a set of trap(s) that does spring for the 3 actions.
> You're half way there, just think "AND" not "instead" to finish it!
> 
> 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: Codesigning & notarizing

2021-02-04 Thread Marty Knapp via use-livecode
I just updated to Xcode 11.3 and still have the issue. With revzip included, 
building with 9.6.2 it works fine *until* I codesign - either with the Levure 
app packager or with AppWrapper (tried versions 3 and 4) As soon as it starts 
to launch it crashes. If I take out revzip the app will open fine when code 
signed.

If rev zip was damaged it would not work in the unsigned app. Anything else 
that I should check? This is really frustrating.

Marty

> On Feb 4, 2021, at 1:09 PM, panagiotis merakos via use-livecode 
>  wrote:
> 
> Thanks for testing Matthias :)
> 
> On Thu, 4 Feb 2021, 23:08 Paul Dupuis via use-livecode, <
> use-livecode@lists.runrev.com> wrote:
> 
>> I should have added that we sign with entitlements (the same set LC uses)
>> 
>> On 2/4/2021 3:56 PM, panagiotis merakos via use-livecode wrote:
>>> @Marty
>>> 
>>> If you have not done it already, it might be worth adding entitlements to
>>> the codesign.
>>> 
>>> 
>> https://lessons.livecode.com/m/4071/l/1293515-entitlements-for-signed-and-notarized-apps
>>> 
>>> I do not think it is the Xcode version that is the problem. I am on
>> Mojave
>>> as well, so I can do a quick test if you send me the standalone that
>>> crashes. Also make sure you attach the stack to the bug report :)
>>> 
>>> Kind regards,
>>> Panos
>>> --
>>> 
>>> On Thu, 4 Feb 2021 at 22:47, Paul Dupuis via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 I should add, we're not using Levure. We are using LC9.6.2rc2, we
 codesign via Terminal on Mohave using Xcode 10.2.1
 
 On 2/4/2021 3:37 PM, Paul Dupuis via use-livecode wrote:
> FYI - Our App includes the revZIP library. We codesign deep via
> Terminal command and get no crashes. Codesign, notarize, and staple
> without problems.
> 
> 
> On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
>> Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
>> library (crashes when codesigned)
>> 
>> Just filed a bug report on this - 23083
>> 
>> Marty
>> 
>>> On Feb 4, 2021, at 11:25 AM, Marty Knapp 
>>> wrote:
>>> 
>>> I’ve narrowed this down to the “Revolution Zip” library. If I leave
>>> that out of Inclusions, I can build in 9.6.2 and codesign and all is
>>> well.
>>> 
>>> marty
>>> 
 On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode
  wrote:
 
 Hi Marty,
 
 My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
 
 I have only a cursory understanding of Levure. From what I read,
 Trevor has methods to codesign and even notarize inside of Levure’s
 framework.
 
 If your testing with a basic stack works as expected, maybe some
 interaction is happening with the Levure Framework project. I am
 certain Trevor knows best what may be happening here.
 
 When you find out, please post back what you learn.
 
 Best regards,
 
 Mark Talluto
 livecloud.io 
 nursenotes.net 
 canelasoftware.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
 
 ___
 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


___
use-livecode mailing list
use-livecode@lists

Re: Close Stack Cleanup

2021-02-04 Thread Tore Nilsen via use-livecode
I follow a similar approach to what Curry describes here, keeping it modular, 
but I do not do any clean up at closing time. Instead I execute the necessary 
routines as part of a preOpenStack handler. I then do not have to consider 
which way the stack was closed. This is also what I encourage my students to 
do, in order to present the users with a pristine application every time the 
user starts the application.

By keeping it modular, the clean up script can also be started from other 
handlers if necessary. 

Best regards
Tore Nilsen

> 4. feb. 2021 kl. 22:23 skrev Curry Kenworthy via use-livecode 
> :
> 
> 
> Bob:
> 
> > I am trying to clean up my stack (i.e. clear the fields),
> > then save it when I close it
> 
> This is a good topic for LiveCode learners; I'm chiming in
> 
> I often do something similar - but with an important difference:
> I perform cleanup when I save. I do NOT force an auto save.
> (More on that later.)
> 
> > BY ANY MEANS. That means by script, by menu OR by clicking the red dot
> > (of for WIN users the red X) in the title bar.
> > I need this to work in the IDE as well as in standalone.
> 
> So, let's halt at this point and take inventory of your desires!
> You want to trap at least 3 methods of initiating a close action.
> (Tally: 3)
> 
> Furthermore, IDE versus Standalone is an extra complexity.
> I don't like that, but it is the unfortunate reality.
> So I'm accounting for that extra complexity via a "+" designation!
> (Tally: "3+")
> 
> Now jumping ahead a bit to make a connection:
> 
> > If I use “CloseStack” instead
> 
> Remember our tally of "3+" Actions?
> The word "instead" suggests you're assuming a SINGLE trap.
> 
> Everyone here should know my KISS philosophy: less is better.
> 3 birds with one stone is superior; I'm always harping on that.
> But then again, in this case you have 3+ birds! :)
> 
> I'd hazard a guess on 2 traps - that's my experience for similar cases.
> (But if one will work, use one.)
> 
> > You would think closeStackRequest gets sent when I
> > click the red dot or X. You would be mistaken.
> 
> Actually I would NOT be mistaken, as long as we're talking about the X,
> and the stack has been named/saved at least once. Just tested it!
> 
> But among the "extra complexity" I mentioned, if the stack is dirty,
> the IDE will trap the close action at the front, BEFORE you get it.
> It can still fire, but AFTER you dance around a bit with the IDE.
> (Important to note that's the IDE; closeStackRequest does respond.)
> 
> To succeed in the IDE, you may indeed need to use closeStack.
> But that's probably "with" not "instead" of closeStackRequest!
> 
> We can still follow KISS and avoid duplicating code,
> via modularity - the 2 traps can call a common set of code.
> Using params or other means to handle the differences in the 2/3 cases.
> 
> > I just want it to be saved. I can force quit if I mess something up.
> 
> I DISCOURAGE using a custom auto-save and resorting to force quit.
> If you implement an auto-save, do it very well.
> (And done well, a force-quit would not likely be Plan A for reverting.)
> 
> But I encourage cleanup when saving or when closing. I do it constantly.
> It just requires a set of trap(s) that does spring for the 3 actions.
> You're half way there, just think "AND" not "instead" to finish it!
> 
> 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: Close Stack Cleanup

2021-02-04 Thread Curry Kenworthy via use-livecode


Bob:

> I am trying to clean up my stack (i.e. clear the fields),
> then save it when I close it

This is a good topic for LiveCode learners; I'm chiming in

I often do something similar - but with an important difference:
I perform cleanup when I save. I do NOT force an auto save.
(More on that later.)

> BY ANY MEANS. That means by script, by menu OR by clicking the red dot
> (of for WIN users the red X) in the title bar.
> I need this to work in the IDE as well as in standalone.

So, let's halt at this point and take inventory of your desires!
You want to trap at least 3 methods of initiating a close action.
(Tally: 3)

Furthermore, IDE versus Standalone is an extra complexity.
I don't like that, but it is the unfortunate reality.
So I'm accounting for that extra complexity via a "+" designation!
(Tally: "3+")

Now jumping ahead a bit to make a connection:

> If I use “CloseStack” instead

Remember our tally of "3+" Actions?
The word "instead" suggests you're assuming a SINGLE trap.

Everyone here should know my KISS philosophy: less is better.
3 birds with one stone is superior; I'm always harping on that.
But then again, in this case you have 3+ birds! :)

I'd hazard a guess on 2 traps - that's my experience for similar cases.
(But if one will work, use one.)

> You would think closeStackRequest gets sent when I
> click the red dot or X. You would be mistaken.

Actually I would NOT be mistaken, as long as we're talking about the X,
and the stack has been named/saved at least once. Just tested it!

But among the "extra complexity" I mentioned, if the stack is dirty,
the IDE will trap the close action at the front, BEFORE you get it.
It can still fire, but AFTER you dance around a bit with the IDE.
(Important to note that's the IDE; closeStackRequest does respond.)

To succeed in the IDE, you may indeed need to use closeStack.
But that's probably "with" not "instead" of closeStackRequest!

We can still follow KISS and avoid duplicating code,
via modularity - the 2 traps can call a common set of code.
Using params or other means to handle the differences in the 2/3 cases.

> I just want it to be saved. I can force quit if I mess something up.

I DISCOURAGE using a custom auto-save and resorting to force quit.
If you implement an auto-save, do it very well.
(And done well, a force-quit would not likely be Plan A for reverting.)

But I encourage cleanup when saving or when closing. I do it constantly.
It just requires a set of trap(s) that does spring for the 3 actions.
You're half way there, just think "AND" not "instead" to finish it!

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: Codesigning & notarizing

2021-02-04 Thread panagiotis merakos via use-livecode
Thanks for testing Matthias :)

On Thu, 4 Feb 2021, 23:08 Paul Dupuis via use-livecode, <
use-livecode@lists.runrev.com> wrote:

> I should have added that we sign with entitlements (the same set LC uses)
>
> On 2/4/2021 3:56 PM, panagiotis merakos via use-livecode wrote:
> > @Marty
> >
> > If you have not done it already, it might be worth adding entitlements to
> > the codesign.
> >
> >
> https://lessons.livecode.com/m/4071/l/1293515-entitlements-for-signed-and-notarized-apps
> >
> > I do not think it is the Xcode version that is the problem. I am on
> Mojave
> > as well, so I can do a quick test if you send me the standalone that
> > crashes. Also make sure you attach the stack to the bug report :)
> >
> > Kind regards,
> > Panos
> > --
> >
> > On Thu, 4 Feb 2021 at 22:47, Paul Dupuis via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> I should add, we're not using Levure. We are using LC9.6.2rc2, we
> >> codesign via Terminal on Mohave using Xcode 10.2.1
> >>
> >> On 2/4/2021 3:37 PM, Paul Dupuis via use-livecode wrote:
> >>> FYI - Our App includes the revZIP library. We codesign deep via
> >>> Terminal command and get no crashes. Codesign, notarize, and staple
> >>> without problems.
> >>>
> >>>
> >>> On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
>  Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
>  library (crashes when codesigned)
> 
>  Just filed a bug report on this - 23083
> 
>  Marty
> 
> > On Feb 4, 2021, at 11:25 AM, Marty Knapp 
> > wrote:
> >
> > I’ve narrowed this down to the “Revolution Zip” library. If I leave
> > that out of Inclusions, I can build in 9.6.2 and codesign and all is
> > well.
> >
> > marty
> >
> >> On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode
> >>  wrote:
> >>
> >> Hi Marty,
> >>
> >> My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
> >>
> >> I have only a cursory understanding of Levure. From what I read,
> >> Trevor has methods to codesign and even notarize inside of Levure’s
> >> framework.
> >>
> >> If your testing with a basic stack works as expected, maybe some
> >> interaction is happening with the Levure Framework project. I am
> >> certain Trevor knows best what may be happening here.
> >>
> >> When you find out, please post back what you learn.
> >>
> >> Best regards,
> >>
> >> Mark Talluto
> >> livecloud.io 
> >> nursenotes.net 
> >> canelasoftware.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
> >>
> >> ___
> >> 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: Codesigning & notarizing

2021-02-04 Thread Paul Dupuis via use-livecode

I should have added that we sign with entitlements (the same set LC uses)

On 2/4/2021 3:56 PM, panagiotis merakos via use-livecode wrote:

@Marty

If you have not done it already, it might be worth adding entitlements to
the codesign.

https://lessons.livecode.com/m/4071/l/1293515-entitlements-for-signed-and-notarized-apps

I do not think it is the Xcode version that is the problem. I am on Mojave
as well, so I can do a quick test if you send me the standalone that
crashes. Also make sure you attach the stack to the bug report :)

Kind regards,
Panos
--

On Thu, 4 Feb 2021 at 22:47, Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:


I should add, we're not using Levure. We are using LC9.6.2rc2, we
codesign via Terminal on Mohave using Xcode 10.2.1

On 2/4/2021 3:37 PM, Paul Dupuis via use-livecode wrote:

FYI - Our App includes the revZIP library. We codesign deep via
Terminal command and get no crashes. Codesign, notarize, and staple
without problems.


On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:

Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
library (crashes when codesigned)

Just filed a bug report on this - 23083

Marty


On Feb 4, 2021, at 11:25 AM, Marty Knapp 
wrote:

I’ve narrowed this down to the “Revolution Zip” library. If I leave
that out of Inclusions, I can build in 9.6.2 and codesign and all is
well.

marty


On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode
 wrote:

Hi Marty,

My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.

I have only a cursory understanding of Levure. From what I read,
Trevor has methods to codesign and even notarize inside of Levure’s
framework.

If your testing with a basic stack works as expected, maybe some
interaction is happening with the Levure Framework project. I am
certain Trevor knows best what may be happening here.

When you find out, please post back what you learn.

Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.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


___
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: Codesigning & notarizing

2021-02-04 Thread matthias rebbe via use-livecode
The stack is already attached to the bug report. ;) 

I had some time, so I've used Marty's demo stack and  created a standalone and 
code signed it. I also did not add the entitlements when code signing with App 
Wrapper 4. 
The code signed app does not crash at startup.


-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 04.02.2021 um 21:56 schrieb panagiotis merakos via use-livecode 
> :
> 
> @Marty
> 
> If you have not done it already, it might be worth adding entitlements to
> the codesign.
> 
> https://lessons.livecode.com/m/4071/l/1293515-entitlements-for-signed-and-notarized-apps
> 
> I do not think it is the Xcode version that is the problem. I am on Mojave
> as well, so I can do a quick test if you send me the standalone that
> crashes. Also make sure you attach the stack to the bug report :)
> 
> Kind regards,
> Panos
> --
> 
> On Thu, 4 Feb 2021 at 22:47, Paul Dupuis via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> I should add, we're not using Levure. We are using LC9.6.2rc2, we
>> codesign via Terminal on Mohave using Xcode 10.2.1
>> 
>> On 2/4/2021 3:37 PM, Paul Dupuis via use-livecode wrote:
>>> FYI - Our App includes the revZIP library. We codesign deep via
>>> Terminal command and get no crashes. Codesign, notarize, and staple
>>> without problems.
>>> 
>>> 
>>> On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
 Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
 library (crashes when codesigned)
 
 Just filed a bug report on this - 23083
 
 Marty
 
> On Feb 4, 2021, at 11:25 AM, Marty Knapp 
> wrote:
> 
> I’ve narrowed this down to the “Revolution Zip” library. If I leave
> that out of Inclusions, I can build in 9.6.2 and codesign and all is
> well.
> 
> marty
> 
>> On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode
>>  wrote:
>> 
>> Hi Marty,
>> 
>> My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
>> 
>> I have only a cursory understanding of Levure. From what I read,
>> Trevor has methods to codesign and even notarize inside of Levure’s
>> framework.
>> 
>> If your testing with a basic stack works as expected, maybe some
>> interaction is happening with the Levure Framework project. I am
>> certain Trevor knows best what may be happening here.
>> 
>> When you find out, please post back what you learn.
>> 
>> Best regards,
>> 
>> Mark Talluto
>> livecloud.io 
>> nursenotes.net 
>> canelasoftware.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
>> 
>> 
>> ___
>> 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: Codesigning & notarizing

2021-02-04 Thread panagiotis merakos via use-livecode
@Marty

If you have not done it already, it might be worth adding entitlements to
the codesign.

https://lessons.livecode.com/m/4071/l/1293515-entitlements-for-signed-and-notarized-apps

I do not think it is the Xcode version that is the problem. I am on Mojave
as well, so I can do a quick test if you send me the standalone that
crashes. Also make sure you attach the stack to the bug report :)

Kind regards,
Panos
--

On Thu, 4 Feb 2021 at 22:47, Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I should add, we're not using Levure. We are using LC9.6.2rc2, we
> codesign via Terminal on Mohave using Xcode 10.2.1
>
> On 2/4/2021 3:37 PM, Paul Dupuis via use-livecode wrote:
> > FYI - Our App includes the revZIP library. We codesign deep via
> > Terminal command and get no crashes. Codesign, notarize, and staple
> > without problems.
> >
> >
> > On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
> >> Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
> >> library (crashes when codesigned)
> >>
> >> Just filed a bug report on this - 23083
> >>
> >> Marty
> >>
> >>> On Feb 4, 2021, at 11:25 AM, Marty Knapp 
> >>> wrote:
> >>>
> >>> I’ve narrowed this down to the “Revolution Zip” library. If I leave
> >>> that out of Inclusions, I can build in 9.6.2 and codesign and all is
> >>> well.
> >>>
> >>> marty
> >>>
>  On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode
>   wrote:
> 
>  Hi Marty,
> 
>  My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
> 
>  I have only a cursory understanding of Levure. From what I read,
>  Trevor has methods to codesign and even notarize inside of Levure’s
>  framework.
> 
>  If your testing with a basic stack works as expected, maybe some
>  interaction is happening with the Levure Framework project. I am
>  certain Trevor knows best what may be happening here.
> 
>  When you find out, please post back what you learn.
> 
>  Best regards,
> 
>  Mark Talluto
>  livecloud.io 
>  nursenotes.net 
>  canelasoftware.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
>
>
> ___
> 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: Codesigning & notarizing

2021-02-04 Thread matthias rebbe via use-livecode
Hi Marty,

i added a comment to your bug report already. I used your demo stack and cannot 
replicate the crash.
I use App Wrapper 4 to code sign. I code signe for Web distribution, not for 
App Store or Store installer.

I am also on Mojave (10.14.6), but i am using Xcode 11.3

Regards,
Matthias


-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 04.02.2021 um 21:51 schrieb Marty Knapp via use-livecode 
> :
> 
> No it is not used on startup, it’s for a backup feature that the user 
> invokes. I am on Mojave and looks like x-code 10.1. Do you think my version 
> of x-code could be the issue?
> 
> All is fine when I build with LC 9.6.1. It’s when I build with 9.6.2. I’ve 
> used the codesigning ability of Trevor’s “Levure” framework as well as 
> AppWrapper - tried both version 3 and 4
> 
> Marty
> 
>> On Feb 4, 2021, at 12:46 PM, panagiotis merakos via use-livecode 
>>  wrote:
>> 
>> Hello Marty,
>> 
>> How is revZip used by your app? Is it used on startup?
>> 
>> Kind regards,
>> Panos
>> --
>> 
>> On Thu, 4 Feb 2021 at 22:38, Paul Dupuis via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> FYI - Our App includes the revZIP library. We codesign deep via Terminal
>>> command and get no crashes. Codesign, notarize, and staple without
>>> problems.
>>> 
>>> 
>>> On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
 Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
>>> library (crashes when codesigned)
 
 Just filed a bug report on this - 23083
 
 Marty
 
> On Feb 4, 2021, at 11:25 AM, Marty Knapp 
>>> wrote:
> 
> I’ve narrowed this down to the “Revolution Zip” library. If I leave
>>> that out of Inclusions, I can build in 9.6.2 and codesign and all is well.
> 
> marty
> 
>> On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>> 
>> Hi Marty,
>> 
>> My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
>> 
>> I have only a cursory understanding of Levure. From what I read,
>>> Trevor has methods to codesign and even notarize inside of Levure’s
>>> framework.
>> 
>> If your testing with a basic stack works as expected, maybe some
>>> interaction is happening with the Levure Framework project. I am certain
>>> Trevor knows best what may be happening here.
>> 
>> When you find out, please post back what you learn.
>> 
> 
> 
> ___
> 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: Codesigning & notarizing

2021-02-04 Thread Marty Knapp via use-livecode
No it is not used on startup, it’s for a backup feature that the user invokes. 
I am on Mojave and looks like x-code 10.1. Do you think my version of x-code 
could be the issue?

All is fine when I build with LC 9.6.1. It’s when I build with 9.6.2. I’ve used 
the codesigning ability of Trevor’s “Levure” framework as well as AppWrapper - 
tried both version 3 and 4

Marty

> On Feb 4, 2021, at 12:46 PM, panagiotis merakos via use-livecode 
>  wrote:
> 
> Hello Marty,
> 
> How is revZip used by your app? Is it used on startup?
> 
> Kind regards,
> Panos
> --
> 
> On Thu, 4 Feb 2021 at 22:38, Paul Dupuis via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> FYI - Our App includes the revZIP library. We codesign deep via Terminal
>> command and get no crashes. Codesign, notarize, and staple without
>> problems.
>> 
>> 
>> On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
>>> Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
>> library (crashes when codesigned)
>>> 
>>> Just filed a bug report on this - 23083
>>> 
>>> Marty
>>> 
 On Feb 4, 2021, at 11:25 AM, Marty Knapp 
>> wrote:
 
 I’ve narrowed this down to the “Revolution Zip” library. If I leave
>> that out of Inclusions, I can build in 9.6.2 and codesign and all is well.
 
 marty
 
> On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
> 
> Hi Marty,
> 
> My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
> 
> I have only a cursory understanding of Levure. From what I read,
>> Trevor has methods to codesign and even notarize inside of Levure’s
>> framework.
> 
> If your testing with a basic stack works as expected, maybe some
>> interaction is happening with the Levure Framework project. I am certain
>> Trevor knows best what may be happening here.
> 
> When you find out, please post back what you learn.
> 


___
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: Codesigning & notarizing

2021-02-04 Thread panagiotis merakos via use-livecode
Hello Marty,

How is revZip used by your app? Is it used on startup?

Kind regards,
Panos
--

On Thu, 4 Feb 2021 at 22:38, Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> FYI - Our App includes the revZIP library. We codesign deep via Terminal
> command and get no crashes. Codesign, notarize, and staple without
> problems.
>
>
> On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
> > Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip”
> library (crashes when codesigned)
> >
> > Just filed a bug report on this - 23083
> >
> > Marty
> >
> >> On Feb 4, 2021, at 11:25 AM, Marty Knapp 
> wrote:
> >>
> >> I’ve narrowed this down to the “Revolution Zip” library. If I leave
> that out of Inclusions, I can build in 9.6.2 and codesign and all is well.
> >>
> >> marty
> >>
> >>> On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>>
> >>> Hi Marty,
> >>>
> >>> My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
> >>>
> >>> I have only a cursory understanding of Levure. From what I read,
> Trevor has methods to codesign and even notarize inside of Levure’s
> framework.
> >>>
> >>> If your testing with a basic stack works as expected, maybe some
> interaction is happening with the Levure Framework project. I am certain
> Trevor knows best what may be happening here.
> >>>
> >>> When you find out, please post back what you learn.
> >>>
> >>> Best regards,
> >>>
> >>> Mark Talluto
> >>> livecloud.io 
> >>> nursenotes.net 
> >>> canelasoftware.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
>
___
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: Codesigning & notarizing

2021-02-04 Thread Paul Dupuis via use-livecode
I should add, we're not using Levure. We are using LC9.6.2rc2, we 
codesign via Terminal on Mohave using Xcode 10.2.1


On 2/4/2021 3:37 PM, Paul Dupuis via use-livecode wrote:
FYI - Our App includes the revZIP library. We codesign deep via 
Terminal command and get no crashes. Codesign, notarize, and staple 
without problems.



On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:
Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip” 
library (crashes when codesigned)


Just filed a bug report on this - 23083

Marty

On Feb 4, 2021, at 11:25 AM, Marty Knapp  
wrote:


I’ve narrowed this down to the “Revolution Zip” library. If I leave 
that out of Inclusions, I can build in 9.6.2 and codesign and all is 
well.


marty

On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode 
 wrote:


Hi Marty,

My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.

I have only a cursory understanding of Levure. From what I read, 
Trevor has methods to codesign and even notarize inside of Levure’s 
framework.


If your testing with a basic stack works as expected, maybe some 
interaction is happening with the Levure Framework project. I am 
certain Trevor knows best what may be happening here.


When you find out, please post back what you learn.

Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.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



___
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: Codesigning & notarizing

2021-02-04 Thread Paul Dupuis via use-livecode
FYI - Our App includes the revZIP library. We codesign deep via Terminal 
command and get no crashes. Codesign, notarize, and staple without problems.



On 2/4/2021 2:40 PM, Marty Knapp via use-livecode wrote:

Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip” library 
(crashes when codesigned)

Just filed a bug report on this - 23083

Marty


On Feb 4, 2021, at 11:25 AM, Marty Knapp  wrote:

I’ve narrowed this down to the “Revolution Zip” library. If I leave that out of 
Inclusions, I can build in 9.6.2 and codesign and all is well.

marty


On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode 
 wrote:

Hi Marty,

My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.

I have only a cursory understanding of Levure. From what I read, Trevor has 
methods to codesign and even notarize inside of Levure’s framework.

If your testing with a basic stack works as expected, maybe some interaction is 
happening with the Levure Framework project. I am certain Trevor knows best 
what may be happening here.

When you find out, please post back what you learn.

Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.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: Using MySQL on (headless) Linux

2021-02-04 Thread Ralph DiMola via use-livecode
David's server talk is worth a mention again! He got me into LC server. It
was so nice not to have learn php in depth as I could leverage my LC
knowledge and existing code. I use server every day.

But a question... I have always been confused with the difference between
"start using' and "include" but I think I get it now.
"Start using" is just like desktop and the message path goes thru it in
order of the "start using"s take on desktop.
"Include" is including the code into the script that invokes it. So as Mark
said you could use includes to set global vars or even a different include
file of constants depending on the data received in the web request.
Is this correct?

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 Mark Wieder via use-livecode
Sent: Thursday, February 04, 2021 11:52 AM
To: Richard Gaskin via use-livecode
Cc: Mark Wieder
Subject: Re: Using MySQL on (headless) Linux

On 2/4/21 1:52 AM, Richard Gaskin via use-livecode wrote:

> With all this flexibility in one lean install, for me the pros of LC 
> Server for headless work are clear:

...plus the fact that there's an "include" command in the server, allowing
for things like global constants.

--
  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


___
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: Codesigning & notarizing

2021-02-04 Thread Marty Knapp via use-livecode
Re: building a standalone in LC 9.6.2 rc2 with the “Revolution Zip” library 
(crashes when codesigned)

Just filed a bug report on this - 23083

Marty

> On Feb 4, 2021, at 11:25 AM, Marty Knapp  wrote:
> 
> I’ve narrowed this down to the “Revolution Zip” library. If I leave that out 
> of Inclusions, I can build in 9.6.2 and codesign and all is well.
> 
> marty
> 
>> On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode 
>>  wrote:
>> 
>> Hi Marty,
>> 
>> My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
>> 
>> I have only a cursory understanding of Levure. From what I read, Trevor has 
>> methods to codesign and even notarize inside of Levure’s framework. 
>> 
>> If your testing with a basic stack works as expected, maybe some interaction 
>> is happening with the Levure Framework project. I am certain Trevor knows 
>> best what may be happening here.
>> 
>> When you find out, please post back what you learn. 
>> 
>> Best regards,
>> 
>> Mark Talluto
>> livecloud.io 
>> nursenotes.net 
>> canelasoftware.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: Codesigning & notarizing

2021-02-04 Thread Marty Knapp via use-livecode
I’ve narrowed this down to the “Revolution Zip” library. If I leave that out of 
Inclusions, I can build in 9.6.2 and codesign and all is well.

marty

> On Feb 3, 2021, at 2:59 PM, Mark Talluto via use-livecode 
>  wrote:
> 
> Hi Marty,
> 
> My work is with LiveCode 9.6.2 rc2 and Xcode 11.3.1.
> 
> I have only a cursory understanding of Levure. From what I read, Trevor has 
> methods to codesign and even notarize inside of Levure’s framework. 
> 
> If your testing with a basic stack works as expected, maybe some interaction 
> is happening with the Levure Framework project. I am certain Trevor knows 
> best what may be happening here.
> 
> When you find out, please post back what you learn. 
> 
> Best regards,
> 
> Mark Talluto
> livecloud.io 
> nursenotes.net 
> canelasoftware.com 
> 
> 
> 
> 
>> On Feb 3, 2021, at 1:45 PM, Marty Knapp via use-livecode 
>>  wrote:
>> 
>> Mark,
>> When I create a new, empty test stack and save as a standalone using 
>> versions 9.6.0, 9.6.1 and 9.6.2, I right-click the resulting app to show 
>> contents and there is a folder “_CodeSignature” and inside that is a 
>> “CodeResources” file. When I build a test standalone with LC 9.5.1 that 
>> folder is not present. So LC must have started codesigning as you described 
>> starting with 9.6.0.
>> 
>> I can build a standalone in 9.6.1, codesign with AppWrapper and it notaries 
>> and runs fine. It’s when I do the build with 9.6.2 - it will run before I 
>> codesign with AppWrapper but after I codesign with AppWrapper - then it 
>> crashes on startup. It is a Levure-based app. If I create an empty test 
>> stack, build with 9.6.2, then codesign with AppWrapper it will open without 
>> a problem. So it looks like something specific to Levure or some combination 
>> of Levure, the version of my X-code (I’m on Mojave running X-Code 10.1 it 
>> looks like.) and LC 9.6.2.
>> 
>> Marty


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Close Stack Cleanup

2021-02-04 Thread Bob Sneidar via use-livecode
Hi all. 

I know we have tread this ground before, but I am trying to clean up my stack 
(i.e. clear the fields), then save it when I close it BY ANY MEANS. That means 
by script, by menu OR by clicking the red dot (of for WIN users the red X) in 
the title bar. I need this to work in the IDE as well as in standalone. 

You would think closeStackRequest gets sent when I click the red dot or X. You 
would be mistaken. 

The dictionary reads, 

The closeStackRequest message is only sent if the request to close a stack is 
initiated by the user (eg by clicking file -> close in the LiveCode menu). If 
the request is initiated from a script (eg "close this stack" ) then the 
closeStackRequest message is not sent.

Apparently clicking the red dot is not considered, “initiated by the user.” It 
ought to be. 

If I use “CloseStack” instead, I cannot save the stack because a script is 
currently running, and I do not want to be presented with the dialog to save, 
do not save, or cancel. I just want it to be saved. I can force quit if I mess 
something up. 

Bob S

___
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: Files() can't list rtfd files (mac)

2021-02-04 Thread Michael Kristensen via use-livecode
Danke schön Klaus

Michael
___
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: Sign a Mac App, also sign the DMG?

2021-02-04 Thread Paul Dupuis via use-livecode
We current ship a commercial app. We code sign, notarize, and staple our 
App We then place it on a DMG using DropDMG, but do not code sign the 
DMG. We distribute the DMG via our Web site and not the MacApp store.


QA testing on Catalina and Big Sur show only the usual "This (the DMG) 
has been downloaded from the Internet" warning that your get even with a 
signed DMG if downloading outside of the MacApp store. Where as a signed 
DMG will not open on Mavericks and a couple other above 10.9.


We test on 10.9 to 10.16 as that is the range of MacOS versions 
supported by LC.



On 2/4/2021 11:54 AM, Peter Bogdanoff via use-livecode wrote:

To avoid the unidentifiable developer warning in recent macOS versions, you do 
need it signed. If your market is consumers, that is what they will have.

DropDMG is great.

Peter


On Feb 4, 2021, at 8:49 AM, Klaus major-k via use-livecode 
 wrote:

Hi Paul,


Am 04.02.2021 um 17:46 schrieb Paul Dupuis via use-livecode 
:

If the App is Signed and Notarized, it is actually best NOT to sign the DMG.
Older versions of MacOS (like Mavericks, etc.) have a problem with signed DMGs

thank you very much, very helpful!


On 2/4/2021 11:40 AM, Klaus major-k via use-livecode wrote:
Hi friends,

quick question, now we have a Mac app, signed and notarized
and what not, is it also neccessary for the DMG we create from
that app for distribution?

Thanks for any insight!

Best

Klaus

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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

___
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: Sign a Mac App, also sign the DMG?

2021-02-04 Thread Peter Bogdanoff via use-livecode
To avoid the unidentifiable developer warning in recent macOS versions, you do 
need it signed. If your market is consumers, that is what they will have.

DropDMG is great.

Peter 

> On Feb 4, 2021, at 8:49 AM, Klaus major-k via use-livecode 
>  wrote:
> 
> Hi Paul,
> 
>> Am 04.02.2021 um 17:46 schrieb Paul Dupuis via use-livecode 
>> :
>> 
>> If the App is Signed and Notarized, it is actually best NOT to sign the DMG.
>> Older versions of MacOS (like Mavericks, etc.) have a problem with signed 
>> DMGs
> 
> thank you very much, very helpful!
> 
>>> On 2/4/2021 11:40 AM, Klaus major-k via use-livecode wrote:
>>> Hi friends,
>>> 
>>> quick question, now we have a Mac app, signed and notarized
>>> and what not, is it also neccessary for the DMG we create from
>>> that app for distribution?
>>> 
>>> Thanks for any insight!
> 
> Best
> 
> Klaus
> 
> --
> Klaus Major
> https://www.major-k.de
> https://www.major-k.de/bass
> kl...@major-k.de
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
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: Using MySQL on (headless) Linux

2021-02-04 Thread Mark Wieder via use-livecode

On 2/4/21 1:52 AM, Richard Gaskin via use-livecode wrote:

With all this flexibility in one lean install, for me the pros of LC 
Server for headless work are clear:


...plus the fact that there's an "include" command in the server, 
allowing for things like global constants.


--
 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: Sign a Mac App, also sign the DMG?

2021-02-04 Thread Klaus major-k via use-livecode
Hi Paul,

> Am 04.02.2021 um 17:46 schrieb Paul Dupuis via use-livecode 
> :
> 
> If the App is Signed and Notarized, it is actually best NOT to sign the DMG.
> Older versions of MacOS (like Mavericks, etc.) have a problem with signed DMGs

thank you very much, very helpful!

> On 2/4/2021 11:40 AM, Klaus major-k via use-livecode wrote:
>> Hi friends,
>> 
>> quick question, now we have a Mac app, signed and notarized
>> and what not, is it also neccessary for the DMG we create from
>> that app for distribution?
>> 
>> Thanks for any insight!

Best

Klaus

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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Sign a Mac App, also sign the DMG?

2021-02-04 Thread Paul Dupuis via use-livecode
If the App is Signed and Notarized, it is actually best NOT to sign the 
DMG. Older versions of MacOS (like Mavericks, etc.) have a problem with 
signed DMGs



On 2/4/2021 11:40 AM, Klaus major-k via use-livecode wrote:

Hi friends,

quick question, now we have a Mac app, signed and notarized
and what not, is it also neccessary for the DMG we create from
that app for distribution?

Thanks for any insight!


Best

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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
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


Sign a Mac App, also sign the DMG?

2021-02-04 Thread Klaus major-k via use-livecode
Hi friends,

quick question, now we have a Mac app, signed and notarized
and what not, is it also neccessary for the DMG we create from
that app for distribution?

Thanks for any insight!


Best

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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Using MySQL on (headless) Linux

2021-02-04 Thread Bob Sneidar via use-livecode
I don’t remember what I had for dinner on Friday. :-)

Bob S


On Feb 3, 2021, at 10:58 PM, Mark Waddingham via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

On 2021-02-03 20:07, Richard Gaskin via use-livecode wrote:
LC Server had already been ruled out (for whatever reason) in an earlier part 
of the thread...
That's too bad. LC Server is LiveCode build designed specifically for
command line use.

Interesting - I don't remember that being what I specifically designed it for :P

___
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: Using MySQL on (headless) Linux

2021-02-04 Thread Richard Gaskin via use-livecode

Mark Waddingham wrote:


On 2021-02-03 20:07, Richard Gaskin via use-livecode wrote:
LC Server had already been ruled out (for whatever reason) in an 
earlier part of the thread...


That's too bad. LC Server is LiveCode build designed specifically for
command line use.


Interesting - I don't remember that being what I specifically designed 
it for :P


LiveCode Server was *specifically designed* to be used just like PHP - 
allowing you to interpolate code with HTML output for the purposes of 
constructing webpages on the fly, sitting behind a web-server... That's 
why it has unique syntax designed precisely for a CGI environment, and 
operating in that PHP-like manner.


Making it run in command-line mode as well was an obvious thing to do, 
and also made up for the fact (at the time) that bare standalone engines 
would not launch a stack on the command-line (as that was a rather 
gaping licensing hole which was closed between v3 and v4

IIRC). [ It also made it easier to test the general features of it! ]

Since the advent of the community edition, however, and perhaps more 
importantly script-only-stacks - standalone engines running with -ui can 
be just as convenient...



Indeed it can.  The -ui option for running standalones was something 
many of us enjoyed back in the MetaCard days; AFAIK it was first 
implemented with v1.0 back in '92; it least it was there when I first 
started with MC back in '96.


In addition to being an option for standalones, one could even run the 
bare engine with -ui as well.


And being a command line tool that uses stdin/stdout, running the engine 
or a standalone with -ui also worked well as a CGI under Apache or 
Lightly (though in a flavor more like Perl, Python, or Ruby than PHP).


Your fine addition in more recent years with a special Server build to 
allow PHP-like co-mingling of code and content was well done and much 
appreciated for those who enjoy that workflow on web servers.


And back in '14 David Williams reminded us that the standard shebang 
option for running a script text file is still available, though with a 
slight syntactic difference from how we used to do that with MC (entry 
point used to be a startup message, now just bare script statements 
outside of a handler):

https://livecode.com/a-livecode-shell/


With all this flexibility in one lean install, for me the pros of LC 
Server for headless work are clear:


- We get the benefits of a standalone without having to make a
  standalone (indeed the engine can be kept up to date with a
  scrape-n-wget from the Downloads page, without needing to run
  it through the Standalone Builder on a separate GUI system).

- We have the same options for running it as a standalone, without
  needing to remember to add -ui (minor, but every little simplicity
  is nice).

- BONUS: We get the bonus option of running it aa a CGI without
  needing to write our own libraries for that (reading and parsing
  POST, writing to stdOut, handling every little detail about
  headers, sessions, and more).  And when we do, we can enjoy
  PHP-style implicit merge, mixing content and code much more
  conveniently than with the merge function.

That bonus may be irrelevant for some use cases, but probably not many. 
After all, a headless machine is usually not our main dev machine; it's 
probably being deployed to provide services for client machines. When 
those services are being delivered over a network we'll need a protocol, 
and in most cases HTTP will be a great choice, certainly the most common 
one. And though we can write our own HTTP daemon in LC, letting Apache 
do that generic work gives us better throughput, robustness, and 
security, with lower maintenance costs.


Letting Apache do what it does best lets us do what we do best: focus on 
the functionality unique to our application service.



All that said, perhaps my appreciation for your work with LC Server is 
indeed misplaced, and maybe it shouldn't be encouraged as the go-to 
choice for headless LiveCode development. :)


But as one who resisted using it for many years after it was released, 
continuing to use standalones with -ui, I must admit that the 
efficiencies in both execution time and my development and maintenance 
time eventually made me uniquely enamored of LC Server as my default 
choice for any headless system.


So if this makes me an LC Server fanboy, guilty as charged, your honor.

--
 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