Re: Stack name conflicts resolved?

2016-11-05 Thread Monte Goulding

> On 6 Nov. 2016, at 1:31 pm, Mark Wieder  wrote:
> 
> When new stacks are created in memory they are assigned the id 1002.
> Why?
> If there's a stack already in memory why not create the new stack with the 
> next sequential id?
> Then the combination of id and filename should uniquely identify a stack.

Stack IDs aren’t really IDs at all they are just the max ID in a stack + 1. The 
first 1000 IDs are reserved. Card 1 is 1001 and therefore a new stack ID is 
1002. Create a new object and the ID changes.

I guess we will discuss UUIDs next ;-)

Cheers

Monte
___
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: Updating Text-Script Only Stacks in Run-Time, Message Path Memory

2016-11-05 Thread Monte Goulding

> On 6 Nov. 2016, at 1:33 pm, Mark Wieder  wrote:
> 
>> So, yes… something is causing the IDE not to pick up the changes in the open 
>> scripts and (re)placing it in the message path.
> 
> Yep. It's one of the two reasons I don't use script-only stacks.

From the sounds of the original description I’m more suspicious of the message 
box than anything to do with loading the script correctly when it’s applied or 
script only stacks. The message box does a certain amount of jiggery pokery to 
interpret what you enter.

FWIW I work with script only stacks most of the time and have not noticed 
anything like this. Of course if you are making changes in a text editor and 
expecting those to be reflected in the running IDE then you are out of luck.

Cheers

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

Mobile tao: mouseStillDown, mouseUp, answer dialog

2016-11-05 Thread Mike Kerner
This is the second time I've been bitten by this, so this is more a note to
me for the next time it happens, because I had forgotten what I learned,
the first time, and I didn't look in the right place for my notes on the
subject, but I did look here.

For some context, I was trying to (poorly) emulate 3d touches by handling
mouseStillDown on mobile.


1) mouseStillDown does not propogate.  ONLY the object that the user is
touching will receive it.  If the object is part of a group, the group will
not get the message.  You have to specifically send the message to the
group for the group to get and handle it.  This is important if you are
using a skinning tool.  If that group has an icon and a face, make sure you
catch and send mouseStillDown in both.

2) The answer dialog on mobile is not truly modal.  Think of it as having a
transparent background that sits over your stack.  So, if you catch
mouseStillDown and pop up an answer dialog, when you stop pressing on the
object (so you can tap on the dialog), the object will receive
mouseUp/mouseLeave/etc.

3) The easiest way to handle this is to have a semaphore

local MSD

on mouseDown
   put false into MSD
end mouseDown

on mouseUp
   if MSD then exit mouseUp
end mouseUp

on mouseStillDown
   put true into MSD
end mouseStillDown


-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Goofy question about Datagrids

2016-11-05 Thread Sri
Bob Sneidar-2 wrote
> Well I discovered that what you CANNOT do is call a user-defined command
> or function that has not been loaded yet, as in a front or back script
> that has not been inserted yet. If I do, when I open the stack I get an
> error. I suppose I could do the inserts in a preopen handler, but the
> scripts are contained in buttons in the stack that is not open yet. Not
> sure how that would play out.
> 
> Bob S

Bob,

May be I have not understood what you are trying to do, but a user-defined
function in the same script as the FillinData handler of the column in
question works perfectly for me.

 
Above is the original phone number format. I tried to convert it by adding
an fConvert function in the column behavior of the "Phone" column, as
follows:

on FillInData pData
   -- set the text of field 1 of me to pData
   set the text of field 1 of me to fConvert(pData)
 end FillInData
 
function fConvert pData
   set the itemDel to "-"
   return "(" & item 1 of pData & ")" &&  (item 2 of pData) && (item 3 of
pData)
end fConvert

It works perfectly; here's the image.

 

I hope the images show in the post (My post wouldn't make any sense
otherwise!)

Regards,
Sri




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Goofy-question-about-Datagrids-tp4709954p4710097.html
Sent from the Revolution - User mailing list archive at Nabble.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: Updating Text-Script Only Stacks in Run-Time, Message Path Memory

2016-11-05 Thread J. Landman Gay

On 11/5/16 10:04 AM, Sannyasin Brahmanathaswami wrote:

But the engine does not yet "see" my new handler.  Just for fun: open
stack file on disk.. in BBEdit: yes, confirmed, my changes are
there.

ERGO conclude: editing a script only stack and saving it does *not*
update the "live" version of that file in memory that is in use by
the engine.


Actually, I've seen the same thing occasionally in regular stack scripts 
too, not just script-only stacks. There's been an issue with window 
confusion for some time, but I have never been able to get a reliable 
recipe.


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


