Re: iOS simulator not responding
Great! I have a vague memory of trying to have a transparent entry field so that it could show some faint placeholder text when empty then change to opaque when any text was entered, and not being able to get it to work. Terry... On 27/11/19, 2:39 pm, "use-livecode on behalf of J. Landman Gay via use-livecode" wrote: Found it, it was the alpha. When I leave that out, it displays, is editable, and works. Thank you! On 11/26/19 8:16 PM, Terry Judd via use-livecode wrote: > I primarily use single line input fields on my apps' login screens. Here's what I do for a password field - for a 'normal' field I just change the 'contentType' to 'plain'. > > mobileControlCreate "input", pControlName > mobileControlSet pControlName, "rect", the rect of pObj > mobileControlSet pControlName, "opaque", true > mobileControlSet pControlName, "visible", true > mobileControlSet pControlName, "contentType", "password" > mobileControlSet pControlName, "borderStyle", "bezel" > mobileControlSet pControlName, "fontSize", "18" > mobileControlSet pControlName, "textAlign", "left" > mobileControlSet pControlName, "returnKeyType", "default" > mobileControlSet pControlName, "autoCorrectionType", "no" > mobileControlSet pControlName, "autoCapitalizationType", "none" > mobileControlSet pControlName, "keyboardStyle", "alert" > > HTH, > > Terry... > > On 27/11/19, 1:00 pm, "use-livecode on behalf of J. Landman Gay via use-livecode" wrote: > > Thanks Terry. I keep finding new things. It turns out my multiline fields > are working, but the single input ones do not. Very strange. > > Do you have single line inputs? > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > On November 26, 2019 5:26:05 PM Terry Judd via use-livecode > wrote: > > > Not sure if it will help, but here's the code I use to create a multiline > > text control (pControlName) on iOS that 'overlays' an existing LC field (pObj) > > > > # create a native multiline text control > > put the rect of pObj into tRect > > # shrink the rect by 1 pixel all around to reveal the object's border > > add 1 to item 1 of tRect > > add 1 to item 2 of tRect > > add -1 to item 3 of tRect > > add -1 to item 4 of tRect > > mobileControlCreate "multiline", pControlName > > mobileControlSet pControlName, "rect", tRect > > mobileControlSet pControlName, "opaque", true > > mobileControlSet pControlName, "visible", true > > mobileControlSet pControlName, "contentType", "plain" > > mobileControlSet pControlName, "fontSize", "18" > > mobileControlSet pControlName, "textAlign", "left" > > mobileControlSet pControlName, "returnKeyType", "default" > > mobileControlSet pControlName, "autoCorrectionType", "default" > > mobileControlSet pControlName, "autoCapitalizationType", "sentences" > > mobileControlSet pControlName, "keyboardStyle", "default" > > > > You use 'editable' and 'enabled' as parameters for mobileControlSet but I > > don't use either of those. I use 'opaque' but you don't because you are > > after a transparent effect - I wonder whether 'opaque' can be used in > > conjunction with 'alpha' though? > > > > Terry... > > > > > > ?On 27/11/19, 6:46 am, "use-livecode on behalf of J. Landman Gay via > > use-livecode" > use-livecode@lists.runrev.com> wrote: > > > >I have reduced the problem to iOS input fields. Some testing shows that: > > > >* The native fields exist > >* Their rect is correct > >* If I script their text data, it is there and can be retrieved > > > >But they are inactive, can't be tapped, don't show any text even if its > >entry is scripted, can't be typed into, can't be focused. They act like > >they are invisible. > > > >Here is what I do to create them. This is a generic handler that creates > >all input fields throughout the app, and it works fine on Android. > >Usually I call it like this: createInputFld "email". The other params > >are used only occasionally. > > > >command createInputFld pName,pReturnKey,pMultiline -- native single-line > >input > > -- pName = any valid fld identifier (long name, ID, etc) > > -- pReturnKey = return key type, usually "search" > > -- pMultiline = boolean, whether to create a multi-line input >
Re: iOS simulator not responding
Found it, it was the alpha. When I leave that out, it displays, is editable, and works. Thank you! On 11/26/19 8:16 PM, Terry Judd via use-livecode wrote: I primarily use single line input fields on my apps' login screens. Here's what I do for a password field - for a 'normal' field I just change the 'contentType' to 'plain'. mobileControlCreate "input", pControlName mobileControlSet pControlName, "rect", the rect of pObj mobileControlSet pControlName, "opaque", true mobileControlSet pControlName, "visible", true mobileControlSet pControlName, "contentType", "password" mobileControlSet pControlName, "borderStyle", "bezel" mobileControlSet pControlName, "fontSize", "18" mobileControlSet pControlName, "textAlign", "left" mobileControlSet pControlName, "returnKeyType", "default" mobileControlSet pControlName, "autoCorrectionType", "no" mobileControlSet pControlName, "autoCapitalizationType", "none" mobileControlSet pControlName, "keyboardStyle", "alert" HTH, Terry... On 27/11/19, 1:00 pm, "use-livecode on behalf of J. Landman Gay via use-livecode" wrote: Thanks Terry. I keep finding new things. It turns out my multiline fields are working, but the single input ones do not. Very strange. Do you have single line inputs? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On November 26, 2019 5:26:05 PM Terry Judd via use-livecode wrote: > Not sure if it will help, but here's the code I use to create a multiline > text control (pControlName) on iOS that 'overlays' an existing LC field (pObj) > > # create a native multiline text control > put the rect of pObj into tRect > # shrink the rect by 1 pixel all around to reveal the object's border > add 1 to item 1 of tRect > add 1 to item 2 of tRect > add -1 to item 3 of tRect > add -1 to item 4 of tRect > mobileControlCreate "multiline", pControlName > mobileControlSet pControlName, "rect", tRect > mobileControlSet pControlName, "opaque", true > mobileControlSet pControlName, "visible", true > mobileControlSet pControlName, "contentType", "plain" > mobileControlSet pControlName, "fontSize", "18" > mobileControlSet pControlName, "textAlign", "left" > mobileControlSet pControlName, "returnKeyType", "default" > mobileControlSet pControlName, "autoCorrectionType", "default" > mobileControlSet pControlName, "autoCapitalizationType", "sentences" > mobileControlSet pControlName, "keyboardStyle", "default" > > You use 'editable' and 'enabled' as parameters for mobileControlSet but I > don't use either of those. I use 'opaque' but you don't because you are > after a transparent effect - I wonder whether 'opaque' can be used in > conjunction with 'alpha' though? > > Terry... > > > ?On 27/11/19, 6:46 am, "use-livecode on behalf of J. Landman Gay via > use-livecode" use-livecode@lists.runrev.com> wrote: > >I have reduced the problem to iOS input fields. Some testing shows that: > >* The native fields exist >* Their rect is correct >* If I script their text data, it is there and can be retrieved > >But they are inactive, can't be tapped, don't show any text even if its >entry is scripted, can't be typed into, can't be focused. They act like >they are invisible. > >Here is what I do to create them. This is a generic handler that creates >all input fields throughout the app, and it works fine on Android. >Usually I call it like this: createInputFld "email". The other params >are used only occasionally. > >command createInputFld pName,pReturnKey,pMultiline -- native single-line >input > -- pName = any valid fld identifier (long name, ID, etc) > -- pReturnKey = return key type, usually "search" > -- pMultiline = boolean, whether to create a multi-line input > put (the rect of control pName) into tRect > subtract 10 from item 2 of tRect -- adjust for mobile > add 10 to item 4 of tRect -- may not need for iOS > if pMultiLine = true then > mobileControlCreate "multiline", pName > else > mobileControlCreate "input", pName > end if > mobileControlSet pName, "rect", tRect > mobileControlSet pName, "autoCapitalizationType", "none" > mobileControlSet pName, "autoCorrectionType", "no" > mobileControlSet pName, "enabled", true > mobileControlSet pName, "editable", true -- multiline only (?) > mobileControlSet pName, "alpha", 0 -- transparent > mobileControlSet pName, "textalign", the effective textalign of >control pName > mobileControlSet pName,
Re: iOS simulator not responding
I primarily use single line input fields on my apps' login screens. Here's what I do for a password field - for a 'normal' field I just change the 'contentType' to 'plain'. mobileControlCreate "input", pControlName mobileControlSet pControlName, "rect", the rect of pObj mobileControlSet pControlName, "opaque", true mobileControlSet pControlName, "visible", true mobileControlSet pControlName, "contentType", "password" mobileControlSet pControlName, "borderStyle", "bezel" mobileControlSet pControlName, "fontSize", "18" mobileControlSet pControlName, "textAlign", "left" mobileControlSet pControlName, "returnKeyType", "default" mobileControlSet pControlName, "autoCorrectionType", "no" mobileControlSet pControlName, "autoCapitalizationType", "none" mobileControlSet pControlName, "keyboardStyle", "alert" HTH, Terry... On 27/11/19, 1:00 pm, "use-livecode on behalf of J. Landman Gay via use-livecode" wrote: Thanks Terry. I keep finding new things. It turns out my multiline fields are working, but the single input ones do not. Very strange. Do you have single line inputs? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On November 26, 2019 5:26:05 PM Terry Judd via use-livecode wrote: > Not sure if it will help, but here's the code I use to create a multiline > text control (pControlName) on iOS that 'overlays' an existing LC field (pObj) > > # create a native multiline text control > put the rect of pObj into tRect > # shrink the rect by 1 pixel all around to reveal the object's border > add 1 to item 1 of tRect > add 1 to item 2 of tRect > add -1 to item 3 of tRect > add -1 to item 4 of tRect > mobileControlCreate "multiline", pControlName > mobileControlSet pControlName, "rect", tRect > mobileControlSet pControlName, "opaque", true > mobileControlSet pControlName, "visible", true > mobileControlSet pControlName, "contentType", "plain" > mobileControlSet pControlName, "fontSize", "18" > mobileControlSet pControlName, "textAlign", "left" > mobileControlSet pControlName, "returnKeyType", "default" > mobileControlSet pControlName, "autoCorrectionType", "default" > mobileControlSet pControlName, "autoCapitalizationType", "sentences" > mobileControlSet pControlName, "keyboardStyle", "default" > > You use 'editable' and 'enabled' as parameters for mobileControlSet but I > don't use either of those. I use 'opaque' but you don't because you are > after a transparent effect - I wonder whether 'opaque' can be used in > conjunction with 'alpha' though? > > Terry... > > > ?On 27/11/19, 6:46 am, "use-livecode on behalf of J. Landman Gay via > use-livecode" use-livecode@lists.runrev.com> wrote: > >I have reduced the problem to iOS input fields. Some testing shows that: > >* The native fields exist >* Their rect is correct >* If I script their text data, it is there and can be retrieved > >But they are inactive, can't be tapped, don't show any text even if its >entry is scripted, can't be typed into, can't be focused. They act like >they are invisible. > >Here is what I do to create them. This is a generic handler that creates >all input fields throughout the app, and it works fine on Android. >Usually I call it like this: createInputFld "email". The other params >are used only occasionally. > >command createInputFld pName,pReturnKey,pMultiline -- native single-line >input > -- pName = any valid fld identifier (long name, ID, etc) > -- pReturnKey = return key type, usually "search" > -- pMultiline = boolean, whether to create a multi-line input > put (the rect of control pName) into tRect > subtract 10 from item 2 of tRect -- adjust for mobile > add 10 to item 4 of tRect -- may not need for iOS > if pMultiLine = true then > mobileControlCreate "multiline", pName > else > mobileControlCreate "input", pName > end if > mobileControlSet pName, "rect", tRect > mobileControlSet pName, "autoCapitalizationType", "none" > mobileControlSet pName, "autoCorrectionType", "no" > mobileControlSet pName, "enabled", true > mobileControlSet pName, "editable", true -- multiline only (?) > mobileControlSet pName, "alpha", 0 -- transparent > mobileControlSet pName, "textalign", the effective textalign of >control pName > mobileControlSet pName, "textColor", the effective textcolor of >control pName > if pReturnKey <> "" then mobileControlSet pName, "returnKeyType", >pReturnKey -- usually "search" > mobileControlSet pName, "visible", true
Re: iOS simulator not responding
Thanks Terry. I keep finding new things. It turns out my multiline fields are working, but the single input ones do not. Very strange. Do you have single line inputs? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On November 26, 2019 5:26:05 PM Terry Judd via use-livecode wrote: Not sure if it will help, but here's the code I use to create a multiline text control (pControlName) on iOS that 'overlays' an existing LC field (pObj) # create a native multiline text control put the rect of pObj into tRect # shrink the rect by 1 pixel all around to reveal the object's border add 1 to item 1 of tRect add 1 to item 2 of tRect add -1 to item 3 of tRect add -1 to item 4 of tRect mobileControlCreate "multiline", pControlName mobileControlSet pControlName, "rect", tRect mobileControlSet pControlName, "opaque", true mobileControlSet pControlName, "visible", true mobileControlSet pControlName, "contentType", "plain" mobileControlSet pControlName, "fontSize", "18" mobileControlSet pControlName, "textAlign", "left" mobileControlSet pControlName, "returnKeyType", "default" mobileControlSet pControlName, "autoCorrectionType", "default" mobileControlSet pControlName, "autoCapitalizationType", "sentences" mobileControlSet pControlName, "keyboardStyle", "default" You use 'editable' and 'enabled' as parameters for mobileControlSet but I don't use either of those. I use 'opaque' but you don't because you are after a transparent effect - I wonder whether 'opaque' can be used in conjunction with 'alpha' though? Terry... ?On 27/11/19, 6:46 am, "use-livecode on behalf of J. Landman Gay via use-livecode" use-livecode@lists.runrev.com> wrote: I have reduced the problem to iOS input fields. Some testing shows that: * The native fields exist * Their rect is correct * If I script their text data, it is there and can be retrieved But they are inactive, can't be tapped, don't show any text even if its entry is scripted, can't be typed into, can't be focused. They act like they are invisible. Here is what I do to create them. This is a generic handler that creates all input fields throughout the app, and it works fine on Android. Usually I call it like this: createInputFld "email". The other params are used only occasionally. command createInputFld pName,pReturnKey,pMultiline -- native single-line input -- pName = any valid fld identifier (long name, ID, etc) -- pReturnKey = return key type, usually "search" -- pMultiline = boolean, whether to create a multi-line input put (the rect of control pName) into tRect subtract 10 from item 2 of tRect -- adjust for mobile add 10 to item 4 of tRect -- may not need for iOS if pMultiLine = true then mobileControlCreate "multiline", pName else mobileControlCreate "input", pName end if mobileControlSet pName, "rect", tRect mobileControlSet pName, "autoCapitalizationType", "none" mobileControlSet pName, "autoCorrectionType", "no" mobileControlSet pName, "enabled", true mobileControlSet pName, "editable", true -- multiline only (?) mobileControlSet pName, "alpha", 0 -- transparent mobileControlSet pName, "textalign", the effective textalign of control pName mobileControlSet pName, "textColor", the effective textcolor of control pName if pReturnKey <> "" then mobileControlSet pName, "returnKeyType", pReturnKey -- usually "search" mobileControlSet pName, "visible", true if the platform contains "iPhone" then mobileControlSet pName, "borderStyle", "none" mobileControlSet pName, "clearButtonMode", "always" end if end createInputFld The fields on the first card are plain input fields, but I have a question about multiline fields. The docs are a bit confusing. I pass the parameter to Android and it does what I want. But I'm not clear whether that works on iOS. The docs say that multiline fields are applicable to both platforms, but mobileControlCreate info says it is Android only. There is also a separate iOS command to create a multiline field. How does all this work? Multiline isn't applicable to the immediate issue, where I can't get past the first two plain input fields. On 11/25/19 5:09 PM, J. Landman Gay via use-livecode wrote: > Thanks Panos. Resetting didn't work, so now I'm wondering if it is > something about my LC native fields. The first thing the user needs to > do is log in, and I can't test beyond that until I can enter > credentials. There are two native fields, both are transparent. Would > transparency in iOS matter? They work on Android. > > I forgot to mention that the only OS available in XCode 10.1 is iOS 12.1 > but I assume that's okay. > > On 11/25/19 4:11 PM, panagiotis merakos via use-livecode wrote: >> Hello Jacque, >> >> So
Re: [ANN] Release 9.6.0 DP-1
I suspect most people would prefer and be more satisfied with a situation where the things which were merged were of appropriate quality, traceable, documented, not break anything and were reasonably certain to not cause difficulties in the future. (The latter two criteria are hard to meet, but at least achieving the previous three helps mitigate that fact). As with most cases of quoting numbers without any due diligence, analysis or context (as is the case in the original post) - one would be wise to not infer anything from it as numbers quoted in such a fashion are essentially meaningless (42, anyone?). All of us try things, whether it be adding features, fixing bugs or just experiments in our code - the results of which never see the light of day. In my team’s case we have the tendency to push whatever we do publicly as a branch / PR as a matter of habit (although perhaps I should re-evaluate as to whether it is a good habit or not!) If we did not have that policy and instead we pushed nothing publicly until it was going to be merged (which does not appear to be an uncommon phenomenon looking askance at quite a few other large projects lurking out there); then you’d probably find the number of open PRs at any one time would probably be countable on your digits. Warmest Regards, Mark. Sent from my iPhone > On 26 Nov 2019, at 20:50, Richmond via use-livecode > wrote: > > I think I understand what "no longer relevant" means, > but "stale" is unclear to me; I've always thought of something > that has gone stale as something that someone > should have done something with earlier but somehow 'overlooked.' > > And, as to "not going to get merged," well, why isn't that feature going to > get > merged? I wonder how many people are going to feel completely satisfied by > either that classification or "stale" ? > >> On 26.11.19 22:44, hh via use-livecode wrote: >> @Mark Waddingham. >> Good to know you are still alive. >> >> LC version numbering has it's own logic, agreed -- as long as >> it's counting up. Integers are meek as a lamb, we have enough >> of them. >> >> Nevertheless Mark Wieder made a good point with looking at the >> pull requests. >> >> If I understand correctly then you both are right: >> At the very end it is the content that matters. >> >> Now we all look forward to know which pull requests are *NOT* >> "incomplete or WIP" and which are *NOT* "stale / no longer >> relevant / not going to get merged". >> >> >> ___ >> 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: html5-IDE v100_alpha
Wow. very impressive..may I ask the reason why you created this? Is it to have an easier time testing html 5 features?. is it to turn it into a product? On Tue, Nov 26, 2019 at 6:03 PM hh via use-livecode < use-livecode@lists.runrev.com> wrote: > A few more words in defense of the HTML5 standalone builder: > > Enjoy html5IDE v100_alpha. A LC-playground with 'integrated' > propertyInspector, dictionary, scriptEditor and tools. > > http://hyperhh.de/html5/html5IDE.html > > You can create objects, edit their properties and their script. > Moreover there is a Paint-section and a MessageBox. > > You can save and load scripts, but not (yet) the created card. > The dictionary is a html5 version of Bernd Niggemann's tinyDict. > The script editor is based on Codemirror (MIT-licensed). > > There is a compact help (btn "H" of the Tools). > > There is still a lot to do... > > This "IDE" is made out of 6 independent standalones (in frames) > that send messages to each other. Each of these standalones can > separately be reloaded. > > ** Please be patient ** > Loading the standalone needs here, using Safari and a 100 MBit > connection up to 20 seconds (first time only), so up to 2 minutes > with a 16 MBit connection. > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Office:226-706-9339 Mobile:226-706-9793 ___ 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: [ANN] Release 9.6.0 DP-1
I LOVE YOU!!! (erm... plutonically of course.) Bob S > On Nov 26, 2019, at 15:26 , Brian Milby via use-livecode > wrote: > > For the IDE I only have 1987 which had a conflict that I just resolved (allow > nesting of DG behaviors). > > Thanks, > Brian ___ 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: [ANN] Release 9.6.0 DP-1
Whatever the semantics of release numbers, what pull requests or issues remain. You did the right thing! MW: We felt it better to get dp-1 almost feature complete, addressing the critical issues holding up people's apps first before lumping a lot of fixes from all over the place. The latter always risks a greater increase in the possibility of regressions and thus potential for a largely unusable build. thank you to staying on the key priorities. Hopefully 9.6 will work on iPhone 8! Brahmanathaswami ___ 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: [ANN] Release 9.6.0 DP-1
I have a couple and at least one is directly targeted at mobile (7154). 6404 is Vulcan reviewed but not yet merged (and is the oldest one I have outstanding). Both are widget updates. For the IDE I only have 1987 which had a conflict that I just resolved (allow nesting of DG behaviors). Thanks, Brian On Nov 26, 2019, 3:45 PM -0500, hh via use-livecode , wrote: > @Mark Waddingham. > Good to know you are still alive. > > LC version numbering has it's own logic, agreed -- as long as > it's counting up. Integers are meek as a lamb, we have enough > of them. > > Nevertheless Mark Wieder made a good point with looking at the > pull requests. > > If I understand correctly then you both are right: > At the very end it is the content that matters. > > Now we all look forward to know which pull requests are *NOT* > "incomplete or WIP" and which are *NOT* "stale / no longer > relevant / not going to get merged". > > > ___ > 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: iOS simulator not responding
Not sure if it will help, but here's the code I use to create a multiline text control (pControlName) on iOS that 'overlays' an existing LC field (pObj) # create a native multiline text control put the rect of pObj into tRect # shrink the rect by 1 pixel all around to reveal the object's border add 1 to item 1 of tRect add 1 to item 2 of tRect add -1 to item 3 of tRect add -1 to item 4 of tRect mobileControlCreate "multiline", pControlName mobileControlSet pControlName, "rect", tRect mobileControlSet pControlName, "opaque", true mobileControlSet pControlName, "visible", true mobileControlSet pControlName, "contentType", "plain" mobileControlSet pControlName, "fontSize", "18" mobileControlSet pControlName, "textAlign", "left" mobileControlSet pControlName, "returnKeyType", "default" mobileControlSet pControlName, "autoCorrectionType", "default" mobileControlSet pControlName, "autoCapitalizationType", "sentences" mobileControlSet pControlName, "keyboardStyle", "default" You use 'editable' and 'enabled' as parameters for mobileControlSet but I don't use either of those. I use 'opaque' but you don't because you are after a transparent effect - I wonder whether 'opaque' can be used in conjunction with 'alpha' though? Terry... On 27/11/19, 6:46 am, "use-livecode on behalf of J. Landman Gay via use-livecode" wrote: I have reduced the problem to iOS input fields. Some testing shows that: * The native fields exist * Their rect is correct * If I script their text data, it is there and can be retrieved But they are inactive, can't be tapped, don't show any text even if its entry is scripted, can't be typed into, can't be focused. They act like they are invisible. Here is what I do to create them. This is a generic handler that creates all input fields throughout the app, and it works fine on Android. Usually I call it like this: createInputFld "email". The other params are used only occasionally. command createInputFld pName,pReturnKey,pMultiline -- native single-line input -- pName = any valid fld identifier (long name, ID, etc) -- pReturnKey = return key type, usually "search" -- pMultiline = boolean, whether to create a multi-line input put (the rect of control pName) into tRect subtract 10 from item 2 of tRect -- adjust for mobile add 10 to item 4 of tRect -- may not need for iOS if pMultiLine = true then mobileControlCreate "multiline", pName else mobileControlCreate "input", pName end if mobileControlSet pName, "rect", tRect mobileControlSet pName, "autoCapitalizationType", "none" mobileControlSet pName, "autoCorrectionType", "no" mobileControlSet pName, "enabled", true mobileControlSet pName, "editable", true -- multiline only (?) mobileControlSet pName, "alpha", 0 -- transparent mobileControlSet pName, "textalign", the effective textalign of control pName mobileControlSet pName, "textColor", the effective textcolor of control pName if pReturnKey <> "" then mobileControlSet pName, "returnKeyType", pReturnKey -- usually "search" mobileControlSet pName, "visible", true if the platform contains "iPhone" then mobileControlSet pName, "borderStyle", "none" mobileControlSet pName, "clearButtonMode", "always" end if end createInputFld The fields on the first card are plain input fields, but I have a question about multiline fields. The docs are a bit confusing. I pass the parameter to Android and it does what I want. But I'm not clear whether that works on iOS. The docs say that multiline fields are applicable to both platforms, but mobileControlCreate info says it is Android only. There is also a separate iOS command to create a multiline field. How does all this work? Multiline isn't applicable to the immediate issue, where I can't get past the first two plain input fields. On 11/25/19 5:09 PM, J. Landman Gay via use-livecode wrote: > Thanks Panos. Resetting didn't work, so now I'm wondering if it is > something about my LC native fields. The first thing the user needs to > do is log in, and I can't test beyond that until I can enter > credentials. There are two native fields, both are transparent. Would > transparency in iOS matter? They work on Android. > > I forgot to mention that the only OS available in XCode 10.1 is iOS 12.1 > but I assume that's okay. > > On 11/25/19 4:11 PM, panagiotis merakos via use-livecode wrote: >> Hello Jacque, >> >> So the iOS standalone is installed to the iOS simulator, but the >> simulator >> does not respond to clicks / keyboard entry? >> >> I am on Mojave as well, but have not seen that happening. >> >> Maybe it is worth resetting the simulator
html5-IDE v100_alpha
A few more words in defense of the HTML5 standalone builder: Enjoy html5IDE v100_alpha. A LC-playground with 'integrated' propertyInspector, dictionary, scriptEditor and tools. http://hyperhh.de/html5/html5IDE.html You can create objects, edit their properties and their script. Moreover there is a Paint-section and a MessageBox. You can save and load scripts, but not (yet) the created card. The dictionary is a html5 version of Bernd Niggemann's tinyDict. The script editor is based on Codemirror (MIT-licensed). There is a compact help (btn "H" of the Tools). There is still a lot to do... This "IDE" is made out of 6 independent standalones (in frames) that send messages to each other. Each of these standalones can separately be reloaded. ** Please be patient ** Loading the standalone needs here, using Safari and a 100 MBit connection up to 20 seconds (first time only), so up to 2 minutes with a 16 MBit connection. ___ 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: [ANN] Release 9.6.0 DP-1
Round these parts quite a few of us have our own logic, so I wouldn't get fussed about the numbering . . . I'm actually looking forward to fiddling around with the new release over the weekend, and building the new "PDF bits" into my Devawriter Pro: Thanks in advance! On 26.11.19 22:44, hh via use-livecode wrote: @Mark Waddingham. Good to know you are still alive. LC version numbering has it's own logic, agreed -- as long as it's counting up. Integers are meek as a lamb, we have enough of them. Nevertheless Mark Wieder made a good point with looking at the pull requests. If I understand correctly then you both are right: At the very end it is the content that matters. Now we all look forward to know which pull requests are *NOT* "incomplete or WIP" and which are *NOT* "stale / no longer relevant / not going to get merged". ___ 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: [ANN] Release 9.6.0 DP-1
I think I understand what "no longer relevant" means, but "stale" is unclear to me; I've always thought of something that has gone stale as something that someone should have done something with earlier but somehow 'overlooked.' And, as to "not going to get merged," well, why isn't that feature going to get merged? I wonder how many people are going to feel completely satisfied by either that classification or "stale" ? On 26.11.19 22:44, hh via use-livecode wrote: @Mark Waddingham. Good to know you are still alive. LC version numbering has it's own logic, agreed -- as long as it's counting up. Integers are meek as a lamb, we have enough of them. Nevertheless Mark Wieder made a good point with looking at the pull requests. If I understand correctly then you both are right: At the very end it is the content that matters. Now we all look forward to know which pull requests are *NOT* "incomplete or WIP" and which are *NOT* "stale / no longer relevant / not going to get merged". ___ 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: [ANN] Release 9.6.0 DP-1
@Mark Waddingham. Good to know you are still alive. LC version numbering has it's own logic, agreed -- as long as it's counting up. Integers are meek as a lamb, we have enough of them. Nevertheless Mark Wieder made a good point with looking at the pull requests. If I understand correctly then you both are right: At the very end it is the content that matters. Now we all look forward to know which pull requests are *NOT* "incomplete or WIP" and which are *NOT* "stale / no longer relevant / not going to get merged". ___ 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: [ANN] Release 9.6.0 DP-1
If I had written that there would be people queueing at the airport to come over to Bulgaria and surgically remove my, erm, "ears." Well done, Mr Wieder. On 26.11.19 19:51, Mark Wieder via use-livecode wrote: On 11/26/19 1:58 AM, panagiotis merakos via use-livecode wrote: Dear list members, We are pleased to announce the release of LiveCode 9.6.0 DP-1. Really? A major point release while still in the queue there are 186 pull requests for the engine (dating back to 2014) 42 pull requests for the IDE (dating back to 2016) ___ 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: [ANN] Release 9.6.0 DP-1
On 11/26/19 10:34 AM, Mark Waddingham via use-livecode wrote: Its not a major point release, its a minor point release a la semantic versioning (https://semver.org/) - major.minor.maintenance. OK. I don't want to get into arguing semantics. But there are now several active (?) streams. LC 8.2.0 is still at a DP2 build I take it that the 8.x series is a dead end? LC 9.0.x is at a stable 9.0.5 build. Is that the end of 9.0? LC 9.5.1 is at the RC1 stage, and has been for three weeks In LC history that's pretty long for an RC release to lay stagnant. Is there going to be a stable LC 9.5 release or is development now going towards 9.6? LC 9.6.0 is newly at DP1 And I take it that this is the wave of the future and why building from source announces itself as 9.6. It contains a number of changes which are definitely not suitable for a maintenance release (as they add or change functionality) but are critical to quite a number of people's apps (iOS player issues, in particular; but also some android issues too) [ otherwise they would have been in a 9.5.2! ] Yes, this feels subjectively to me like a 9.5.2 release. Again, I don't want to argue naming semantics, but the 9.0->9.5 jump was a major change, and this doesn't feel like that kind of leap to me. I'm glad the problems were fixed, I just expected more from the build level. (which is something for when I have a 'spare' afternoon). Heh. We felt it better to get dp-1 almost feature complete, addressing the critical issues holding up people's apps first before lumping a lot of fixes from all over the place. The latter always risks a greater increase in the possibility of regressions and thus potential for a largely unusable build. No argument there. OK - I'm not going to get anywhere by pushing this point further, so I'm gonna shut up and get back to working on things. -- 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: iOS simulator not responding
I have reduced the problem to iOS input fields. Some testing shows that: * The native fields exist * Their rect is correct * If I script their text data, it is there and can be retrieved But they are inactive, can't be tapped, don't show any text even if its entry is scripted, can't be typed into, can't be focused. They act like they are invisible. Here is what I do to create them. This is a generic handler that creates all input fields throughout the app, and it works fine on Android. Usually I call it like this: createInputFld "email". The other params are used only occasionally. command createInputFld pName,pReturnKey,pMultiline -- native single-line input -- pName = any valid fld identifier (long name, ID, etc) -- pReturnKey = return key type, usually "search" -- pMultiline = boolean, whether to create a multi-line input put (the rect of control pName) into tRect subtract 10 from item 2 of tRect -- adjust for mobile add 10 to item 4 of tRect -- may not need for iOS if pMultiLine = true then mobileControlCreate "multiline", pName else mobileControlCreate "input", pName end if mobileControlSet pName, "rect", tRect mobileControlSet pName, "autoCapitalizationType", "none" mobileControlSet pName, "autoCorrectionType", "no" mobileControlSet pName, "enabled", true mobileControlSet pName, "editable", true -- multiline only (?) mobileControlSet pName, "alpha", 0 -- transparent mobileControlSet pName, "textalign", the effective textalign of control pName mobileControlSet pName, "textColor", the effective textcolor of control pName if pReturnKey <> "" then mobileControlSet pName, "returnKeyType", pReturnKey -- usually "search" mobileControlSet pName, "visible", true if the platform contains "iPhone" then mobileControlSet pName, "borderStyle", "none" mobileControlSet pName, "clearButtonMode", "always" end if end createInputFld The fields on the first card are plain input fields, but I have a question about multiline fields. The docs are a bit confusing. I pass the parameter to Android and it does what I want. But I'm not clear whether that works on iOS. The docs say that multiline fields are applicable to both platforms, but mobileControlCreate info says it is Android only. There is also a separate iOS command to create a multiline field. How does all this work? Multiline isn't applicable to the immediate issue, where I can't get past the first two plain input fields. On 11/25/19 5:09 PM, J. Landman Gay via use-livecode wrote: Thanks Panos. Resetting didn't work, so now I'm wondering if it is something about my LC native fields. The first thing the user needs to do is log in, and I can't test beyond that until I can enter credentials. There are two native fields, both are transparent. Would transparency in iOS matter? They work on Android. I forgot to mention that the only OS available in XCode 10.1 is iOS 12.1 but I assume that's okay. On 11/25/19 4:11 PM, panagiotis merakos via use-livecode wrote: Hello Jacque, So the iOS standalone is installed to the iOS simulator, but the simulator does not respond to clicks / keyboard entry? I am on Mojave as well, but have not seen that happening. Maybe it is worth resetting the simulator state: Quit any instances of Xcode and iOS simulator, and execute this in the terminal: sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService Then: - Open the Simulator from Xcode (Launch Xcode 10.1, go to Xcode's menubar and choose Xcode -> Open Developer Tool -> Simulator) - Wait until the simulator fully loads, until it shows the device's Home screen If you change device by clicking on the Simulator's app menubar (Hardware -> Device -> iOS 12.1 -> ) - again, wait until the new simulator device fully loads, until it shows the device's Home screen - Now go back to LiveCode and test again Fingers crossed :) Panos -- On Mon, 25 Nov 2019 at 21:43, J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: When I run a test on the iOS simulator, it will not respond to either clicks/taps or keyboard entry. Basically, it's inert. I've tried several different hardware devices, all with the same results. A Google search seems to show that this is a bug in the simulator when running under Mojave, and works again if run in Catalina. I can't update to Catalina yet because several apps I rely on will not run there. I'm using LC 9.5.1 (rc1), XCode 10.1, on Mojave. Has anyone seen this, and if so, have a workaround? -- 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
Re: [ANN] Release 9.6.0 DP-1
Well i'm happy at least PDF printing is a step in the right direction. Via html and opening in a browser one could get to pdf / print on paper, so we can skip that. Hopefully printing on paper will be a next step on Android. Thanks a lot! Jerry Op 26-11-2019 om 19:34 schreef Mark Waddingham via use-livecode: On 2019-11-26 17:51, Mark Wieder via use-livecode wrote: On 11/26/19 1:58 AM, panagiotis merakos via use-livecode wrote: Dear list members, We are pleased to announce the release of LiveCode 9.6.0 DP-1. Really? A major point release while still in the queue there are 186 pull requests for the engine (dating back to 2014) 42 pull requests for the IDE (dating back to 2016) Its not a major point release, its a minor point release a la semantic versioning (https://semver.org/) - major.minor.maintenance. It contains a number of changes which are definitely not suitable for a maintenance release (as they add or change functionality) but are critical to quite a number of people's apps (iOS player issues, in particular; but also some android issues too) [ otherwise they would have been in a 9.5.2! ] [ Note: We do sometimes change functionality in a backwards incompatible fashion in minor point releases so we aren't strictly semver - but only if it is focused in specific areas - in this case, we had to remove some features from the mobile player control as we could not replicate them with the replacement OS APIs, and we had to tweak how you setup the camera control to stop iOS complaining about permissions. ] At least 100 of the engine pull requests are either incomplete (no release note yet, no issue filed yet, no docs updates yet etc.) or WIP so are not mergeable as they stand. Probably half of the remainder are probably stale/no longer relevant/not going to get merged - so they probably could do with a cull (which is something for when I have a 'spare' afternoon). The IDE PRs (after a very brief perusal) look like about half are not yet complete and a few are WIP so not too dissimilar % wise. We felt it better to get dp-1 almost feature complete, addressing the critical issues holding up people's apps first before lumping a lot of fixes from all over the place. The latter always risks a greater increase in the possibility of regressions and thus potential for a largely unusable build. We're planning to get at least 20 further bugfixes merged for dp-2, and how many more than that depends on how testing goes, regression reports go and how much time we have before christmas :) Warmest Regards, Mark. ___ 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: [ANN] Release 9.6.0 DP-1
On 2019-11-26 17:51, Mark Wieder via use-livecode wrote: On 11/26/19 1:58 AM, panagiotis merakos via use-livecode wrote: Dear list members, We are pleased to announce the release of LiveCode 9.6.0 DP-1. Really? A major point release while still in the queue there are 186 pull requests for the engine (dating back to 2014) 42 pull requests for the IDE (dating back to 2016) Its not a major point release, its a minor point release a la semantic versioning (https://semver.org/) - major.minor.maintenance. It contains a number of changes which are definitely not suitable for a maintenance release (as they add or change functionality) but are critical to quite a number of people's apps (iOS player issues, in particular; but also some android issues too) [ otherwise they would have been in a 9.5.2! ] [ Note: We do sometimes change functionality in a backwards incompatible fashion in minor point releases so we aren't strictly semver - but only if it is focused in specific areas - in this case, we had to remove some features from the mobile player control as we could not replicate them with the replacement OS APIs, and we had to tweak how you setup the camera control to stop iOS complaining about permissions. ] At least 100 of the engine pull requests are either incomplete (no release note yet, no issue filed yet, no docs updates yet etc.) or WIP so are not mergeable as they stand. Probably half of the remainder are probably stale/no longer relevant/not going to get merged - so they probably could do with a cull (which is something for when I have a 'spare' afternoon). The IDE PRs (after a very brief perusal) look like about half are not yet complete and a few are WIP so not too dissimilar % wise. We felt it better to get dp-1 almost feature complete, addressing the critical issues holding up people's apps first before lumping a lot of fixes from all over the place. The latter always risks a greater increase in the possibility of regressions and thus potential for a largely unusable build. We're planning to get at least 20 further bugfixes merged for dp-2, and how many more than that depends on how testing goes, regression reports go and how much time we have before christmas :) Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: [ANN] Release 9.6.0 DP-1
> We are pleased to announce the release of LiveCode 9.6.0 DP-1. > Mark Wieder wrote: > Really? > A major point release while still in the queue there are > > 186 pull requests for the engine (dating back to 2014) > 42 pull requests for the IDE (dating back to 2016) Good point, perhaps the major point principle has lost its meaning already with 9.5.0 (compared to 9.0.5)? ___ 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: [ANN] Release 9.6.0 DP-1
On 11/26/19 1:58 AM, panagiotis merakos via use-livecode wrote: Dear list members, We are pleased to announce the release of LiveCode 9.6.0 DP-1. Really? A major point release while still in the queue there are 186 pull requests for the engine (dating back to 2014) 42 pull requests for the IDE (dating back to 2016) -- 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: Adding `the caller` to LiveCode Script
I'd like to see the 'the caller' added as well. Mind you, I'd like to see a *lot* more of the player object bugs fixed and more of the LCS statements that are still not Unicode aware made Unicode aware first, but the "the caller" would probably 3rd on my list. Digging through the executionContexts is a pain even when possible and there are lots of places in my code where being able to fidn the caller would be helpful. On 11/26/2019 10:59 AM, Trevor DeVore via use-livecode wrote: About 15 years ago Dar Scott added a feature request to have a function that returns the long ID of the caller's caller's object: https://quality.livecode.com/show_bug.cgi?id=1954 Two years ago LiveCode Builder added `the caller` which does just that, but only in LCB. If anyone is looking for a contribution to make to the engine I am throwing this out there as something to consider: Add `the caller` to LCS. Why is this useful? When writing handlers that send callback messages it is sometimes desirable to send the message to the object that called the handler. For example, let's say I have a library that makes REST calls to a server API. This calls are asynchronous so a handler in the library will need to notify the caller that the request is finished. If a handler from the library was called from a card then I might want the callback to be sent to the card. If a handler was called from a group then I might want the callback to be sent to the group. The current solution is to pass the long id of the object you want the callback sent to as a parameter to the library handlers. For example: restAPIGetObjects tId, the long id of me # callback will sent to me If you aren't using password protected stacks then you can use `the executioncontexts` to get the information you need to determine the caller. But when a stack is password protected the necessary information isn't included in `the executioncontexts`. I have a recent real world example. I rewrote the REST API interface in an application I work on to use behaviors that I attach to cards in my UI stacks. The design allows me to segment REST calls made within a specific object (card or group) so that callbacks and cleanup are very simple to manage. The need to pass the long id of the caller as a parameter if I want the callback for a specific handler to be sent to a group on the card shouldn't be part of a handlers parameter list, however. ___ 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
Adding `the caller` to LiveCode Script
About 15 years ago Dar Scott added a feature request to have a function that returns the long ID of the caller's caller's object: https://quality.livecode.com/show_bug.cgi?id=1954 Two years ago LiveCode Builder added `the caller` which does just that, but only in LCB. If anyone is looking for a contribution to make to the engine I am throwing this out there as something to consider: Add `the caller` to LCS. Why is this useful? When writing handlers that send callback messages it is sometimes desirable to send the message to the object that called the handler. For example, let's say I have a library that makes REST calls to a server API. This calls are asynchronous so a handler in the library will need to notify the caller that the request is finished. If a handler from the library was called from a card then I might want the callback to be sent to the card. If a handler was called from a group then I might want the callback to be sent to the group. The current solution is to pass the long id of the object you want the callback sent to as a parameter to the library handlers. For example: restAPIGetObjects tId, the long id of me # callback will sent to me If you aren't using password protected stacks then you can use `the executioncontexts` to get the information you need to determine the caller. But when a stack is password protected the necessary information isn't included in `the executioncontexts`. I have a recent real world example. I rewrote the REST API interface in an application I work on to use behaviors that I attach to cards in my UI stacks. The design allows me to segment REST calls made within a specific object (card or group) so that callbacks and cleanup are very simple to manage. The need to pass the long id of the caller as a parameter if I want the callback for a specific handler to be sent to a group on the card shouldn't be part of a handlers parameter list, however. -- Trevor DeVore ScreenSteps www.screensteps.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
[ANN] Release 9.6.0 DP-1
Dear list members, We are pleased to announce the release of LiveCode 9.6.0 DP-1. Developer Preview Release = Warning: this is not a stable release. Please ensure that you back up your stacks before testing them. Getting the Release === You can get the release at https://downloads.livecode.com/livecode/ or via the automatic updater. Release Contents LiveCode 9.6.0 DP-1 comes with more than 20 bugfixes. In addition, LiveCode 9.6.0 DP-1 includes several amazing new features: - The mobile player control has been updated to use the AVKit framework on iOS. This fixes a lot of existing bugs, including some new issues on iOS 13+ devices. - The mobile browser control has been updated to use the WebKit framework on iOS. This provides better performance on iOS devices. - The "open printing to pdf ..." command can now be used to direct printing to a PDF output file on Android devices. - Support for building with Xcode 11.1 and the iOS 13.1 SDK has been added. - New tsNet build with support for iOS 13+ is included. - New CEF build is included, which addresses rendering issues with the browser widget in some 32bit Windows devices. Known issues - This build (for Mac) is not notarized yet, so if your Mac is running MacOS Catalina (10.15.x) you will get a warning dialog saying that the app cannot be opened. In this case, you have to whitelist LiveCode in the System Settings -> Security and Privacy, and then right-click on LiveCode and choose "Open" from the contextual menu. Just double-clicking to open it will not work. Note that you'll only need to do this once, the very first time you open LiveCode 9.6 DP-1. For more details and instructions see here: https://support.apple.com/en-gb/HT202491 - The Browser widget's native layer is not shown in some Linux distros with Cinnamon window manager. - The use of the Browser widget is not supported on Ubuntu 18.04 64 bit LTS yet. The full release notes are available from: http://downloads.livecode.com/livecode/9_6_0/LiveCodeNotes-9_6_0_dp_1.pdf Feedback Please report any bugs encountered on our BugZilla at http://quality.livecode.com/ We have a forum available for discussing LiveCode Builder at http://forums.livecode.com/viewforum.php?f=93 Have fun! The LiveCode Team ___ 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
