Re: Maintenance forever?
Ugh. I feel your pain on the RAID failure. We had one fail on our primary ERP server about a month ago when a drive controller bit it. The corruption then propogated to the rest of the array. The machine first locked up then was unbootable. About five hours later the team gave up on the transaction log because it took a hit as well. The good news was it happened on a Friday, so even though the guys were working on it through Sunday, operations were only minimally affected by it. -- 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: Show Script in New Window
I only have one monitor and I don't see that. On 9/1/19 8:43 AM, Sannyasin Brahmanathaswami via use-livecode wrote: On Mac, 9.5 stable, Script Editor, clicking on a tab to "Move to New Window". Take that script and moves it out to full screen window, with no way to minimize or go "back" at which point one cannot interact with a) the stack b) another script Can anyone else confirm this behavior. ( have three monitors -- may be complicating the issue) BR -- 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: Launch vs Set in widget
This is long, so most of you will probably want to skip it. On 9/1/19 6:48 AM, Mark Waddingham via use-livecode wrote: Hmmm - you say 'on your Pixel' - have you observed the behavior on other devices, or indeed other Pixels? (It might be worth creating a Pixel emulator which will be in factory state and see if you get the same behavior). I'll try it on my ancient Samsung S5, but it may very well be my Pixel. It won't always load an entire file into the browser widget either, but different testers using a Pixel, Pixel 2 and a Moto G4 did fine. If it's just my phone that would be good. Wouldn't an emulator use the GPU on my Mac, where everything works fine in the IDE? The browser is loading all its HTML files from the Documents folder on the device if that matters, there are no internet URLs. The mobileCreate and browser widget use the same system classes so I'd be surprised if it made any difference switching - especially as the issue sounds like it is to do with navigating between pages in the widget which is the concern of the system webview class, rather than the engine. Thanks, that will save me rewriting the scripts to test it. One thing which might be instructive is to capture the logcat whilst you run your app and then cause it to become 'not responding' - such situations are usually accompanied by quite a lot of log lines, especially if some sort of internal exception is occurring. If I can, I'll try it. I have to look up my notes. I badly need to be able to respond to the backKey too, but apparently that's not possible. The widget eats it. As for acceleratedRendering, it's broken. I had to turn it off completely. Looking at the engine code if you are using the browser widget then you should be getting the 'backKey' message as normal - if you are using mobileCreate browser, then *that* would eat it. Do you have a mobileCreate "browser" instance lurking somewhere still by accident? I'm sure there is no other browser instance anywhere. The stack was created with the widget in place and I haven't put in any code yet for mobileCreate. My goal is to use the backKey only for stack navigation, while still allowing the user to navigate when clicking the links in the browser content. Actually, I wouldn't care if the backKey did traverse the history as long as the card gets the message when the history is exhausted. Links frequently need to load a new file from disk. Right now, clicking browser links works a few times, then the entire app freezes and the only recourse is to quit when the "not responding" message appears. [ I might have read the engine code wrong though... ] When you say 'acceleratedRendering' is broken, can you elaborate? FWIW, we've been using acceleratedRendering alongside browser widgets internally on Android extensively and haven't seen any issues... I was a bit vague. The acceleratedRendering issues occur throughout, and do not occur when acceleratedRendering is completely turned off. There is a mainstack with two substacks, one of which has the browser widget, but acceleratedRendering redraws are bad everywhere. Originally I set ACR in preOpenStack on the 3-card mainstack and in both substacks. It seems the browser widget doesn't need that, so I've removed ACR from that stack. The mainstack has a login card, a TOC (Table of Contents) card, and the main content card. All navigation uses visual effects to emulate swiping. FullscreenMode is "showAll". With ACR on in preOpenStack: 1. Going from login to TOC is fine. 2. Going from TOC to content is fine the first time. Going back to the TOC is okay, but returning to the content causes a kind of double display hiccup; you see the old content, then the new content, then the visual effect happens and the new content is there. I showed this to Ian at the conference and he said my script should work, but I haven't been able to create a test stack to report it since it requires the whole app world to function. 3. The user can change "cards" by swiping, the screen is locked, content updated from a script-local array, and unlocked with "visual effect in rect". Sometimes it works great. Other times there is random junk drawn (my testers see this, they described it as "diagonal lines.") On my Pixel, the entire card goes multicolor chaotic garbage. My testers said the "lines" only last a moment and then the actual content appears. On my Pixel, the card never does appear, the random garbage doesn't respond to taps, and I need to quit and restart the app. 4. Going from the browser stack back to the mainstack causes the browser widget to remain on screen, obscuring the destination card. I don't think it is really there, because tapping where a control should be would redraw the content and the phantom browser disappears. I tried hiding the widget before leaving its stack but it would not hide. To attempt to fix it: I removed ACR from the preOpenStack and put it into the
How to disable Navigation/BackNavigation in the browser widget
As this was several times a question in the forum and also in the use-list here a method that works in the browser widget (without redirecting) on all platforms that support the widget. Browser widget usage example #27: NoNavigation/NoBackNavigation http://forums.livecode.com/viewtopic.php?p=182828#p182828 You can choose to have • either no navigation at all or • no back navigation only from the current page by simply using check buttons. ___ 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: Hactoberfest is coming...
Here is your first request for: * Repos to add to the list of LC projects to be targeted for some effort. So far I've added the LC IDE and Levure * Issues and bug reports to be added to the list of things the community might be able to tackle and resolve quickly, everything from minor bugs or documentation issues all the way up to IDE mods. * Contributors who are interested in helping to maintain the 100% unofficial, unsanctioned livecode hacktoberfest project and maybe turn it into something better. Go to https://macmikey.github.io/lc-hacktoberfest/ Fork or clone the repo Have at it Commit and issue a pull request back. On Sat, Aug 31, 2019 at 5:47 PM Pi Digital via use-livecode < use-livecode@lists.runrev.com> wrote: > Good work, thanks Mikey. > > Sean Cole > Pi Digital Prod Ltd > > > On 31 Aug 2019, at 22:27, Mike Kerner via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > OK, Mikey's 100% unofficial livecode hacktoberfest idea exchange repo is > > now live. > > https://macmikey.github.io/lc-hacktoberfest/ > > > > > > > > On Fri, Aug 30, 2019 at 11:22 PM Brian Milby via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> Yes, very good idea. I got my first shirt last year. > >> > >> Thanks, > >> Brian > >> On Aug 30, 2019, 11:05 PM -0400, Mikey via use-livecode < > >> use-livecode@lists.runrev.com>, wrote: > >>> Hactoberfest is a month away. That's github's event that awards some > swag > >>> like tshirts and stickers in exchange for pull requests to open source > >>> repos. Last year to get your swag you had to submit 4 PR's. > >>> We've got a month, so maybe now would be a good time to develop a list > of > >>> LC repos that deserve our time, changes/additions/features we want to > >>> implement, and get a bunch of people into the swing of contributing to > >>> these LC projects. > >>> We also need to help the people who have never done this help > themselves. > >>> ___ > >>> 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 > >> > > > > > > -- > > 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 > ___ > 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 > -- 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: Globals in Modular Stack Framework
On 9/1/19 7:48 AM, Sannyasin Brahmanathaswami via use-livecode wrote: There are two ways to go with this: 1) keep adding "keys" to the BIG global sConfigA OR 2) we could keep the custom properties of Stack Engine (which is always open) Does anyone have experience and has come to "best practices" for this architecture? And why? One way I deal with this situation is with getter and setter functions: It's a step away from global variables and you have more control and flexibility. # in the main "engine" stack (move sConfigA here) local sConfigA function configArray pKey if pKey is empty then return sConfigA # return the whole array if needed else return sConfigA[pKey] # return just the requested value end if end configArray command setConfigTo pKey, pValue put pValue into sConfigA[pKey] end setConfigTo # in the "modular" stacks you can then setConfigTo tKey, tValue put configArray() into tRetrievalArray put configArray(tKey) into tValue -- 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
Globals in Modular Stack Framework
Given a modular stack framework for mobile, where 1) a "engine" stack to always open, but hidden on boot → call it "Stack Engine" 2) then you have multiple "modular" stacks -- call them views--which are opened and closed on "demand/navigation" → call them a. stack "story" b. stack "calendar" c. stack "book" etc. Now, we know that globals are inherently "evil," but I find myself resorting to a global called sConfigA # with a growing number of keys, # I know "s" is meant for local, it's a legacy thing Now we have performance issues where, for a given view stack-- which may be open or closed: a) we dig the a local data base for "stuff" like a set of quotes b) are a series of image paths The result of such a dbase/disk operations, is usually a "trivial" amount data... say a list of 50 images paths or 100 quotes amount to 20K. It is small matter for the RAM to keep these lists in memory and not have to go "searching" again, so you have performance gain when you come back to say -- Stack "story" There are two ways to go with this: 1) keep adding "keys" to the BIG global sConfigA OR 2) we could keep the custom properties of Stack Engine (which is always open) Does anyone have experience and has come to "best practices" for this architecture? And why? How does Levure handle this? 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
Show Script in New Window
On Mac, 9.5 stable, Script Editor, clicking on a tab to "Move to New Window". Take that script and moves it out to full screen window, with no way to minimize or go "back" at which point one cannot interact with a) the stack b) another script Can anyone else confirm this behavior. ( have three monitors -- may be complicating the issue) 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
Re: Checking the host OS
On OS X in the terminal you can type: sysctl hw.machine and it will display the machine architecture. I don’t use the shell commands much but it looks like you can get the info without compiling code by using the code below. on mouseUp put shell( "sysctl hw.machine" ) into pData put pData end mouseUp JB > On Aug 30, 2019, at 8:41 PM, Devin Asay via use-livecode > wrote: > > On Aug 30, 2019, at 9:10 PM, Mark Wieder via use-livecode > wrote: >> >>> On 8/30/19 12:22 PM, Devin Asay via use-livecode wrote: >>> >>> Now that we can build both 32 and 64 bit applications for Windows, it’s >>> important to be able to tell whether the host OS is 32 or 64 bit. >> >> Why? If the 64-bit application won't run on the 32-bit system you won't get >> as far as your scripted test. Am I missing something? > > No, I’m just toying with the idea of having a 32-bit launcher that would > examine the host OS, then launch the proper executable based on whether it is > 32 or 64 bit. Sort of like a poor man’s universal app like we used to create > for MacOS. It’s possible I’m use way overthinking this. > > -D > ___ > 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: Launch vs Set in widget
On 2019-09-01 01:16, J. Landman Gay via use-livecode wrote: Yes, I meant "launch url in widget" which says it opens a url in the widget, but that is what "set the URL of widget x" does too. I don't see any difference. As Sean said the difference is the widget, rather than anything else. The 'launch url in ' syntax calls an OnLaunchUrl handler in the widget - so the widget could be anything. Obviously for a browser widget launching a url is the same as going to that url - which means it is the same as set. It is plausible that you might have a widget some day which can 'launch a url' but wouldn't have a url property. I'm having a terrible time with both acceleratedRendering and the browser widget in LC 9.5. I can't fix acceleratedRendering but I think I'll try going back to the original mobileCreate method and see if that works better. On my Pixel the widget freezes and Android puts up its "not responding" error dialog after the user navigates around a few pages. It doesn't behave correctly when changing stacks and remains visible after the new stack opens, obscuring the card. It also freezes when the back history is exhausted. I was curious if setting the URL with its launch command would be different. Hmmm - you say 'on your Pixel' - have you observed the behavior on other devices, or indeed other Pixels? (It might be worth creating a Pixel emulator which will be in factory state and see if you get the same behavior). The mobileCreate and browser widget use the same system classes so I'd be surprised if it made any difference switching - especially as the issue sounds like it is to do with navigating between pages in the widget which is the concern of the system webview class, rather than the engine. One thing which might be instructive is to capture the logcat whilst you run your app and then cause it to become 'not responding' - such situations are usually accompanied by quite a lot of log lines, especially if some sort of internal exception is occurring. I badly need to be able to respond to the backKey too, but apparently that's not possible. The widget eats it. As for acceleratedRendering, it's broken. I had to turn it off completely. Looking at the engine code if you are using the browser widget then you should be getting the 'backKey' message as normal - if you are using mobileCreate browser, then *that* would eat it. Do you have a mobileCreate "browser" instance lurking somewhere still by accident? [ I might have read the engine code wrong though... ] When you say 'acceleratedRendering' is broken, can you elaborate? FWIW, we've been using acceleratedRendering alongside browser widgets internally on Android extensively and haven't seen any issues... 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
Save/Open stack to/from variable?
In a situation where you can't 'directly' access the filesystem in order to save or read a stack but can write any variable to a local file and read from any local file to a variable, the questions arise: • Can we save (the current state of) a stack to a variable in a format as the usual stackfile (may be base64 encoded)? • Can we open (and set the state of) a stack from a variable that is in usual stackfile format (may be base64 encoded)? The "read" question describes an extension of "go stack url" where the url is a variable in usual stackfile format. And yes: I don't mean script only stacks. For example in a HTML5 standalone we have such a situation. May be also in some mobile standalones(?). ___ 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: Is HTML5 really practical?
> Alex T. wrote: > Is there a way to force a reload of the bit you want (need) to reload, > without reloading the engine ? (Continuing my answer) For a reload from cache you can do "location.reload()" as "javascript" If you mean to load another standalone or reset the current standalone without reloading the engine: I now looked into emscripten's module API and can't see a way to replace only the module.livecodeStandalone which is the VFS containing the stack. But you can make a mainstack that is only the engine and main scripts and then • load all you need from substacks and write a reset handler to the mainstack. • use go stack url (urls use SOP) from that mainstack. • load script only stacks from a local filesystem Then the engine is loaded only once. See my HTML5 samples TestInStandalone (button insert local library) Read/Write Local File GoStackURL ___ 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: Is HTML5 really practical?
With WebAssembly (WASM) now shipping in most modern browsers there doesn't seem much point in continuing development on the current (somewhat broken) Enscripten driven approach to delivering lc on the web. Hopefully lc have already started looking into compiling to wasm https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/ On Fri, 30 Aug 2019, 21:43 William Prothero via use-livecode, < use-livecode@lists.runrev.com> wrote: > Folks: > I’m considering making a web site that will use livecode’s html5 engine. > Is this practical? > > What I want to create is a signup system for a kayaking club. Paddles are > scheduled for each week and members enter their names for various paddle > times. The member list would be in a database and there would also be a > membership page with entries for various aspects of their skill levels. > > HH’s demos see to show reasonable engine load times, but I’m wondering > whether it might be easier and better to just use the engine as a cgi and > do everything in css and html. > > Frankly, I haven’t seen any compelling use case for livecode's html5. Is > there one, at this time? > > Any thoughts? > > Best, > Bill > > William A. Prothero > http://earthlearningsolutions.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 > ___ 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: Launch vs Set in widget
Originally such things could be used to "redirect" urls.
But in the current browser widget this is not used and in fact there
is no difference between the two:
[ The LCB code is
public handler OnLaunchUrl(in pUrl as String)
setUrl(pUrl)
end handler ]
But I have meanwhile found a solution you could try. Works here on
desktop and mobile.
The script below disables going back in the browser and keeps the
history clean. It preserves the state of your stack, which is the
same as if you navigate back from another page.
Hopefully the backKey doesn't has its own history (couldn't test here).
=== DISABLE GOING BACK IN BROWSER ===
You have to do that each time you go to a new page.
• For example I use it as follows in a browser widget.
on browserNavigateComplete uri
do "history.pushState(null, document.title, location.href);" & \
"window.addEventListener('popstate', function (event){" & \
"history.pushState(null, document.title, location.href); });" \
in widget "browser"
end browserNavigateComplete
• In a HTML5 standalone you can write
do "history.pushState(null, document.title, location.href);" & \
"window.addEventListener('popstate', function (event){" & \
"history.pushState(null, document.title, location.href); });" \
as "javascript"
> JLG wrote:
> Yes, I meant "launch url in widget" which says it opens a url in the
> widget, but that is what "set the URL of widget x" does too. I don't see
> any difference.
>
> I'm having a terrible time with both acceleratedRendering and the browser
> widget in LC 9.5. I can't fix acceleratedRendering but I think I'll try
> going back to the original mobileCreate method and see if that works
> better. On my Pixel the widget freezes and Android puts up its "not
> responding" error dialog after the user navigates around a few pages. It
> doesn't behave correctly when changing stacks and remains visible after the
> new stack opens, obscuring the card. It also freezes when the back history
> is exhausted. I was curious if setting the URL with its launch command
> would be different.
>
> I badly need to be able to respond to the backKey too, but apparently
> that's not possible. The widget eats it. As for acceleratedRendering, it's
> broken. I had to turn it off completely.
>
> I'm stuck with 9.5 because I have to build for 64-bit.
___
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