Stack name conflicts resolved?

2016-11-05 Thread Richard Gaskin
I've grown weary of stack name conflict over the years, and this morning 
decided to take some time to assess where we're really at with that and 
see if perhaps there's a way to handle things more liberally than how 
the IDE does now.


TL/DR version:  It seems there's actually no real problem at all.

Long version:


Setup
-
I checked revfrontscriptlibrary and found that preOpenStack calls 
revIDEHandleNewStack, which resides in revbackscriptlibrary.


In that handler I found this line #3199, which I commented out:

  revCheckStackCollision tStackName

That handler is apparently the one that compares the stacks in the stack 
file being opened against a list of stacks already open, and if any 
stack of the same name is found it brings up the stack name conflict 
warning.


After commenting it out I made two stacks:

mainstack:  tA
 substack:  foo

mainstack   tB
 substack:  foo

On each mainstack is a button with:

  on mouseUp
 toplevel "foo"
  end mouseUp

Each foo substack contains an object to distinguish the stacks from one 
another, so I can tell which foo stack is which at a glance.


With that prep out of the way, I began my experiment:


Experiment 1

I started a fresh session in LC, and opened tA.

Then I opened tB.

And since I'd commented out revCheckStackCollision, no warning was 
presented.


So then in stack tA I clicked the button, and it opened the foo substack 
belonging to it.


Then I clicked the button in stack tB, and it opened the foo substack 
belonging to it.



Experiment 2

I created a third stack file, and added a button with the same script as 
above.


When clicked, it opens the foo window belonging to the stack file which 
had been opened first.




Results
---
It would appear that the resolution of substack names follows a logical 
path that looks for matching stacks in this order:


1. Within the same stack file as the script referring to it.

2. Within another stack file, in the order in which they were opened 
during the session.


This seems more or less what I've been hoping to find for years:
http://quality.livecode.com/show_bug.cgi?id=1061

Unless there's something here that I've missed, it would appear that 
stack name resolution is nearly as logical and useful across stack files 
as icon ID resolution.


And just as we don't need to go through contortions to ensure that every 
icon ID is unique across all stacks, as long as we remember the 
resolution rule we can safely use stacks of the same name within the 
current session.


That is, once we modify the IDE to allow it.

Is there something I've missed here?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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


Re: Background colour of a new stack

2016-11-05 Thread Richard Gaskin

Graham Samuel wrote:

> This may be old news to some, but in the LC7x series and earlier, if
> you created a stack, the card displayed as white. In LC 8.1.1, it
> displays as grey (reported as 220,220,220). To make cards look the
> way they did in earlier versions, I have to created a background
> rectangle graphic specifically coloured white.
>
> Was this a deliberate change? Or have I  made some odd mistake? Looks
> like I need to tweak some cards.

I believe the current default background is inherited from the OS, part 
of the theming enhancements that make LC 8 much more HIG-savvy than 
earlier versions.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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


Re: Background colour of a new stack

2016-11-05 Thread Randy Hengst
Graham,

I also thought the change of color to be a bit odd. 

If I understood you correctly, you are adding a graphic to “cover up” the gray 
background. You don’t need to add a graphic to create the white background. Go 
to the Stack Inspector and change the backgroundColor to white. Then each card 
you make in the stack will have the white background.

be well,
randy

Randy Hengst
www.classroomFocusedSoftware.com



> On Nov 5, 2016, at 4:30 PM, Richard Gaskin  wrote:
> 
> Graham Samuel wrote:
> 
> > This may be old news to some, but in the LC7x series and earlier, if
> > you created a stack, the card displayed as white. In LC 8.1.1, it
> > displays as grey (reported as 220,220,220). To make cards look the
> > way they did in earlier versions, I have to created a background
> > rectangle graphic specifically coloured white.
> >
> > Was this a deliberate change? Or have I  made some odd mistake? Looks
> > like I need to tweak some cards.
> 
> I believe the current default background is inherited from the OS, part of 
> the theming enhancements that make LC 8 much more HIG-savvy than earlier 
> versions.
> 
> -- 
> 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

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

Re: Stack name conflicts resolved?

2016-11-05 Thread Monte Goulding
I didn't say it couldn't be done. Possibly we would need versions of the 
mainstacks and openstacks that listed long IDs.

Sent from my iPhone

> On 6 Nov. 2016, at 9:08 am, Richard Gaskin  wrote:
> 
> I imagine for good reason, but I'm curious: where does topstack not do what 
> an IDE needs?


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


Re: Stack name conflicts resolved?

2016-11-05 Thread Richard Gaskin

stephen barncard wrote:

