Re: CantDelete
Another bingo! The cantSelect does do it. However, that seems to have to be set by a script. I understand that you then can’t select it with the pointer tool to show the Property Inspector for it, so not having a checkbox to set that property makes some sense. But it would be nice to have that checkbox in the PI when you select the object another way. On Oct 8, 2016, at 11:36 PM, Monte Goulding wrote: > >> On 9 Oct 2016, at 5:33 PM, Peter Bogdanoff wrote: >> >> Card objects are still “unprotected”? > > yes, although have you thought about setting the cantModify of the stack or > the cantSelect of the objects? > ___ > 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: CantDelete
> On 9 Oct 2016, at 5:33 PM, Peter Bogdanoff wrote: > > Card objects are still “unprotected”? yes, although have you thought about setting the cantModify of the stack or the cantSelect of the objects? ___ 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: CantDelete
Yes, I didn’t know about selectGroupedControls. Thank you! That definitely does the trick for groups. Card objects are still “unprotected”? On Oct 8, 2016, at 11:25 PM, Monte Goulding wrote: > >> On 9 Oct 2016, at 5:23 PM, Peter Bogdanoff wrote: >> >> Is there any particular reason a field, button, graphic, etc. cannot have a >> “cantDelete” property—just as stacks/cards/groups currently do have? >> >> A group can have this property set, but individual controls in that group >> cannot. If selectGrouped is on I can accidentally delete a control. There >> are objects for which I do not want this to happen. >> >> Is this a reasonable feature request? > > Is it reasonable to set the selectGroupedControls of the group in question to > false? > > 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 ___ 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: CantDelete
> On 9 Oct 2016, at 5:23 PM, Peter Bogdanoff wrote: > > Is there any particular reason a field, button, graphic, etc. cannot have a > “cantDelete” property—just as stacks/cards/groups currently do have? > > A group can have this property set, but individual controls in that group > cannot. If selectGrouped is on I can accidentally delete a control. There are > objects for which I do not want this to happen. > > Is this a reasonable feature request? Is it reasonable to set the selectGroupedControls of the group in question to false? 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: Understanding 'the defaultStack'
> On 9 Oct 2016, at 4:21 PM, J. Landman Gay wrote: > > It's only non-obvious if you haven't been doing it for 30 years. :-) That’s not selling it to me ;-) 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
CantDelete
Is there any particular reason a field, button, graphic, etc. cannot have a “cantDelete” property—just as stacks/cards/groups currently do have? A group can have this property set, but individual controls in that group cannot. If selectGrouped is on I can accidentally delete a control. There are objects for which I do not want this to happen. Is this a reasonable feature request? Peter Bogdanoff ___ 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: Understanding 'the defaultStack'
It's only non-obvious if you haven't been doing it for 30 years. :-) Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On October 8, 2016 6:48:08 PM Monte Goulding wrote: I suspect the fact that go sets the defaultStack (if it is topLevel) and neither clone stack or create stack do regardless of mode also needs to be documented somewhere. I wonder if go altering the defaultStack should be added to the bug db as an anomaly report? It’s certainly a non-obvious side effect of the command. On 9 Oct 2016, at 10:26 AM, Monte Goulding wrote: Hi Folks I just had a look into the source and here’s the but in the go command causing confusion: if (t_stack->getmode() == WM_TOP_LEVEL || t_stack->getmode() == WM_TOP_LEVEL_LOCKED) MCdefaultstackptr = t_stack; What this means is that unless the mode of the stack is topLevel (1) or topLevel + cantModify (2) the defaultStack is not changed by the go command. 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 ___ 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: Understanding 'the defaultStack'
On October 8, 2016 7:06:15 PM Monte Goulding wrote: I can’t help thinking that go touching the defaultStack at all is bug or rather a bad idea in the first place that probably can’t be changed now. Just because you opened a stack does not necessarily mean you want to target the rest of your script to the stack you opened. Actually that's been the whole xtalk metaphor forever and you're right that changing it would break a lot of stacks. When you go to a stack, it becomes "this stack", and you are on "this card" and you expect your script to act on the controls there. It dates back to HC where there was only a single stack open at any time and no confusion was possible. With the introduction of multiple windows, the behavior stayed the same and if you want to address objects in the original stack, you need to use long object references or set the defaultstack yourself. I'm okay with how it works now, but I want to know what the exceptions are. I think I'm starting to get the idea. 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: Understanding 'the defaultStack'
> On 9 Oct 2016, at 10:51 AM, Jeanne A. E. DeVoto > wrote: > > OK, thar seems like a bug to me. If the only stacks open are palettes, for > example, then go should make the target stack the topStack (and hence the > defaultStack, since no stacks of lower mode are open). Thinking on this some more I don’t think you can do what you are suggesting here. Go currently sets the defaultStack to the target stack if it is topLevel. If it set the defaultStack to the topStack it would depend on the current state of the environment whether the defaultStack is the stack being opened by go after the command while at the moment it just depends on the mode of the stack being opened. Indeed let’s say you have stack A that opens stack B and stack B that opens stack C in its preOpenCard handler. At the moment: stack A - is defaultStack in its own script go stack B stack B preOpenStack - stack B now defaultStack in its own script go stack C stack C preOpenStack - stack C no defaultStack in its own script stack B preOpenStack continues but stack C is now the defaultStack back to stack A script and now stack B is the defaultStack But if you change it to set to the topStack then when you go back to the stack A script then stack C will be the defaultStack. 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: Understanding 'the defaultStack'
> On 9 Oct 2016, at 10:51 AM, Jeanne A. E. DeVoto > wrote: > > OK, thar seems like a bug to me. If the only stacks open are palettes, for > example, then go should make the target stack the topStack (and hence the > defaultStack, since no stacks of lower mode are open). I can’t help thinking that go touching the defaultStack at all is bug or rather a bad idea in the first place that probably can’t be changed now. Just because you opened a stack does not necessarily mean you want to target the rest of your script to the stack you opened. > > (In practice, I usually adopt the strategy of setting the defaultStack > explicitly or else targeting everything to the specific stack I want. I think > of the defaultStack as being pretty fragile.) Yes that’s what I do to as the script is much clearer if you explicitly set the defaultStack anyway. 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: Understanding 'the defaultStack'
At 10:26 AM +1100 10/9/2016, Monte Goulding wrote: I just had a look into the source and here's the but in the go command causing confusion: if (t_stack->getmode() == WM_TOP_LEVEL || t_stack->getmode() == WM_TOP_LEVEL_LOCKED) MCdefaultstackptr = t_stack; What this means is that unless the mode of the stack is topLevel (1) or topLevel + cantModify (2) the defaultStack is not changed by the go command. OK, thar seems like a bug to me. If the only stacks open are palettes, for example, then go should make the target stack the topStack (and hence the defaultStack, since no stacks of lower mode are open). (In practice, I usually adopt the strategy of setting the defaultStack explicitly or else targeting everything to the specific stack I want. I think of the defaultStack as being pretty fragile.) ___ 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: Understanding 'the defaultStack'
I suspect the fact that go sets the defaultStack (if it is topLevel) and neither clone stack or create stack do regardless of mode also needs to be documented somewhere. I wonder if go altering the defaultStack should be added to the bug db as an anomaly report? It’s certainly a non-obvious side effect of the command. > On 9 Oct 2016, at 10:26 AM, Monte Goulding wrote: > > Hi Folks > > I just had a look into the source and here’s the but in the go command > causing confusion: > >if (t_stack->getmode() == WM_TOP_LEVEL || t_stack->getmode() == > WM_TOP_LEVEL_LOCKED) >MCdefaultstackptr = t_stack; > > What this means is that unless the mode of the stack is topLevel (1) or > topLevel + cantModify (2) the defaultStack is not changed by the go command. > > 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 ___ 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: Understanding 'the defaultStack'
That's what I saw too in my experiment, but I was issuing commands from the message box. When Graham did a "go stack invisibleStack" the defaultstack didn't change to it. From what Monte said, I'm guessing that Graham's running script was in the original stack and maybe the engine hadn't done its swap yet. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On October 8, 2016 6:17:48 PM "Jeanne A. E. DeVoto" wrote: At 3:54 PM -0500 10/8/2016, J. Landman Gay wrote: I thought visibility might impact it (I believe that's the case with Graham's stack) so I did some quick tests and even though there was a visible mode-1 topstack, going to the invisible one did change the defaultstack. Thus, my curiosity. I quote: "The topStack is the frontmost stack with the lowest mode." The mode runs from 0 to 13 (unless someone's added some modes lately), and invisible isn't one of the modes-a toplevel visible stack has the same mode as a toplevel invisible one. (I don't claim this makes actual sense, mind you) -- jeanne a. e. devoto livec...@jaedworks.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: Understanding 'the defaultStack'
Hi Folks I just had a look into the source and here’s the but in the go command causing confusion: if (t_stack->getmode() == WM_TOP_LEVEL || t_stack->getmode() == WM_TOP_LEVEL_LOCKED) MCdefaultstackptr = t_stack; What this means is that unless the mode of the stack is topLevel (1) or topLevel + cantModify (2) the defaultStack is not changed by the go command. 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: Understanding 'the defaultStack'
> On 9 Oct 2016, at 10:15 AM, Jeanne A. E. DeVoto > wrote: > > (I don't claim this makes actual sense, mind you) What about this: go invisible stack do some stuff depending on the defaultstack being changed to the stack show stack ___ 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: Understanding 'the defaultStack'
At 3:54 PM -0500 10/8/2016, J. Landman Gay wrote: I thought visibility might impact it (I believe that's the case with Graham's stack) so I did some quick tests and even though there was a visible mode-1 topstack, going to the invisible one did change the defaultstack. Thus, my curiosity. I quote: "The topStack is the frontmost stack with the lowest mode." The mode runs from 0 to 13 (unless someone's added some modes lately), and invisible isn't one of the modes-a toplevel visible stack has the same mode as a toplevel invisible one. (I don't claim this makes actual sense, mind you) -- jeanne a. e. devoto livec...@jaedworks.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: Understanding 'the defaultStack'
> On 9 Oct 2016, at 9:09 AM, Graham Samuel wrote: > > Monte, thanks for that, but even your expert intervention this doesn't quite > say what the rules actually are. I think the Dictionary should be revised to > give a complete account. Expert intervention might be overestimating things a bit. Yes it would probably be good if someone improved the docs if it’s causing confusion. For what it’s worth I personally never depend on the defaultStack being anything unless I explicitly set it and I usually only do that when I want to create objects on a stack from some script that isn’t on it. 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: Understanding 'the defaultStack'
Monte, thanks for that, but even your expert intervention this doesn't quite say what the rules actually are. I think the Dictionary should be revised to give a complete account. Cheers Graham Sent from my iPad > On 8 Oct 2016, at 21:51, Monte Goulding wrote: > > >> On 9 Oct 2016, at 7:22 AM, Richard Gaskin wrote: >> >> The rule Dr. Raney gave me is that the defaultStack is the topmost visible >> stack of the lowest mode. > > ^ that’s pretty close but there are some other things that come into play. > It’s a bit of a slippeyr fish. > > The defaultStack is set when executing a script to the stack the script is in > until it is changed by that script. After the script runs it will be reset to > the previous value unless the previous defaultStack happened to be deleted. > > Some events cause the defaultStack to be set to the topStack. The default > stack is reset in the main engine loop to the stack Richard described. > > 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 ___ 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: Understanding 'the defaultStack'
J. Landman Gay wrote: On 10/8/16 3:22 PM, Richard Gaskin wrote: The rule Dr. Raney gave me is that the defaultStack is the topmost visible stack of the lowest mode. I thought visibility might impact it (I believe that's the case with Graham's stack) so I did some quick tests and even though there was a visible mode-1 topstack, going to the invisible one did change the defaultstack. Thus, my curiosity. I.e.: Stack One visible topstack mode 1 command: go stack stackTwo stackTwo visibility false mode 1 command: put the defaultstack -> stackTwo So...? Personally I'd consider that a bug. Even if visibility was never part of a formal definition, so much of the learnability of xTalk rests on being able to predict outcomes based on what we see. The layering of a window visibly changes if a window above it becomes hidden, all the way down to how the OS renders the drag region. To me it seems logical that an invisible window should be expected to require special handling if another window of the same mode is visible. I can't think of a case where the behavior you've documented would be either anticipatable or desirable. -- 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: Understanding 'the defaultStack'
I have a stack that in one place and one place only when the script calls for “ask … with … as sheet” sheets the ask dialog and then it promptly loses focus. If I try to type a replacement for the default text or hit to affirm the default text, nothing happens — the dialog has lost focus as one can see by the hilite color for the text and the lack of blue background for the “OK” button. I have to click in the text field, then do what I want with the dialog. Have not tracked this down. At this point I can’t recall which “ask…” command this occurs in so I can post that section of script, but it only happens in that one place. I don’t know if this is related to the defaultstack issue. — Peter Peter M. Brigham pmb...@gmail.com > On Oct 8, 2016, at 4:54 PM, J. Landman Gay wrote: > > On 10/8/16 3:22 PM, Richard Gaskin wrote: >> The rule Dr. Raney gave me is that the defaultStack is the topmost >> visible stack of the lowest mode. > > I thought visibility might impact it (I believe that's the case with Graham's > stack) so I did some quick tests and even though there was a visible mode-1 > topstack, going to the invisible one did change the defaultstack. Thus, my > curiosity. > > I.e.: > > Stack One > visible > topstack > mode 1 > > > command: go stack stackTwo > > stackTwo > visibility false > mode 1 > > command: put the defaultstack > -> stackTwo > > > So...? > > -- > 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: Understanding 'the defaultStack'
On 10/8/16 3:22 PM, Richard Gaskin wrote: The rule Dr. Raney gave me is that the defaultStack is the topmost visible stack of the lowest mode. I thought visibility might impact it (I believe that's the case with Graham's stack) so I did some quick tests and even though there was a visible mode-1 topstack, going to the invisible one did change the defaultstack. Thus, my curiosity. I.e.: Stack One visible topstack mode 1 command: go stack stackTwo stackTwo visibility false mode 1 command: put the defaultstack -> stackTwo So...? -- 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: Understanding 'the defaultStack'
> On 9 Oct 2016, at 7:22 AM, Richard Gaskin wrote: > > The rule Dr. Raney gave me is that the defaultStack is the topmost visible > stack of the lowest mode. ^ that’s pretty close but there are some other things that come into play. It’s a bit of a slippeyr fish. The defaultStack is set when executing a script to the stack the script is in until it is changed by that script. After the script runs it will be reset to the previous value unless the previous defaultStack happened to be deleted. Some events cause the defaultStack to be set to the topStack. The default stack is reset in the main engine loop to the stack Richard described. 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: Understanding 'the defaultStack'
J. Landman Gay wrote: > I have seen cases where the defaultstack doesn't follow the rule, > or uses some criteria I don't understand, where "go" doesn't set > the defaultstack automatically. I haven't yet pinned down a recipe. > Usually I just set it by script and move on. The rule Dr. Raney gave me is that the defaultStack is the topmost visible stack of the lowest mode. Beyond that I believe the only exceptions are normal scoping rules, such as a script in a palette stack referring to a button will try to resolve that reference in itself unless some other stack is specified. But even then, calling "the defaultStack", regardless of where it's called from, should reflect that one rule unless you've explicitly sat it to something else. If there are indeed exceptions it would be handy to find them and fix them. Having a single rule for the defaultStack makes it very useful, and Raney'a definition seems logical. If there are exceptions we might want to think long and hard about keeping them, as they may well be just regressions that crept in somewhere over the years. I can't think of a case offhand where anything other than the one rule would be desirable. -- 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: Understanding 'the defaultStack'
On 10/8/16 10:37 AM, Dr. Hawkins wrote: On Fri, Oct 7, 2016 at 10:50 PM, Mark Wieder wrote: FWIW I think Jacque's explanation is the better of the two. I think maybe LiveCode should ship her with every new build of the dictionary. on revBuildDictionary clone Jacque set the mainStack of it to stack revDictionary end revBuildDictionary :) Well, I'm flattered guys, but unfortunately every time I clone myself the variants lose track of each other and efficiency fragments. Git might be better. ;) But I'm not the right choice anyway because I don't know some of this myself -- I have seen cases where the defaultstack doesn't follow the rule, or uses some criteria I don't understand, where "go" doesn't set the defaultstack automatically. I haven't yet pinned down a recipe. Usually I just set it by script and move on. I think that was the case with Graham's stack too. Some quirky rule is interfering, or else it's a bug. If so, it's been there a long time. It would be great if someone could look at the source code and give us a list of how the engine determines the defaultstack. Then I could write it down, wait until everyone else forgets about it, and then post it like I know everything... -- 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: LiveCode meeting
In Phoenix at the moment, it would be an extravagant trip! Hope it goes well. > On Oct 8, 2016, at 9:28 AM, Mark Schonewille > wrote: > > At least one person will travel to the Netherlands. If you want to be there > too, you're welcome. Let me know if you need help finding a hotel. > > I have no plans for a web stream, but you never know. > > -- > Kind regards, > > Mark Schonewille > Economy-x-Talk > Http://economy-x-talk.com > > Share the clipboard of your computer over a local network with Clipboard Link > http://clipboardlink.economy-x-talk.com > > > Op 8 okt. 2016 om 18:08 heeft Colin Holgate het > volgende geschreven: > >> When you say this, do you mean you will have a web stream, or are you >> thinking that foreign participants would fly to Utrecht that day? >> >> >>> On Oct 8, 2016, at 7:44 AM, Mark Schonewille >>> wrote: >>> >>> Sunday 16th October I will organise a meeting somewhere in the Netherlands >>> (Tilburg or Utrecht. I know it is on short notice, but by oganising it on >>> this date, we make it possible for a foreign participant to be present at >>> the meeting. I hope you will be able to attent the meeting on this day. >> >> ___ >> 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: LiveCode meeting
At least one person will travel to the Netherlands. If you want to be there too, you're welcome. Let me know if you need help finding a hotel. I have no plans for a web stream, but you never know. -- Kind regards, Mark Schonewille Economy-x-Talk Http://economy-x-talk.com Share the clipboard of your computer over a local network with Clipboard Link http://clipboardlink.economy-x-talk.com Op 8 okt. 2016 om 18:08 heeft Colin Holgate het volgende geschreven: > When you say this, do you mean you will have a web stream, or are you > thinking that foreign participants would fly to Utrecht that day? > > >> On Oct 8, 2016, at 7:44 AM, Mark Schonewille >> wrote: >> >> Sunday 16th October I will organise a meeting somewhere in the Netherlands >> (Tilburg or Utrecht. I know it is on short notice, but by oganising it on >> this date, we make it possible for a foreign participant to be present at >> the meeting. I hope you will be able to attent the meeting on this day. > > ___ > 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: LiveCode meeting
When you say this, do you mean you will have a web stream, or are you thinking that foreign participants would fly to Utrecht that day? > On Oct 8, 2016, at 7:44 AM, Mark Schonewille > wrote: > > Sunday 16th October I will organise a meeting somewhere in the Netherlands > (Tilburg or Utrecht. I know it is on short notice, but by oganising it on > this date, we make it possible for a foreign participant to be present at the > meeting. I hope you will be able to attent the meeting on this day. ___ 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: Understanding 'the defaultStack'
On Fri, Oct 7, 2016 at 10:50 PM, Mark Wieder wrote: > FWIW I think Jacque's explanation is the better of the two. > I think maybe LiveCode should ship her with every new build of > the dictionary. > on revBuildDictionary clone Jacque set the mainStack of it to stack revDictionary end revBuildDictionary :) -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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
LiveCode meeting
Beste dames en heren, Op zondag 16 oktober organiseren we een LiveCode meeting ergens in Nederland (Tilburg of Utrecht). Het is een beetje kortdag, maar deze datum maakt het voor een buitenlandse deelnemer mogelijk om aanwezig te zijn. Ik hoop dat jullie op deze dag aanwezig kunnen zijn. Het wordt een informele bijeenkomst van enkele uren. Tot de mogelijke onderwerpen behoren: LiveCode 8, widgets, Valentina, SuperCard 4.8, Arduino, de nieuwe HyperDuino, en HyperStudio. Daarnaast nodigen we je graag uit om iets over je eigen project(en) te vertellen of vragen te stellen aan collega-LiveCoders. Voorts verloten we een licentie van HyperStudio en een exemplaar van het boek Programming LiveCode for the Real Beginner. Er bestaat ook nog een plan om de volgende meeting in februari of maart in Antwerpen te houden. Hierover zal tijdens de eerstvolgende meeting overleg plaatsvinden. Wil je meebeslissen, zorg dan dat je erbij bent. Ik zal binnen enkele dagen nog een e-mailtje sturen aan eenieder die op mijn lijstje staat. Ik hoop later in de week met meer nieuws te komen. Dear ladies and gentlemen, Sunday 16th October I will organise a meeting somewhere in the Netherlands (Tilburg or Utrecht. I know it is on short notice, but by oganising it on this date, we make it possible for a foreign participant to be present at the meeting. I hope you will be able to attent the meeting on this day. The meeting will be informal and take several hours. Possible subjects are: LiveCode 8, widgets, SuperCard 4.8, Arduino, de new HyperDuino, and HyperStudio. You are also invited to tell something about your own project(s) or to ask your fellow-LiveCoders a number of questions. Additionally we raffle off a licence of HyperStudio and a copy of the book Programming LiveCode for the Real Beginner. Moreover there is a plan to organise a meeting in february or march in Antwerp (Belgium). We will talk about this at the first next meeting. Make sure you're there, if you would like to be involved in any decisions. I'll send an e-mail to everyone on my list within a few days. Hopefully I'll be able to provide more news later this week. -- Kind regards, Mark Schonewille http://economy-x-talk.com https://www.facebook.com/marksch Buy the most extensive book on the LiveCode language: http://livecodebeginner.economy-x-talk.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: Could not create movie reference
Hi Tiemo, is the file system set to be case sensitive and the filename of the (a) movie in a different spelling (upper / lower case) then your player object refers to? Cheers, Malte ___ 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
