Hi folks, Thanks to everyone who responded to my question. Where else would you get such support? And in particular, with what other development system would you get one of the actual architects of the system, responding to your question? LIveCode is something else.
OK, I have updated my screenshot code. I’m still getting a javascript exception, but it looks like it’s now caused by something else that web doesn’t like. Something that works ok on iPad. More investigation is required... On 8 Aug 2024, at 13:39, Mark Waddingham via use-livecode <use-livecode@lists.runrev.com> wrote: Caution: This email originated from outside of the University. Do not click links or open attachments unless you recognise the source of this email and know the content is safe. Check sender address, hover over URLs and don't open suspicious email attachments. On 2024-08-08 10:22, Jimmieson, Phil via use-livecode wrote: Hi folks, I’m experimenting with converting one of my LiveCode iPad Apps into a web version, to see how well it works, but there’s an issue that seems to be a deal-breaker. My iPad app takes a screenshot of the LiveCode stack when the user navigates away from the main card, so that the image can be used elsewhere in the app. This works fine on iPad, but I noticed that the web version of the app generates a javascript exception when I try to leave the main card. On checking the dictionary, I noticed that the export snapshot command is not listed as being supported on web. Is this correct? If so, is there an alternative that will work for web? So 'export snapshot from screen' is not supported - this is the form which takes the pixel data from the actual (composited) screen buffer. However, there is an alternate form which is entirely internal to the engine: export snapshot from [ rect <rect> of ] <object> To use the internal form for a card you can do: export snapshot from this card Or if you want a portion of the card: export snapshot from rect 0,0,100,100 of this card Further there is an `at size <width>,<height>` clause which allows you to specify the size you want the resulting image. The difference here is that the internal form replicates the same process that the engine uses to render objects to a window - it renders the given rectangle of the object into a rect of the specified size (or the size of the rect/object if 'at size' is not specified). In contrast, the 'external' form has to ask the OS for the given rectangle of the actual screen's framebuffer. Hope this helps, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Build Amazing Things _______________________________________________ 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 -- Phil Jimmieson (He/Him) University of Liverpool, Computer Science Department Ashton Bldg, Ashton Street, Liverpool. L69 3BX 0151 795 4236 _______________________________________________ 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