> On Sat, Nov 5, 2016 at 11:28 AM, Richard Gaskin wrote:
>
>> I've grown weary of stack name conflict over the years, and this
>> morning decided to take some time to assess where we're really at
>> with that and see if perhaps there's a way to handle things more
>> liberally than how the IDE does now.
>>
>> TL/DR version:  It seems there's actually no real problem at all.
>
> Thanks Richard, this has been driving me nuts since the first day
> I used Revolution, and it was terrifying. Most of the time I just
> forced quit.
>
> One wonders how many 'solutions to non-problems' are there still
> working in LC? Things we've been doing for years...

I should clarify that by "no real problem at all" I'm thinking in terms 
of sharing stacks among potentially-large teams of people who know what 
they're doing.  In my workflow, learning the rule of stack name 
resolution isn't a big price to pay for the simplicity and flexibility 
of being able to work on anything at any time regardless of its name.


So more specifically, it's fine *in the engine*.

But the *IDE* has different responsibilities.

I didn't close my feature request yet because I'm undecided about the 
best way to provide useful guidance for new users who might spend all 
day working on the wrong stack without some sort of warning.


Like you, I've had issues trying to use the existing dialog, never quite 
certain what either option will do before I pick one, and never quite 
sure it did what I thought it would do after I clicked it.  And like 
you, I've usually found it at least mentally simpler to quit and start 
with a fresh session.


But perhaps there's another option we haven't yet considered, one which 
provides sufficient guidance so folks know which stack they're working 
on, but perhaps less ominous and complex than the solution in place now.


Suggestions?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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


Re: Stack name conflicts resolved?

2016-11-05 Thread Monte Goulding

> On 6 Nov. 2016, at 5:28 am, Richard Gaskin  wrote:
> 
> That is, once we modify the IDE to allow it.

^ this is the issue. For the most part it isn’t the engine that has the issue 
with multiple stacks with the same name open it’s the IDE. There would be 
bucket loads of work involved in getting the IDE to play nicely with multiple 
stacks with the same name open.

Cheers

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

Re: Stack name conflicts resolved?

2016-11-05 Thread Richard Gaskin

Monte Goulding wrote:

>> On 6 Nov. 2016, at 5:28 am, Richard Gaskin wrote:
>>
>> That is, once we modify the IDE to allow it.
>
> ^ this is the issue. For the most part it isn’t the engine that has
> the issue with multiple stacks with the same name open it’s the IDE.
> There would be bucket loads of work involved in getting the IDE to
> play nicely with multiple stacks with the same name open.

I imagine for good reason, but I'm curious: where does topstack not do 
what an IDE needs?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Stack name conflicts resolved?

2016-11-05 Thread stephen barncard
On Sat, Nov 5, 2016 at 11:28 AM, Richard Gaskin 
wrote:

> I've grown weary of stack name conflict over the years, and this morning
> decided to take some time to assess where we're really at with that and see
> if perhaps there's a way to handle things more liberally than how the IDE
> does now.
>
> TL/DR version:  It seems there's actually no real problem at all.
>

Thanks Richard, this has been driving me nuts since the first day I
used Revolution, and it was terrifying. Most of the time I just forced quit.

One wonders how many 'solutions to non-problems' are there still working in
LC? Things we've been doing for years...

(ps I love the thread on the bug report. humor takes many forms.)

Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
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


Background colour of a new stack

2016-11-05 Thread Graham Samuel
This may be old news to some, but in the LC7x series and earlier, if you 
created a stack, the card displayed as white. In LC 8.1.1, it displays as grey 
(reported as 220,220,220). To make cards look the way they did in earlier 
versions, I have to created a background rectangle graphic specifically 
coloured white. 

Was this a deliberate change? Or have I  made some odd mistake? Looks like I 
need to tweak some cards.

Graham


___
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: Updating Text-Script Only Stacks in Run-Time, Message Path Memory

2016-11-05 Thread Sannyasin Brahmanathaswami
right… not the engine… 
some IDE gremlin… 
restarted LC… 

open some script only stack that had been put into use earlier, 
edit save and the changes are available runtime.  

So, yes… something is causing the IDE not to pick up the changes in the open 
scripts and (re)placing it in the message path.

no recipe…

BR
 

On 11/5/16, 9:28 AM, "use-livecode on behalf of J. Landman Gay" 
 
wrote:

>
>ERGO conclude: editing a script only stack and saving it does *not*
>update the "live" version of that file in memory that is in use by
>the engine.

Actually, I've seen the same thing occasionally in regular stack scripts 
too, not just script-only stacks. There's been an issue with window 
confusion for some time, but I have never been able to get a reliable 
recipe.

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

