Re: html5Player
More amazing work from Hermann! As always with your contributions, I learn a lot. Thank you!! Roger ___ 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: html5Player
Great work, Hermann. Thanks for posting that. -- Richard Gaskin Fourth World Systems hh wrote: HTML5: html5Player (v102 as of Jan 30, 2020) This is a HTML5 standalone (webApp in the new LC wording). https://hyperhh.de/html5/html5Player.html This is a "standalone-Plus" that is, it is extended by several javascript extensions for features that are not (yet) implemented in LC-HTML5 or not possible with LC. It can do among other the following. * Load (ordinary) local LC stacks by click or drag and drop. The stacks will run if they would compile and run with the HTML5 standalone builder (but you don't have to compile). The stacks MUST have one of the file endings .rev, .livecode or .livecodescript. * Load and display local or remote images (drag and drop images or copy/paste image urls is supported). * Load and display local audio/video (for cross-browser support use mp3 and mp4 only). Drag and drop file icons is supported. * Open a webview for videos, pdfs, audio streams and html pages. In such a webview you can safely run also HTML5 standalones that don't work in the html5Player because you inject javascript handlers/objects to the loading page. As the main page loads as https you can use https-Addresses only in the webview (especially for audio/video-streams). * Open one or several webcam views (works in newer Chrome, Safari, Brave, not in Firefox). All views are displayed in panels that are draggable and resizable (incl. minimize and maximize). HTML5: html5IDE (Inspector+Dictionary+ScriptEditor+Tools) The above html5Player will complete my experimental html5IDE that is close to "ready"". I can also meanwhile save edited stacks. But I don't publish newer versions than https://hyperhh.de/html5/html5IDE.html until LC does more in that field than renaming it to "WebApps". ___ 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
html5Player
HTML5: html5Player (v102 as of Jan 30, 2020) This is a HTML5 standalone (webApp in the new LC wording). https://hyperhh.de/html5/html5Player.html This is a "standalone-Plus" that is, it is extended by several javascript extensions for features that are not (yet) implemented in LC-HTML5 or not possible with LC. It can do among other the following. * Load (ordinary) local LC stacks by click or drag and drop. The stacks will run if they would compile and run with the HTML5 standalone builder (but you don't have to compile). The stacks MUST have one of the file endings .rev, .livecode or .livecodescript. * Load and display local or remote images (drag and drop images or copy/paste image urls is supported). * Load and display local audio/video (for cross-browser support use mp3 and mp4 only). Drag and drop file icons is supported. * Open a webview for videos, pdfs, audio streams and html pages. In such a webview you can safely run also HTML5 standalones that don't work in the html5Player because you inject javascript handlers/objects to the loading page. As the main page loads as https you can use https-Addresses only in the webview (especially for audio/video-streams). * Open one or several webcam views (works in newer Chrome, Safari, Brave, not in Firefox). All views are displayed in panels that are draggable and resizable (incl. minimize and maximize). HTML5: html5IDE (Inspector+Dictionary+ScriptEditor+Tools) The above html5Player will complete my experimental html5IDE that is close to "ready"". I can also meanwhile save edited stacks. But I don't publish newer versions than https://hyperhh.de/html5/html5IDE.html until LC does more in that field than renaming it to "WebApps". ___ 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: Corrupted Stacks
I use Chronosync. You can schedule them or run them manually. One way or two way syncs. Control over things I never even knew existed. Lifetime license. Bob S > On Jan 29, 2020, at 15:26 , Matthias Rebbe via use-livecode > wrote: > > Which one are you using? > > - > Matthias Rebbe > Life Is Too Short For Boring Code > >> Am 29.01.2020 um 23:50 schrieb Bob Sneidar via use-livecode >> : >> >> I have a sync program sync my projects folder to my iCloud drive. >> >> Bob S ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Corrupted Stacks
Which one are you using? - Matthias Rebbe Life Is Too Short For Boring Code > Am 29.01.2020 um 23:50 schrieb Bob Sneidar via use-livecode > : > > I have a sync program sync my projects folder to my iCloud drive. > > Bob S > > >> On Jan 29, 2020, at 14:30 , Matthias Rebbe via use-livecode >> wrote: >> >> Matthias Rebbe >> Life Is Too Short For Boring Code >> >>> Am 29.01.2020 um 22:00 schrieb Marty Knapp via use-livecode >>> : >>> >>> That’s an interesting approach Matthias. Most of my customers save locally >>> to their Documents folder. It’s just a few people using filer servers or >>> Dropbox >> I´d never problems with Dropbox. I am saving all of my projects to my >> Dropbox account. I´ve never ran into any problem with saving the main stacks >> or any substacks. >> >> While you are mentioning iCloud. I´ve noticed that i have problems building >> and saving a standalone in the Desktop or Documents folder since i´ve setup >> iCloud drive to synchronize my Desktop and Documents folder. Sometimes it >> works and sometime the standalone is not creaed successfully. So maybe >> iCould Drive is working other than Dropbox. Since i save the standalones to >> a local volume i did not run into that problem anymore. >> >> >>> (iCloud, etc). I wonder, is there a reliable way to ascertain if the file >>> is on a server? > > ___ > 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: Corrupted Stacks
I have a sync program sync my projects folder to my iCloud drive. Bob S > On Jan 29, 2020, at 14:30 , Matthias Rebbe via use-livecode > wrote: > > Matthias Rebbe > Life Is Too Short For Boring Code > >> Am 29.01.2020 um 22:00 schrieb Marty Knapp via use-livecode >> : >> >> That’s an interesting approach Matthias. Most of my customers save locally >> to their Documents folder. It’s just a few people using filer servers or >> Dropbox > I´d never problems with Dropbox. I am saving all of my projects to my Dropbox > account. I´ve never ran into any problem with saving the main stacks or any > substacks. > > While you are mentioning iCloud. I´ve noticed that i have problems building > and saving a standalone in the Desktop or Documents folder since i´ve setup > iCloud drive to synchronize my Desktop and Documents folder. Sometimes it > works and sometime the standalone is not creaed successfully. So maybe iCould > Drive is working other than Dropbox. Since i save the standalones to a local > volume i did not run into that problem anymore. > > >> (iCloud, etc). I wonder, is there a reliable way to ascertain if the file is >> on a server? ___ 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: Corrupted Stacks
- Matthias Rebbe Life Is Too Short For Boring Code > Am 29.01.2020 um 22:00 schrieb Marty Knapp via use-livecode > : > > That’s an interesting approach Matthias. Most of my customers save locally to > their Documents folder. It’s just a few people using filer servers or Dropbox I´d never problems with Dropbox. I am saving all of my projects to my Dropbox account. I´ve never ran into any problem with saving the main stacks or any substacks. While you are mentioning iCloud. I´ve noticed that i have problems building and saving a standalone in the Desktop or Documents folder since i´ve setup iCloud drive to synchronize my Desktop and Documents folder. Sometimes it works and sometime the standalone is not creaed successfully. So maybe iCould Drive is working other than Dropbox. Since i save the standalones to a local volume i did not run into that problem anymore. > (iCloud, etc). I wonder, is there a reliable way to ascertain if the file is > on a server? To find out if a Windows drive is mapped to network share you could see here https://devblogs.microsoft.com/scripting/how-can-i-determine-which-drives-are-mapped-to-network-shares/ On Mac OS you could use mount in Terminal. This command without any parameter lists you all mounted drives. The following is the result of mount on my Mac mattes:~ matthias$ mount /dev/disk3s1 on / (apfs, local, journaled) devfs on /dev (devfs, local, nobrowse) /dev/disk3s4 on /private/var/vm (apfs, local, noexec, journaled, noatime, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) /dev/disk1s1 on /Volumes/CCC Backup iMac (hfs, local, nodev, nosuid, journaled, noowners) //matthias@192.169.9.100/Syn%206%20TB on /Volumes/Syn 6 TB (afpfs, nodev, nosuid, mounted by matthias) The network drive is the one with the 2 leading / Matthias > > Marty > >> On Jan 29, 2020, at 11:48 AM, Matthias Rebbe via use-livecode >> wrote: >> >> Hi, >> i´ve ran into a similar situation a few months ago. This is what i´ve done. >> >> I´ve saved the stack to the local temp folder and then used the revcopyfile >> command to copy it to the network drive. >> When opening the app and that stack i used revcopyfile to copy the stack >> from the network drive to the local temp folder and opened that copy of the >> stack. >> So always the stack in to the local temp folder is used, but a copy is made >> to the network drive everytime i save the stack. >> This takes some time, but it´s acceptable and it works pretty well. >> >> - >> Matthias Rebbe >> Life Is Too Short For Boring Code >> >>> Am 29.01.2020 um 19:08 schrieb Marty Knapp via use-livecode >>> : >>> >>> Thanks Richard. What would be considered a large file? In my case I would >>> guess the average file is around 1mb though in some cases it could be up to >>> 5mb. >>> >>> In some cases the user has been able to recover from the “~” file but not >>> always. But it’s disconcerting to them that they never know when it might >>> happen again. And it’s amazing how many people don’t have a backup plan in >>> place. >>> >>> Marty >>> On Jan 28, 2020, at 6:12 PM, Richard Gaskin via use-livecode wrote: Marty Knapp wrote: > I have an app in which users create documents (stacks) that auto-save > when they're closed. I have a a few customers who are getting > corrupted stacks every once in a while. At least in a couple of cases > they are saving to a network server or over an internet connection. ... > Does anyone have any input with my shutdown routine? Ways of making it > more robust? Save is save. One command triggers the engine's save routine. Hard to get leaner than that. As a general rule, I would not advise saving large live documents over a network, or to any folder managed by network sync (Dropbox, iCloud, Nextcloud, etc.). Tons of warnings from software vendors all over the web about things like that. Are the users able to recover from the "~" copy? -- Richard Gaskin Fourth World Systems > > > ___ > 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: Corrupted Stacks
Marty Knapp wrote: > Thanks Richard. What would be considered a large file? In my case I > would guess the average file is around 1mb though in some cases it > could be up to 5mb. Hard to say what these cloud sync services may find problematic. Most of issues I've read about are with paging formats like SQLite, e.g.: https://stackoverflow.com/questions/7003336/how-enable-icloud-support-for-sqlite Since LC writes in one clean step I'm surprised it would have an issue, but while looking into this recently I stumbled across a lot of people who are having issues with Excel files corrupting in sync services. IIRC Dropbox uses - or at least once used - WebDAV, and Nextcloud and others still do. This makes the sync issue more vexing because WebDAV does whole-file transfers, as opposed to patching. So unfortunately I have little I can confidently convey on this, beyond having seen a lot of vendors using SQLite and other paging formats recommend not working directly in synced folder. > I was just on the phone with a customer who is periodically (once > every 2-3 months) having this issue. He’s on a gigabit network and > a 1mb file took about 5 seconds to save before the document closed > and the tilde version of the file was deleted. That’s seems pretty > slow for that size of file. The time between the engine's deletion of the "~" file and it's *apparent* deletion in a file manager may be quite different, as many file managers don't immediately re-render file listings in the UI, deferring it until a few ms after idle (or in the case of Windows, I've seen GUI file listing updates take a few seconds). This time may also be affected by the polling rate of any cloud sync service used with the folder. -- 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: Corrupted Stacks
That’s an interesting approach Matthias. Most of my customers save locally to their Documents folder. It’s just a few people using filer servers or Dropbox (iCloud, etc). I wonder, is there a reliable way to ascertain if the file is on a server? Marty > On Jan 29, 2020, at 11:48 AM, Matthias Rebbe via use-livecode > wrote: > > Hi, > i´ve ran into a similar situation a few months ago. This is what i´ve done. > > I´ve saved the stack to the local temp folder and then used the revcopyfile > command to copy it to the network drive. > When opening the app and that stack i used revcopyfile to copy the stack from > the network drive to the local temp folder and opened that copy of the stack. > So always the stack in to the local temp folder is used, but a copy is made > to the network drive everytime i save the stack. > This takes some time, but it´s acceptable and it works pretty well. > > - > Matthias Rebbe > Life Is Too Short For Boring Code > >> Am 29.01.2020 um 19:08 schrieb Marty Knapp via use-livecode >> : >> >> Thanks Richard. What would be considered a large file? In my case I would >> guess the average file is around 1mb though in some cases it could be up to >> 5mb. >> >> In some cases the user has been able to recover from the “~” file but not >> always. But it’s disconcerting to them that they never know when it might >> happen again. And it’s amazing how many people don’t have a backup plan in >> place. >> >> Marty >> >>> On Jan 28, 2020, at 6:12 PM, Richard Gaskin via use-livecode >>> wrote: >>> >>> Marty Knapp wrote: >>> I have an app in which users create documents (stacks) that auto-save when they're closed. I have a a few customers who are getting corrupted stacks every once in a while. At least in a couple of cases they are saving to a network server or over an internet connection. >>> ... Does anyone have any input with my shutdown routine? Ways of making it more robust? >>> >>> Save is save. One command triggers the engine's save routine. Hard to get >>> leaner than that. >>> >>> As a general rule, I would not advise saving large live documents over a >>> network, or to any folder managed by network sync (Dropbox, iCloud, >>> Nextcloud, etc.). Tons of warnings from software vendors all over the web >>> about things like that. >>> >>> Are the users able to recover from the "~" copy? >>> >>> -- >>> Richard Gaskin >>> Fourth World Systems ___ 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: Corrupted Stacks
Thanks for your input Tom. If I'm not mistaken, isn't that what Dropbox does - saves to a local folder then makes a copy to the cloud? With Richard’s input that Dropbox and similar services are notorious for problems in this regard I can only surmise that it’s the trip over the internet that introduces the opportunity for corruption. But maybe I'm wrong on that. I was just on the phone with a customer who is periodically (once every 2-3 months) having this issue. He’s on a gigabit network and a 1mb file took about 5 seconds to save before the document closed and the tilde version of the file was deleted. That’s seems pretty slow for that size of file. Marty > On Jan 29, 2020, at 9:30 AM, Tom Glod via use-livecode > wrote: > > I would change your save routine to save locally first, then copy to > network location. That should prevent those kinds of issues. > > On Tue, Jan 28, 2020 at 9:14 PM Richard Gaskin via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> Marty Knapp wrote: >> >>> I have an app in which users create documents (stacks) that auto-save >>> when they're closed. I have a a few customers who are getting >>> corrupted stacks every once in a while. At least in a couple of cases >>> they are saving to a network server or over an internet connection. >> ... >>> Does anyone have any input with my shutdown routine? Ways of making it >>> more robust? >> >> Save is save. One command triggers the engine's save routine. Hard to >> get leaner than that. >> >> As a general rule, I would not advise saving large live documents over a >> network, or to any folder managed by network sync (Dropbox, iCloud, >> Nextcloud, etc.). Tons of warnings from software vendors all over the >> web about things like that. >> >> Are the users able to recover from the "~" copy? >> >> -- >> Richard Gaskin >> Fourth World Systems ___ 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: Corrupted Stacks
Hi, i´ve ran into a similar situation a few months ago. This is what i´ve done. I´ve saved the stack to the local temp folder and then used the revcopyfile command to copy it to the network drive. When opening the app and that stack i used revcopyfile to copy the stack from the network drive to the local temp folder and opened that copy of the stack. So always the stack in to the local temp folder is used, but a copy is made to the network drive everytime i save the stack. This takes some time, but it´s acceptable and it works pretty well. - Matthias Rebbe Life Is Too Short For Boring Code > Am 29.01.2020 um 19:08 schrieb Marty Knapp via use-livecode > : > > Thanks Richard. What would be considered a large file? In my case I would > guess the average file is around 1mb though in some cases it could be up to > 5mb. > > In some cases the user has been able to recover from the “~” file but not > always. But it’s disconcerting to them that they never know when it might > happen again. And it’s amazing how many people don’t have a backup plan in > place. > > Marty > >> On Jan 28, 2020, at 6:12 PM, Richard Gaskin via use-livecode >> wrote: >> >> Marty Knapp wrote: >> >>> I have an app in which users create documents (stacks) that auto-save >>> when they're closed. I have a a few customers who are getting >>> corrupted stacks every once in a while. At least in a couple of cases >>> they are saving to a network server or over an internet connection. >> ... >>> Does anyone have any input with my shutdown routine? Ways of making it >>> more robust? >> >> Save is save. One command triggers the engine's save routine. Hard to get >> leaner than that. >> >> As a general rule, I would not advise saving large live documents over a >> network, or to any folder managed by network sync (Dropbox, iCloud, >> Nextcloud, etc.). Tons of warnings from software vendors all over the web >> about things like that. >> >> Are the users able to recover from the "~" copy? >> >> -- >> Richard Gaskin >> Fourth World Systems >> > > ___ > 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: Corrupted Stacks
Thanks Richard. What would be considered a large file? In my case I would guess the average file is around 1mb though in some cases it could be up to 5mb. In some cases the user has been able to recover from the “~” file but not always. But it’s disconcerting to them that they never know when it might happen again. And it’s amazing how many people don’t have a backup plan in place. Marty > On Jan 28, 2020, at 6:12 PM, Richard Gaskin via use-livecode > wrote: > > Marty Knapp wrote: > > > I have an app in which users create documents (stacks) that auto-save > > when they're closed. I have a a few customers who are getting > > corrupted stacks every once in a while. At least in a couple of cases > > they are saving to a network server or over an internet connection. > ... > > Does anyone have any input with my shutdown routine? Ways of making it > > more robust? > > Save is save. One command triggers the engine's save routine. Hard to get > leaner than that. > > As a general rule, I would not advise saving large live documents over a > network, or to any folder managed by network sync (Dropbox, iCloud, > Nextcloud, etc.). Tons of warnings from software vendors all over the web > about things like that. > > Are the users able to recover from the "~" copy? > > -- > Richard Gaskin > Fourth World Systems > ___ 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: Corrupted Stacks
I would change your save routine to save locally first, then copy to network location. That should prevent those kinds of issues. On Tue, Jan 28, 2020 at 9:14 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Marty Knapp wrote: > > > I have an app in which users create documents (stacks) that auto-save > > when they're closed. I have a a few customers who are getting > > corrupted stacks every once in a while. At least in a couple of cases > > they are saving to a network server or over an internet connection. > ... > > Does anyone have any input with my shutdown routine? Ways of making it > > more robust? > > Save is save. One command triggers the engine's save routine. Hard to > get leaner than that. > > As a general rule, I would not advise saving large live documents over a > network, or to any folder managed by network sync (Dropbox, iCloud, > Nextcloud, etc.). Tons of warnings from software vendors all over the > web about things like that. > > Are the users able to recover from the "~" copy? > > -- > Richard Gaskin > Fourth World Systems > > > > ___ > 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) Mobile:647.562.9411 ___ 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