Re: Stack name conflicts resolved?

2016-11-05 Thread Mark Wieder

On 11/05/2016 03:02 PM, Monte Goulding wrote:



On 6 Nov. 2016, at 5:28 am, Richard Gaskin  wrote:

That is, once we modify the IDE to allow it.


^ this is the issue. For the most part it isn’t the engine that has the issue 
with multiple stacks with the same name open it’s the IDE. There would be 
bucket loads of work involved in getting the IDE to play nicely with multiple 
stacks with the same name open.


That is indeed the issue.
The IDE for some reason allows multiple controls with the same name but 
keeps track of their individual identities, but insists that stack names 
be unique in memory.


When new stacks are created in memory they are assigned the id 1002.
Why?
If there's a stack already in memory why not create the new stack with 
the next sequential id?

Then the combination of id and filename should uniquely identify a stack.

--
 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: Updating Text-Script Only Stacks in Run-Time, Message Path Memory

2016-11-05 Thread Mark Wieder

On 11/05/2016 02:39 PM, Sannyasin Brahmanathaswami wrote:


So, yes… something is causing the IDE not to pick up the changes in the open 
scripts and (re)placing it in the message path.


Yep. It's one of the two reasons I don't use script-only stacks.

--
 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: Background colour of a new stack

2016-11-05 Thread Graham Samuel
Thanks Randy, I hadn’t realised I could do that. Excellent!

Graham

> On 5 Nov 2016, at 22:40, Randy Hengst  wrote:
> 
> Graham,
> 
> I also thought the change of color to be a bit odd. 
> 
> If I understood you correctly, you are adding a graphic to “cover up” the 
> gray background. You don’t need to add a graphic to create the white 
> background. Go to the Stack Inspector and change the backgroundColor to 
> white. Then each card you make in the stack will have the white background.
> 
> be well,
> randy
> 
> Randy Hengst
> www.classroomFocusedSoftware.com
> 
> 
> 
>> On Nov 5, 2016, at 4:30 PM, Richard Gaskin  
>> wrote:
>> 
>> Graham Samuel wrote:
>> 
>>> This may be old news to some, but in the LC7x series and earlier, if
>>> you created a stack, the card displayed as white. In LC 8.1.1, it
>>> displays as grey (reported as 220,220,220). To make cards look the
>>> way they did in earlier versions, I have to created a background
>>> rectangle graphic specifically coloured white.
>>> 
>>> Was this a deliberate change? Or have I  made some odd mistake? Looks
>>> like I need to tweak some cards.
>> 
>> I believe the current default background is inherited from the OS, part of 
>> the theming enhancements that make LC 8 much more HIG-savvy than earlier 
>> versions.
>> 
>> -- 
>> 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
> 
> ___
> 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

Updating Text-Script Only Stacks in Run-Time, Message Path Memory

2016-11-05 Thread Sannyasin Brahmanathaswami
I ran into this today: Run a boot stack that has a list of stack files,
Initialization script loads N number of stacks as libs with "start using stack 
x" on a loop

So far so good. I can run cmds from the message box to fire handlers in any of 
the stacks that were loaded with "start using"

Run into small bug… need to do some testing. All the stacks in use appear in 
the project browser

Open script of stack "model_preferences"  in the script editor,  Add a new 
handler

command checkPrefsFilePath
  answer "Hello" with "Gotcha"
# my default test just to see if the handler is in the message path before 
actually "coding it out"
end checkPrefsFilePath

--click yellow button… save … LC IDE flashes the "saving stack… " modal…
--go to message box; enter "checkPrefsFilePath"
--msg box returns

"checkPrefsFilePath"  and does not fire my handler… I set a break point on 
another handler that was in the script before startup of this session

go to msg box; enter "setPref"
and it breaks on my break point: ergo the engine sees it/found it.

But the engine does not yet "see" my new handler.  Just for fun: open stack 
file on disk.. in BBEdit: yes, confirmed, my changes are there.

ERGO conclude: editing a script only stack and saving it does *not* update the 
"live" version of that file in memory that is in use by the engine.

I guess this "kinda" makes sense, since the message path was already 
"assembled' at start up and editing and save script only stacks doesn’t' 
necessary make any change to that message path.

But, am I the only on that thinks this is odd behavior? If I am right, doesn't 
it break the "write, run with no compile" principle of LiveCode?  If I edit the 
script of a binary stack, those changes are immediately implemented. Should it 
not be the same for script only stacks?

OK, so given the current behavior, assuming I'm not missing something simple, 
do we have to manually re-issue a "start using stack 
"preferences.livecodescript" every time we edit it's script?

What am I missing.

BR







___
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