Re: Still problems with creating the neccessary file for keystore reset (Lengthy mail)
On 2024-08-27 13:06, Klaus major-k via use-livecode wrote: java -jar pepk.jar --keystore=android_upload.keystore --alias=sehenkey --output=output.zip signing-keystore=android_upload.keystore --signing-key-alias=upload-key-alias --rsa-aes -encryption --encryption-key-path=upload_certificate.pem There's a missing `--` in front of `signing-keystore` - that's causing the args error: Error: Unable to parse the input: [--keystore=android_upload.keystore, --alias=sehenkey, --output=output.zip, signing-keystore=android_upload.keystore, --signing-key-alias=upload-key-alias, --rsa-aes, -encryption, --encryption-key-path=upload_certificate.pem] java.lang.IllegalArgumentException: Invalid argument: signing-keystore=android_upload.keystore Warmest Regards, 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
Re: Issues with (64bit?) Windows MySQL driver
On 2024-08-16 08:32, Ben Rubinstein via use-livecode wrote: I have a tool (a LiveCode standalone) running on Windows, which every night drops and recreates a database on a remote MySQL server, (about 350MB, 50 tables). Running for many years. About a year ago, we started to see a problem where sometimes the nightly build would fail, part-way through the process. The routine involves creating and populating tables, then creating indexes. Depending when the problem hits, the initial error is either Connection was killed or Lost connection to MySQL server during query All subsequent calls to revdb_execute get the error MySQL server has gone away I tried splitting the build into sections, so that the code opens the connection to a database builds some of the tables, then closes the connection, and opens a new connection to add more tables. There was no evidence that this made the issue occur less frequently; and once it hit, subsequent attempts to open a connection would get the error Can't connect to MySQL server on '' (0) When this was happening maybe a couple of times per month (on average) it didn't matter too much (the system is designed to be resilient, if the data wasn't refreshed one day, it would be the next). I thought it might be network glitches. Recently IT tightened security on the machine where the tool runs; and since then we get this problem nine times of out ten. They say the only change made was to remove the admin privileges of the user account, and have now reversed that change; however, this problem has remained since. Another problem that arrived at the same time, reported here as "a windows weirdness", seems (per Paul Dupuis and Mark Waddingham) to be related to UNC paths, and possibly to security policies. Does anyone have a suggestion for how conditions could affect this? Is there any way to get more detailed information out of the rev database driver about what's happening? The dbmysql is just a thin wrapper around the mysqlclient library which is basically just implementing a protocol over a socket. The fact that you get 'Can't connect to MySQL on ''' after it happens sounds very much like there's some sort of blocking going on at the system level. (A bit like most servers have 'portsentry' or similar on it which blocks requests which look dodgy) - given the 'tigtening of security' this is quite possible... I think there are some low-level network tools on windows you could use to look at what's happening with sockets/ports (e.g. https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview). I was going to suggest tweaking the timeouts/auto-reconnect parameters on your revOpenDatabase call - but I'm not sure its a timeout due to the 'Can't connect' error happening subsequently. Warmest Regards 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
Re: Problems with revSetSpeechVoice
On 2024-08-15 14:36, Klaus major-k via use-livecode wrote: Hi all, I am currently working with the revSpeak library (needs to be crossplatform Mac and Win) and facing serious problems. I have a field with all available voices, that I fill with: --- on mouseUp put revSpeechVoices() into tVoices sort tVoices put textdecode(tVoices,"utf8") into fld "fi_voices" end mouseUp --- textdecode is neccessary to preserve UMLAUTS like in: Sandy (Französisch (Kanada)) ## Sandy (French, Canada)) Now all the french voices do NOT work! I tried: -- revSetSpeechVoice tVoice ## Where tVoice of course contains the above mentioned voice -- I even tried: -- put textencode(tVoice,"native") into tVoice2 revSetSpeechVoice tVoice2 -- No dice, always reverts back to the "default" voice on my Mac. Did you try: -- put textencode(tVoice,"utf8") into tVoice2 revSetSpeechVoice tVoice2 ------ Warmest Regards, 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
Re: A Windows weirdness
On 2024-08-13 21:24, Ben Rubinstein via use-livecode wrote: It turned out that the issue was that I was reading the data as put URL format("binfile://%s", tPath) into tData this was working, but now returned "can't open file". Changing the statement to put URL format("binfile:%s", tPath) into tData Can you give some examples of what tPath is in these circumstances? Just to see what sort of paths the engine would have actually have been passing to Windows. fixed the issue, so it's fine. But my question would be does anyone know what would have changed on the system to make this statement, that used to work, do so no longer? I suspect Paul is right that this is UNC related - there have been some security options added related to UNC paths to windows (buried somewhere in the registry) so it could be that but I'm not 100% sure (I'll do some experimentation later on). What version of Windows does the afflicted machine have? Warmest Regards, 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
Re: Export snapshot - is it usable on LiveCode web apps?
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 of ] 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 ,` 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
Re: crop image
On 2024-07-23 14:23, jbv via use-livecode wrote: Hi list, I have the following script : create image put number of imgs into ni put id of img ni into tid set filename of img id tid to myFile put imageData of img id tid into pimage -- many lines for imagedata analysis crop image id tid to rect trect I get this error : crop: object is not an image That is a slightly misleading error... 'crop' does not operate on images which are referenced - i.e. use a filename To crop such an image, load the data into the image: set the text of img id tid to url ("binfile:" & myFile) Hope this helps. Warmest Regards, 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
Re: Slow stack problem
On 2024-06-29 08:53, Neville Smythe via use-livecode wrote: Is it not the case that the processing time for looping over the number of lines and getting the k-th line in each iteration, for some arbitrary k, going to be Order(N^2) * C * T where N = the number of lines in the text C = the number of codepoints in each line T = the (average) time for processing each codepoint to check for a return character Now N and C are the same whether the text is ascii or unicode Largely - yes - although for stuff like this you need to think in terms of bytes not codepoints (as memory throughput becomes 'a thing' when the strings are anything longer than a few characters) - so unicode is 2*ascii in this regard [ Its actually more than 2x for longer strings but how much more depends on CPU/memory architecture - CPUs can only read from their level 1 cache, and there's a cost to a cache miss, and you get 2x as many cache misses with unicode data as native data, assuming the data is larger than a single level 1 cache line. ] Test 1 If I get rid of the red herring by replacing the matchChunk call with a simple ... Which would appear to mean that processing unicode codepoints for the apparently simple task of checking for return takes 100 times as much time as processing ascii. That seems excessive, to put it mildly! Its a lot slower certainly, but then searching unicode text for a string is (in the general case) a lot more complex than searching native/ascii text for a string. Test 2 With the original code using matchChunk, which of course is going to have its own internal loop on code points so multiply by another 8 (it only searches the first few characters) and will not always return true so more lines must be processed — but again these are same multipliers whether ascii or unicode ... Plain ascii takes 0.07 seconds Unicode takes19.9 seconds, a multiplier of nearly 300. — I can easily believe matchChunk takes 3 times as long to process unicode as ascii, this is the sort of factor I would have expected in Test 1. So 'Test 2' is slightly misleading - as it still suggests matchChunk is causing a slowdown - which it isn't. The difference here is Test 2 is doing more work as it isn't always exiting. If you test: get line k of fff put true into tFound I suspect you'll find the time to process your data if it contains unicode is pretty similar to that when matchChunk is also called. In my quick test (which is 32 index lines, 200 fff lines) I get about 10ms (no unicode) vs 1400ms (unicode) OK Mark, hit me again, I am a glutton for punishment, what is wrong with this analysis? Nothing in particular - apart from thinking that matchChunk is actually a relevant factor here ;) The reasons this delimiter search operation on unicode strings is so much slower than native is for two reasons: 1) We (well, I) heavily optimized the core native/ascii string operations in 2015 to make sure there were as fast as possible 2) Searching a unicode string for another string (which is what is going on here) is much more complex than doing the same for native/ascii Native/ascii strings have some very pleasant properties: - one byte (codeunit) is one character - always. - each character has only one representation - its byte value - casing is a simple mapping between lower and upper case characters - and only about 25% of characters are affected Unicode has none of these properties - a unicode character (grapheme) can be arbitrarily many codeunits (2 byte quantities) long - characters can have multiple representations - e.g. e-acute vs e,combining-acute - casing is not (in general) a simple mapping of one codeunit to another Currently the unicode operations in the engine are largely unoptimized - they assume the general case in all things so even searching a string for LF (which is the case here) is still done under the assumption that it might need that (very hefty) extra processing. Of course it would be nice to have highly optimized low-level unicode string optimizations but you have to pick your battles (particular when the battles are incredibly technical ones!) but the reality is that this (admittedly large!) speed difference is only really noticeable 'at scale' and when scale is involved, there's pretty much always an algorithmic change which can make those 'low-level' performance differences irrelevant. The case here is a really good example. The line X based code gives (no matchChunk / with matchChunk): ASCII 300 lines 13ms / 22ms ASCII 3000 lines - 986ms / 1104ms ASCII 1 lines - 10804ms / 11213ms The array based code gives (no matchChunk / with matchChunk): ASCII 300 lines - 2ms / 11ms ASCII 3000 lines - 19ms / 101ms ASCII 1 lines - 69ms / 336ms UNICODE 300 lines - 7ms / 12ms UNICODE 3000 lines - 52ms / 108ms UNICODE 1 lines
Re: Slow stack problem
On 2024-06-28 11:15, Neville Smythe via use-livecode wrote: In my last epistle I mentioned the repeat loop had only 32 iterations. Much more relevant of course is the inner loop on the number of lines of the data variable fff. In this case fff had 1760 lines. So the total possible number of iterations was around 3 to 5, getting up there but still well within LC capability. I tried operating the loop on just the first 100 lines of fff. The repeats took 0.006 seconds (impressive). Then just the first 300 lines. Timing was 0.016 seconds, approximately linear increase as expected Are you sure a linear increase is expected? Then the first 500 lines. Timing is now 6.43 seconds. Something very odd there, that’s beyond exponential increase. And on the last 500 lines, timing was 0.135 seconds (Aha !!!) I take it you tested this by doing the loop where fff was just line 1 to 300, then just line 1 to 500 and then just -500 to -1? My guess here is that the first 300 lines do not have a unicode character, there is somewhere in the next 200, and there are none in the last 500. This would seem to point to matchChunk having indigestion over something in the middle of the text data. The data is 98% plain ascii, but quite likely it has a few Unicode characters: I have taken a whole lot of time to convert my legacy app to accept Asian and European Unicode personal names. All regex matches in LC are Unicode (under the hood) - so thinking this is regex related is a red-herring. Running a regex on Unicode text, is no different from on native text - its just its dealing with 16-bit units rather than 8-bit (regex is generally a linear operation - it takes time proportional, roughly to length of pattern * length of string - well, as long as you don't use any backtracking type features). The issue here is the assumption that your code is doing something linear... It *looks* linear because your code is only doing two nested repeat loops - so from the point of view of lines of script its iterating the central loop roughly 'the number of lines of indexList * the number of lines of fff' - however the engine is doing a lot more work. The central loop is doing (paraphrased); repeat with x = 1 to N get line x of jjj end repeat This means the engine is searching for a line delimiter not N times, but sum(1, ..., N) times (which is N*(N-1)/2 - i.e. N^2 roughly). Processing 300 lines will take the engine about 45000 steps, processing 500 lines will take the engine 125000 steps, processing 1760 lines will take the engine > 1,500,000. This means that a small change in how long it takes to search for a line delimiter (which is the fundamental operation here) makes a big difference to how long doing 1000's of them will take - and searching a string containing unicode is a fair bit slower than searching a string which contains only native characters. Fortunately there is an easy solution here - use an array so you get random access to the lines of fff: split fff by return repeat with i=2 to the number of lines of indexList put line (i+1) of indexList into which put "(^[0-9-]*\t" & which & ")" into regX put false into found repeat with k=lastFound+1 to the number of elements of fff put matchChunk(fff[k],regX,pos1,pos2) into found if found then exit repeat end repeat if found then put k into lastFound end if put lastFound into item i of mylineNumbers end repeat This should do exactly the same thing but SUBSTANTIALLY faster whether your fff variable contains native or unicode characters. Warmest Regards, 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
Re: Windows on ARM...
On 2024-04-09 20:03, Paul Dupuis via use-livecode wrote: Mothership people (or anyone in the community that may know this): Microsoft is expected to port and release Windows running on ARM chips (Surface laptops will use the Snapdragon X Elite processors from Qualcomm) this year. Announcement expected May 20, shipping - who knows when, but likely this year. This is to compete with Apple's M# chips. Will we have a dual build option in Livecode (or is one even needed)? And, for the BIG QUESTION, how long is it likely to be after Windows on ARM is released to the public before we see a LC version that supports it? I can't really say when we will add a native ARM64 build for Windows - it will depend largely on demand and need. That being said, we have recently updated how we build the windows engine to use the most recent version of Visual Studio (which has arm64 target compilers) so that is at least a step in the right direction. I know, this is probably way ahead of any practical answer, but I know we WILL have customers asking us if our app (built on LC9.6.11) will run on Windows on ARM on day one. Windows ARM has been available to everyone for a while - albeit not strictly a 'public' thing, virtualization tools like VMware on macOS will download and install the ARM version of windows automatically if you are running on an ARM mac. We have a couple of people internally who have ARM macs, and use VMware to run Windows in ARM and we haven't seen any problems. So I can echo what Mike said - especially since Microsoft added x86-64 support to their Intel emulation layer on Windows ARM (think Rosetta 2) about a year or so ago - both x86 and x86-64 versions of the LiveCode engine run seamlessly on it. Another thing to remember is that Microsoft are not forcing a processor transition unlike Apple have done twice now (in the last two decades) - I fully expect that Windows on ARM will support Intel executables indefinitely, just like x86-64 Windows continues to support x86 executables. Warmest Regards, 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
Re: disabled buttons still receive events, they just process them, later?
It’s because of the wait - ‘blocking’ waits (those which aren’t ‘with messages’) queue any (low level) events so they are handled at the next wait (in this case the global one the engine does implicitly when there are no handlers executing). Flushing events after the wait as Jacque suggests will ensure they aren’t there to handle. Warmest Regards. Mark. Sent from my iPhone > On 21 Feb 2024, at 21:59, Mike Kerner via use-livecode > wrote: > > i did. > i have both a button, and a power button. > script: > > *local* count > > *on* mouseUp > > *if* the disabled of me *then* *put* cr & "disabled" after msg > > *add* 1 to count > > *set* the enabled of me to false > > *put* count > > *wait* 2 second > > *set* the enabled of me to true > > *end* mouseUp > >> On Wed, Feb 21, 2024 at 4:47 PM Craig Newman via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >> Mike. >> >> In a new stack I placed a button with this: >> >> on mouseUp >> beep 2 >> end mouseUp >> >> If I click on the button I hear two clicks. I disabled the button and >> clicked on it. I enabled the button. No clicks. I did this all by hand. Did >> you? >> >> Craig >> >>> On Feb 21, 2024, at 4:07 PM, Mike Kerner via use-livecode < >> use-livecode@lists.runrev.com> wrote: >>> >>> alright, i'm a little surprised to notice this: >>> i have a button. i disabled the button. >>> then i clicked on the button >>> then i re-enabled the button >>> the click, from the period while the button was disabled, is received and >>> processed by the button. >>> that seems problematic, to me. how would one cause clicks to be >> discarded, >>> permanently? hide the button? overlay it with a transparent control that >>> will absorb and ignore the clicks? >>> >>> -- >>> 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 ___ 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: AW: Re: macOS window maximization weirdness
On 2024-02-10 21:16, Paul Dupuis via use-livecode wrote: My desktopChanged handler, at one point, executes either a: set the effective width of window tWindow to tMontiorWidth OR a set the effective height of window tWindow to tMonitorHeight Either of which sends a resizeStack message to the stack/window. However, when it is sent this 2nd time as a result of the window maximization (which does a successful resizeStack, then desktopChanged, which sets teh effecting width/height, that causes a resizeStack) the resizeStack parameters, pNewWidth and pNewHeight are EMPTY, so any placement of controls based on the parameters use empty, which gets treated as zero. As far as I can see, the engine only ever sends resizeStack with all parameters - so if your stack is getting a resizeStack with only two arguments - that's being sent from your code or a library you are using I think. The work-around is the do Example 2 for resizeStack, but I think is might be considered an ENGINE BUG that on macOS, not Windows, maximization sends a resizeStack and then a desktopChanged message. No monitor has been added or removed, nor has the resolution of any monitor been changed, therefore I don't think a desktopChanged message SHOULD be sent on macOS window maximization. I think this is a bug? Does anyone have a valid reason why macOS should receive a desktopChanged message on window maximization when Windows does not? So the engine hooks into the notification from the OS for a change in screen parameters... The engine then checks the new ones against the old and sends desktopChanged if there are any differences. In the case of maximization on macOS - using (what is now!) the fullscreen gadget on the titlebar of windows causes the OS furniture to ebb away - i.e. the *working* screenRect changes - and thus the engine sends the desktopChanged notification.* (You can test this by creating a stack and 'answer the screenRect & return & the working screenRect' - click before and after the fullscreen gadget on the title bar, and there will be a difference.) Warmest Regards, Mark. P.S. The message is also sent when the dock is adjusted in size too - so presumably you would see the same problem then (assuming your handling of the desktopChanged message is causing the errant resizeStack with only two arguments to be sent from script somehow). -- 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
Re: Which is faster...
very high number of iterations!) then fetch into a local variable before the loop and then use that value (the same, to be fair, is true of calling functions which return fixed values and accessing array elements - especially ones on paths longer than one). 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
Re: Property Inspector bug for keys with commas in the key name
Indeed you can indirect through a variable - but you can’t do, e.g: get the foo,bar,baz of me Which was my point :) Warmest Regards, Mark. P.S. Of course an obvious syntactic extension would be allowing quoting of the property keyword: the “foo,bar,baz” of me. Sent from my iPhone > On 5 Nov 2023, at 16:14, Curry Kenworthy via use-livecode > wrote: > > > Mark: > > > to access your custom properties with `the X of` syntax - > > it is *this* kind of access which is *not* possible > > if the custom property name is not an identifier > > Discussion is perception - Code is reality: > > put "I,love,commas*etc" into X > set the X of me to "Hi, Mark!" > answer the X of me > > https://quality.livecode.com/show_bug.cgi?id=23512 > > Best wishes, > > Curry Kenworthy > > Radically Innovative Christian LiveCode Development > "PASSION for Elegant, Efficient Code!" > http://livecodeconsulting.com/ > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Property Inspector bug for keys with commas in the key name
On 2023-11-03 20:21, Paul Dupuis via use-livecode wrote: You do make a good point about the documentation regarding custom properties. Assuming people read the documentation. At the same time, you used to be able to use commas in custom property names. As Curry noted, Livecode even used to use them in the standalone setting properties, so the mothership set a precedence. The user guide's comments are really good advice *if* you want to access your custom properties with `the X of` syntax - it is *this* kind of access which is *not* possible if the custom property name is not an identifier (i.e. something you can use as a variable or handler name). (Remember that you can set the 'current' custom property set of an object and use `the X of` syntax to access the keys of that too - and if you do that, then any non-identifier keys are similarly not accessible). So we haven't set a precedent by using commas in custom property names - its in a custom property set *and* they are never accessed via `the X of` syntax (only via `the SET[X] of` syntax) - and with such things (where you are using the custom property set as an array of data) I don't think the rule applies. It's not really a problem since I can do updates by script. It is more of just an annoyance. I agree its an annoyance - and is something which is resolvable (i.e. by adding a variant of the hilitedElement property of the treeview with one which returns a sequence rather than a string). Feel free to file a bug report about it and we'll put it on the list to look at. Warmest Regards, 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
Re: Crashing on M2 Mac
Dan, could you file a bug with the offending line of code which crashed ios17 with 9.6.10… Just so we can check it isn’t still there in 9.6.11 :) Thanks! Mark Sent from my iPhone > On 3 Nov 2023, at 16:48, Dan Friedman via use-livecode > wrote: > > To all, > > Oops! I am mistaken…. It wasn’t MacOS that had the issue, it was iOS 17 that > was problem. iOS app built with 9.6.10 running on iOS 17 crashes when the > convert command is called. I can (in my experience) absolutely confirm this. > Debugged it down to the single line of code. Rebuilt the app with 10.0.0 > (dp 6) and the issue was solved. > > Apologies for posting the wrong platform. > > -Dan > > > From: use-livecode on behalf of > panagiotis merakos via use-livecode > Date: Friday, November 3, 2023 at 9:23 AM > To: How to use LiveCode > Cc: panagiotis merakos > Subject: Re: Crashing on M2 Mac > Hello all, > > We are not aware of any bug in the "convert" command, and I think it is > highly unlikely such a bug to affect M2 machines but not M1 ones. > > We have a M2 machine running Sonoma which is used in the prerelease testing > so my feeling is that if there was such a bug, we would have caught it in > the prerelease testing of 9.6.11 rc1, which included a fix related to the > system date on Sonoma. Also, a related report we got about the convert > command - but turned out to be not a bug, is this one: > > https://quality.livecode.com/show_bug.cgi?id=24362 > > BTW, the crash report that is attached in the first post indicates that the > app was running under Rosetta (> Code Type:X86-64 (Translated)) > > @Peter > If you have a reproducible recipe please do file a bug report and include > your app or a sample stack - I can give it a try in my Sonoma M2 mac mini. > > Kind regards, > Panos > > >> On Fri, 3 Nov 2023 at 14:05, Paul Dupuis via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >> Also, have you (or could you) try LC 9.6.11rc-1 and see if that has a >> fix for the convert issue you found? >> >> We use convert a lot (currently under LC 9.6.10) and can't take out app >> to LC 10, so a 9.6.11 that addresses this convert bug is needed. >> >>> On 11/2/2023 6:33 PM, Dan Friedman via use-livecode wrote: >>> Peter, >>> >>> I recently discovered (from one of my own apps) that a Mac app built >> with 9.6.10 running on Sonoma crashes when the convert command is called. >> I rebuilt the app in 10.0.0 (dp 6) and the app no longer crashes. Hope >> that helps! >>> >>> - Dan >>> >>> >>> From: use-livecode on behalf of >> Peter Bogdanoff via use-livecode >>> Date: Thursday, November 2, 2023 at 3:23 PM >>> To: Paul Dupuis via use-livecode >>> Cc: Peter Bogdanoff >>> Subject: Crashing on M2 Mac >>> A user is reporting crashing on his M2 Sonoma Mac. >>> >>> This was a build of LC 9.6.10, with both Intel and Apple chosen in the >> Standalone settings. >>> >>> It did not crash with only Apple chosen, though there were script errors >> that did not happen with non-M2 users (M1 is OK). I haven’t been able to >> debug that since I don’t have an M2 Mac. >>> >>> Has anyone used LC with M2? >>> >>> Peter Bogdanoff >>> Process: MITA [10810] Path: /Applications/MITA.app/Contents/MacOS/MITA Identifier:com.artsinteractiveinc.mita Version: 3.0 (3.0) Code Type: X86-64 (Translated) Parent Process:launchd [1] User ID: 501 Date/Time: 2023-11-02 13:22:17.1555 -0400 OS Version:macOS 14.1 (23B74) Report Version:12 Anonymous UUID:982CECFD-B763-4068-2C69-6639836A03DF Sleep/Wake UUID: DAD13568-D6D9-4419-BF53-FA013DE5385B Time Awake Since Boot: 11 seconds Time Since Wake: 1041 seconds System Integrity Protection: enabled Notes: PC register does not match crashing frame (0x0 vs 0x1026B9E58) Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0004 Exception Codes: 0x0001, 0x0004 VM Region Info: 0x4 is not in any region. Bytes before following >> region: 140722906071036 REGION TYPESTART - END [ VSIZE] >> PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> mapped file 7ffc9ad4-7ffcc03e8000 [598.7M] >> r-x/r-x SM=COW ...t_id=60eeba9b Error Formulating Crash Report: PC register does not match crashing frame (0x0 vs 0x1026B9E58) >>> ___ >>> 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/list
Re: decrypt error junk
On 2023-11-02 02:06, Tom Glod via use-livecode wrote: I have found a "wrong decryption key" that does not return a bad decrypt error, but returns garbage into "the result". Every other wrong key correctly gives the usual error. The right key works to decrypt. What exact error do you get with a wrong key vs the not-so-wrong key? the length of the encryption/decryption key is always 64 characters it is always alphanumeric, because its a hash derivative, no weird characters, always the correct length. and the salt is the same for every key i tried. I can program around it, but its unsettling. I will report it, but in the meantime has anyone ever come across this garbage in "the result" as a result of an incorrect. decryption key? So I don't think this is a bug, but expected behavior. The encrypt/decrypt operations are very low-level they 'simply' apply the specified algorithm to the data. Encryption/decryption is 'just' a mathematical function which uses the 'key bytes' and 'input data' to derive an output - in particular, decryption does not include any validation checks to ensure the provided decryption key is what was used to encrypt in the first place - that's something you have to do yourself. There's a huge variety of ways to do this - but perhaps the simplest is to add your favorite (simple) hash of the encryption key before the data being encrypted: (pseudo encryption code - I don't know exactly what form of encrypt you are using!): local tKey, tHash put deriveMyEncryptionKey(tPassword) into tKey put md5Digest(tKey) into tHash encrypt tHash & tData using ... with password tKey (pseudo decryption code - I don't know exactly what form of encrypt you are using!): decrypt tEncryptedData using ... with password tKey if byte 1 to 16 of tData is not md5Digest(tKey) then throw "incorrect password" end if Of course I'm now slightly intrigued as to what checks OpenSSL *can* actually do to be able to generate a 'bad decrypt' message - so by all means file a bug/send a test stack to support and we can at least advise on that (and potentially update the docs). Warmest Regards, 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
Re: Modify timeout for shell function
On 2023-11-01 11:20, Ben Rubinstein via use-livecode wrote: An install which runs daily and makes a number of calls using the shell function occasionally reports The process "..." exceeded the timeout of 10 seconds. I'm not sure where this timeout is defined; I'm not totally sure where this message is coming from (the shell? LiveCode? the process that was invoked through the shell command?). Definitely not LiveCode - LiveCode runs the shell process until it ends on all platforms its implemented on (I'll leave it for another day to ponder whether there should be some sort of timeout to account for rogue/hung processes!) Assuming for a moment that this isn't a timeout internal to the process that I happen to be invoking, is there a way in LiveCode, or in shell configuration, to modify this timeout? Doing a quick google for variants of "The process ... exceeded the timeout of 10 seconds" - then there are various results relating to Laravel - which is a PHP framework. So are you shell'ing to PHP? If so my guess is that whatever PHP script you are running is using sub-processes too, and has a process timeout set to 10s. Warmest Regards, 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
Re: Filter with wildcards
The filter command has had a ‘with[out] regex’ form for a long time - so I’d use a regex instead :) (I’m pretty sure [ ] is a set of characters to match, rather than a list of sub strings, in wildcard expressions) Warmest Regards, Mark. Sent from my iPhone > On 30 Oct 2023, at 17:19, David Glasgow via use-livecode > wrote: > > Hi folks, > > I am doing the above and struggling with an oddity that I can’t find guidance > on on Livecode or wider wildcard stuff > > A simple example is I am searching text messages for 'with you' or 'with u’ > > so I use the wildcard form > > *with [you,u]* > > That finds all examples of both just fine. However, it also finds ‘with > unlimited cheese’ and 'with us’, ‘with yours’ etc. so I want a space after > both u > > When I put two spaces inside the square brackets after each string, the > search still works but spaces seem to be ignored (so still finds the above > resamples I don’t want). > > If I put a single space after the brackets the first bracketed string is > ignored and the filter only finds “with u “ > > Hope someone can help me stop pulling my baffled face > > Cheers > > David Glasgow > > > ___ > 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: Oddity in 'currentCard' function?
On 2023-10-25 13:57, Paul Dupuis via use-livecode wrote: On 10/25/2023 12:34 AM, Mark Waddingham via use-livecode wrote: If you want to do stuff with the current card of a stack, then don't use the currentCard property - 'this card of stack ...' *is* a chunk reference and thus it doesn't care whether the card has a name or not. Okay, I get that id is a legacy return value when there is no name. I'd just like to confirm that: this card of stack "X" and the currentCard of stack "X" refer to the same card, even if in different ways (actual object reference vs short name)? Yes - 'the currentCard of stack "X"' is equivalent to 'the short name of this card of stack X'. The currentCard property was added a very long time ago to be used by a project which never saw the light of day (I'm not sure I remember what it was now!)... There was (apparently!) a need at that time to be able to switch cards in a stack *without* the stack coming to front (which is what happens when you use the only alternative 'go card ... of stack'). It was added as a property as that was the quickest/fastest way to do so, for something which I don't remember being entirely convinced by at the time - it wasn't documented for a long time, but then I think someone asked about it and it had been there long enough and it doesn't do any harm really so it was documented. Basically, its main use was for changing card (i.e. as a settable property); rather than finding out what card was current (since that was already catered for via interrogating 'this card of this stack'). With hindsight, if the ability to switch cards without bringing the stack to front is indeed useful then it should probably be provided via a new command, or an augmentation of the 'go' command (like we have go visible / go invisible). Warmest Regards, 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
Re: Oddity in 'currentCard' function?
On 2023-10-25 15:41, Craig Newman via use-livecode wrote: Paul. The construction "answer this card of stack “X” does not work if you are not on stack “X”: answer the currentCard of stack “X” —works answer the name of this card of stack “X —works answer this card of stack “X”—Nope 'this card of this stack' is an object reference - when evaluated in contexts which don't expect an object reference, object references return the *content* of the object, or an error (if the object has no content)... Only buttons and fields have content - in which case evaluating them returns the 'text' of the object. Most things *don't* expect an object reference - places that do are where an object needs to be acted on, rather than a value being needed. For example: set the X of put exists() put there is an answer Warmest Regards, 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
Re: Oddity in 'currentCard' function?
On 2023-10-24 18:00, Paul Dupuis via use-livecode wrote: I think I found a oddity in the "currentCard" property. The documentation states that the currentCard property return the short name of the current card of a stack: for example: put the currentCard of stack "Untitled 1" into tCardName You can then execute code such as: set the myProperty of cd tCardName of stack "Untitled 1" to tValue ... But again, breaking that example above (set the myProperty of the currentCard of stack "Untitled 1" to tValue) into 2 lines: put the currentCard of stack "Untitled 1" into tCardName set the myProperty of cd tCardName of stack "Untitled 1" to tValue FAILS if the card has no name. Something just seems off here? As Jacque said, if an object has an empty name then the short name returns ` id ` (i.e. an id chunk) - this is long standing behavior and one which I'm not sure is entirely helpful (it should perhaps just return empty!). You see the same effect in other properties which return a 'short name' - e.g. the menubar of a stack. So its entirely consistent with 'object name' properties. (In these cases there is no string which such properties could return which would help distinguish unnamed things and that could be used to resolve them in some sort of chunk in a consistent manner as object names can be arbitrary strings). If you want to do stuff with the current card of a stack, then don't use the currentCard property - 'this card of stack ...' *is* a chunk reference and thus it doesn't care whether the card has a name or not. If you want the long id of the current card of a stack to manipulate 'out of context' then use the long id: put the long id of this card of stack ... into tCardId Of course, if you really want to use the currentCard (for whatever reason), then you need to make sure all your cards have names (which to be fair, is a good habit to get into - as is naming all objects with some, unique, name!). Warmest Regards, 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
Re: OS X document icon missing
On 2023-10-18 20:54, J. Landman Gay via use-livecode wrote: On 10/18/23 10:35 AM, Paul Dupuis via use-livecode wrote: If you have identified the document extension in the Standalone setting for macOS and set an ics file of icons (or the appropriate sizes required by Apple) than documents created by that app should display the icon. No go. Here is the relevant part of the plist: CFBundleDocumentTypes CFBundleTypeExtensions .rbox The extension shouldn't have an initial `.` - I suspect that is the problem :) Warmest Regards, 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
Re: Livecode 10dp6 and web fonts
On 2023-09-27 15:49, Paul Dupuis via use-livecode wrote: I get the value of web font support in LC10dp6 for WEB based applications. However, if you making a multi-platform application, you still have the issue of UI consistency across platforms as web fonts can't be used in desktop standalones (or, I assume, phone standalones) It is true that web fonts are a 'browser' thing - however, you can still download the underlying TTF files from the web font service and include them in native standalones if you want to use the same fonts across web and native apps (obviously, you need to check the license the fonts are served under - but that's true with any non-system fonts you might include at the moment). In the future we could look at making font inclusion easier in standalones cross-platform (i.e. allow specifying fonts in the s/b at a higher-level and then it doing the right thing) - however, there are some engine improvements to font selection across the different platforms we need to do first (in particularly, 'fixing' the font enumeration properties and allowing specification of different weights and stretches via the textStyle properties!). Warmest Regards, 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
Re: Android ANR (App not responding | Jacque was right :-)
On 2023-09-14 18:49, Klaus major-k via use-livecode wrote: But I'm using a Mac and it looks like that tool is not available here in the SDK tools folder. Maybe available somewhere in "Android Studio". And my problem NEVER happened when I'm at home, only during band rehearsals and gigs! :-D So this is perhaps the most useful observation... This could suggest there is a either a difference in usage, or environment between the two places. e.g. - is the app used more / for longer at gigs compared to home? - how is the tablet powered at home vs at gigs? - how does the tablet connect to the internet at home vs at gigs? (even if the app does not use the internet, lots of background stuff on Android *does*) - when the problem happens is there anything specific you can think of in common with what you were doing / the app was doing / the device was doing just before? (e.g. does it happen just after the device has gone to sleep). The fact it is 'hanging' suggests there is something (on startup?) which is failing and causing an infinite loop. Is there anything in the startup code for the app which waits for something to happen? e.g. an network request, something to initialize etc.? Warmest Regards, Mark. P.S. If you send your app's source to supp...@livecode.com with a rough outline of where to look for startup code etc. then Panos and I can take a quick look and see if we can see anything which may be causing your issue. -- 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
Re: Sorting by item ... of each and item ... of each
On 2023-09-03 10:26, panagiotis m via use-livecode wrote: Hello Matthias, I do not think that the syntax "sort by sortKey1 and sortKey2" is supported Heh technically it 'is' - and does do something but it won't be what you expected... So the syntax for sort in this case is: sort by This works by iterating over the elements in , passing each through the expression to generate a sort key list, sorting that list and then reordering the original list. Expressions can contain the boolean 'and' operator, so: sort by X and Y Means that the sort key is evaluated as 'X and Y' for each element - meaning sort ends up sorting a list of 'true' and 'false' values. As Panos says, if you want to sort by separate fields with decreasing priority you need to do multiple sorts from least priority to most - this works because 'sort' is stable (if two elements compare the same, then the order of them in the output list is the same as the first). The alternative is to work out a sort expression which combines the two parts of the element you want to sort so that the sort keys sort in that order. This can be quite tricky, but (for example) - let's say your container has elements of the form: , So you want things in the 'obvious' sorted order - then you could use: sort tSections ascending text by format("%08d%08d", item 1 of each, item 2 of each) Here the sortkey is defined so that the text sort of the sort keys is that same as sorting first by sub-section number and then by section number. Warmest Regards, 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
Re: Pasting text and images together?
You could poke around the raw clipboard data - this is platform specific (in terms of the keys) but gives a complete reflection of the system clipboard: lock clipboard put the keys of the rawClipboardData unlock clipboard This will dump what raw data types are present - then you can fetch using ‘the rawClipboardData[key]’. Note that you need to lock and unlock the clipboard around ‘raw’ access. Warmest regards, Mark. Sent from my iPhone > On 1 Sep 2023, at 20:33, David Epstein via use-livecode > wrote: > > To clarify my original question: > > I'm not expecting the built-in paste command to handle this task; I'm > wondering if I can script my own paste command to handle it. > > Richmond, I can write a script to "paste" an image by itself (by creating > an image and setting its text to clipboardData["image"]). > > But is there some way I can access both the text and the image that are on > the clipboard after I have copied a combination of those from, e.g., a web > browser? (Pasting to Apple Notes confirms that the clipboard contains both > text and image.) > ___ > 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: is strictly a name
On 2023-09-01 17:44, Paul Dupuis via use-livecode wrote: I may just be experiencing a brain fart, but I have read the release notes several times, and I don't understand the purpose of the new: is strictly a name operator? Can someone explain its purpose in really basic terms or examples? Its purposes is so that it is possible to tell when a value is a 'name' rather than a 'string' when the distinction is important. The cases where this is true are few and far between - indeed, the use-case it was added for was so that the exact runtime type of constant values generated when parsing script (e.g. from constant initializers) is preserved. There are two kinds of strings internally - strings and names. All names are strings, but not all strings are names. The difference is that there is only ever one instance of a name with a given string in memory - e.g. if two variables hold a name whose string is "foo", then they will hold the same pointer. As to what names are - they are an optimization for cases where the engine will often do comparisons between them. Names are implemented in a global hash table in such a way that caseless and case-sensitive comparisons are constant time (when both values being compared are names). The keys of an array are names - which means the engine never has to compare the actual characters of a key in an array as it does a lookup. Literals in scripts are stored as names - so if you have 100 instances of the string constant "foobar" throughout all your scripts as literals - there will only actually be one instance of "foobar" Similarly, internally, object names, handler names and variable names are all stored as, well, names (again - because they are commonly compared against each other). Some examples of where you can observe a name are: put "foo" is strictly a name => true put ("foo" & empty) is strictly a name => false repeat for each key tFoo in { "foo": true } put tFoo is a strictly a name => true end repeat There might be a few other places where you could see a name rather than a string, but as mentioned above - its unlikely that 99.9% of people would ever need to worry about it :) Warmest Regards, 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
Re: [[ ANN ]] Release 9.6.10 RC-1
On 2023-08-19 21:57, Tom Glod via use-livecode wrote: Hello, Does this mean we have JSON support in SQLite? This is from the documentation.: In other words, the JSON functions went from being opt-in with SQLite version 3.37.2 and earlier to opt-out with SQLite version 3.38.0 and later. The SQLite JSON support was included in dbsqlite in 9.0.3 - https://quality.livecode.com/show_bug.cgi?id=21821 Warmest Regards, 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
Re: Detecting when resizeStack is completed
On 2023-08-18 17:03, David Epstein via use-livecode wrote: How can I redraw objects after the user has resized the stack, but not continuously during the resize? Releasing the mouse at the end of a resize does not appear to send a mouseUp message. Normal window resizing is handled by the OS, so doesn't generate mouse events. One way to get close to what you request is to only relayout your objects if the user has not changed the size within a short period. Something like: ``` local sPendingResizeId constant kResizeTimeout = 20 on resizeStack pWidth, pHeight /* If there is already a deferred request to resize then cancel. */ if sPendingResizeId is not empty then cancel sPendingResizeId end if /* Defer the request to resize for a further period. */ send "_doResizeStack pWidth, pHeight" to me in kResizeTimeout milliseconds put the result into sPendingResizeId end resizeStack on _doResizeStack pWidth, pHeight lock screen ... do relayout ... unlock screen end _doResizeStack ``` This defers the relayout code until a resize stack message has not been sent for the timeout interval. Warmest Regards, 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
Re: Linux filenames in LC Server
d when it wants to open myscript.lc instead of pointing to the livecode-server executable (in which case it might have to have a .cgi suffix rather than .txt), or is it a shell script to be executed by livecode-server? The provided text should be put into a shell script which should be launched *instead* of livecode-server - so configure your CGI environment to call said shell script when it encounters a lc server script file to run. It will then set environment variables and then 'exec' replaces the shell script with livecode-server (in the same process). Technically while what the engine is doing is correct (relative to its need to have filenames represented as strings internally at least) it isn't ideal. There are two options to improve the situation (when the locale env vars are not set / set to C): 1) Rather than assume ASCII, assume native - this would preserve the bytes in the filename regardless of system encoding. 2) Rather than assume ASCII, assume utf-8 - this would correctly represent filenames which are valid UTF-8, but would still fail on filenames with bad encoding Here (1) has the advantage that filenames would be preserved; but with the slight caveat that if you combined with other unicode characters (in a report say); the filenames would be displayed incorrectly (here 'display' would also include being sent as part of some protocol response). Here (2) has the advantage of everything working as expected assuming the server in question is utf-8 - it would still fail on filenames which are badly encoded though. However the latter could be mitigated by making the sys-string<->lc-string conversion slightly less strict - i.e. bad utf-8 chars map to/from '?' as they do in textEncode/Decode - so at least you could see the bad filenames. I suspect (2) is overall better - its only downside is that you would not be able to manipulate files on the server which had badly encoded utf-8 names. However, that seems like an extreme edge case; and one which you could work around by just setting the LANG env var to a native encoding and put appropriate code in your app to deal with. Warmest Regards, 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
Re: Browser widget: "Navigation request cancelled"
On 2023-08-15 12:08, Ben Rubinstein via use-livecode wrote: Is it possible to get any more detail about what's going on? I'm guessing you are using 10-dp-5 :) The issues here are regressions caused by the switch to WKWebView in 10 (previously we used the older WebView system web browser API): The missing progressChanged messages issue is https://quality.livecode.com/show_bug.cgi?id=24271 The missing other messages issue is https://quality.livecode.com/show_bug.cgi?id=24247 The latter is related to server vs local redirects in the web page. Both should be fixed in the upcoming 10-dp-6. Warmest Regards, 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
Re: Linux filenames in LC Server
had to to encode/decode filenames appropriately yourself and I guess utf-8 was just assumed. With PHP7 I believe it handles unicode transparently a bit like LC does, so I'll see if I can see what PHP7+ uses to determine the system encoding. Indeed, it might do no harm at all to just assume UTF-8 encoding for Linux in the engine if the locale vars are not set (which appears to be the case here) which would resolve the problem transparently. Warmest Regards, 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
Re: Linux filenames in LC Server
On 2023-08-14 12:30, Mark Waddingham via use-livecode wrote: So assuming that the defaultFolder is accessible in your above script (as a read-only folder would also cause the same error) then there does appear to be something up here... Okay so I'm pretty sure the linux server engine is doing the right thing. As mentioned previously, Linux filesystems don't actually care what the encoding of a filename is - to linux its just a sequence of bytes The interpretation is given by the 'locale' settings which are in effect for any given program. So, when you run lc-server from a terminal session directly, its almost certainly the case that the LC_ALL and LANG environment variables are set to en_US.UTF-8 (or some other language code DOT UTF-8 - it is the UTF-8 which is the important bit). On Linux, a C API nl_langinfo() is used to fetch the encoding to use when talking to the system APIs (e.g. filesystem APIs) - this (I believe) derives its information from LANG/LC_ALL. If the latter *are not set* then it will likely default to the 'C' locale which has no interpretation of any non-ascii chars, and thus attempts to encode/decode utf-8 encoded filenames will fail. My theory is that these variables are not set in the configuration for running CGIs in Apache (or whatever web server is being used in this instance). Digging around it looks like Apache (at least) has a `SetEnv` directive which would allow these environment variables to be set, e.g. SetEnv LC_ALL en_US.UTF-8 SetEnv LANG en_US.UTF-8 Although I'm not 100% sure where such things go, perhaps someone more conversant with apache config could chime in to suggest. Warmest Regards, 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
Re: Linux filenames in LC Server
On 2023-08-14 12:12, matthias rebbe via use-livecode wrote: Hi Mark, when i read Neville's post i thought also about normalize, although i really do not have a clue about the whole unicode stuff, but i remembered that the standalone builder make use of the normalize function. ;) So i used this script on LC Server to write the seconds to a file containing an a-umlaut in its name. put normalizeText("testä.txt", "NFC") into tFile put the seconds into URL ("binfile:"&tFile) put the result put "" put the files put "" put tFile But that does not work. "The result" returns 'can't open file'. Hmmm - I must confess that I misread Neville's post - he did explicitly mention 'creating' files... The normalization would only arise if the file already existed, but the requested (incoming) filename was normalized differently (thus resulting in the file not being found). So assuming that the defaultFolder is accessible in your above script (as a read-only folder would also cause the same error) then there does appear to be something up here... Warmest Regards, 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
Re: Linux filenames in LC Server
On 2023-08-14 02:45, Neville Smythe via use-livecode wrote: OK, so the macOS *is* using utf-8 for its file names - the [e-acute] in the filename Carré.txt is rendered with two bytes [C3A9] not the single byte MacRoman encoding. I got tricked by copying the terminal listing into another program rather than hex dumping within the terminal, and somewhere in the process the native encoding was preferred. So one must *not* textEncode a filename to utf-8 before writing a file to disk, LC deals with the encoding, although you *should” textEncode its contents. Which leaves the problem of why I can’t get LC Server on Linux to write non-ascii filenames So I suspect the problem here is normalization, rather than the inability of Linux to write non-ascii filenames. Characters such as e-acute / e-grave have *two* representations in unicode - the decomposed and composed form. The composed form is a direct mapping from the native encodings and is a single codepoint, the decomposed form will be two codepoints - (e, combining-acute/grave) Depending on where the string comes from it might either be composed or decomposed - macOS filenames are stored decomposed in the FS, but the higher-level parts of the OS make either form work (in a similar fashion to how macOS filesystems are case-insensitive by default). Linux filesystems, however, are both case-sensitive and form-sensitive - a filename must match byte to byte with what it was created with (indeed, linux filesystems care nothing for encodings, they see filenames as a sequence of bytes which are interpreted relative to the user's current locale - the default locale on linux these days is utf-8). If your app is managing the files completely on Linux (i.e. it is creating / deleting them and the filenames are not user-editable) then (if this is the caseu) the problem should be fixable by choosing a normalization form when you create / lookup the file - i.e. pass all filenames on the server through `normalizeText(, )` - here you want form to be either "NFC" (composed) or "NFD" (decomposed). Warmest Regards, Mark. P.S. For all the gory details about Unicode normalization forms see - https://unicode.org/reports/tr15/ -- 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
Re: LC 9.6.9 App uses too much memory!
On 2023-08-13 14:29, harrison--- via use-livecode wrote: Hi LiveCoders, Clearly this is a bug in LC 9.6.9, but I don’t know what is causing the problem. I noticed that others in the past have run into a similar problem. Was this ever reported as a bug? Could you file a bug report with recipe and attach (or send to supp...@livecode.com if its sensitive) the stack and recipe for reproducing the problem so we can take a look. Thanks in advance, 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
Re: charIndex property
Oh those pesky chunks which don’t ‘cover’ the target string (which is actually all of them except codeunit/point/char come to think of it). I should have run through a few more examples in my head before posting…. Alternative attempt: Put null into word N to -1 of S Delete codeunit (codeunitoffset(null, S) to -1 of S Return the number of chars in S + 1 The problem before was the chars which do not form part of the last chunk and remain after deletion. The above puts in a sentinel char which can be searched for to find where the requested chunk started. Second time lucky? ;) Mark. Sent from my iPhone > On 27 Jul 2023, at 21:23, Paul Dupuis via use-livecode > wrote: > > On 7/27/2023 4:31 AM, Mark Waddingham via use-livecode wrote: >>> On 2023-07-26 18:02, Paul Dupuis via use-livecode wrote: >>> If I have some text in a field, I can use the "charIndex" property (see >>> Dictionary) to obtain teh character position of the first character of a >>> chunk. >>> >>> Does anyone know of a clever way to do the equivalent of the charIndex for >>> an arbitrary chunk expression for a container/variable (i.e. not an actual >>> field object)? >> >> This should work I think: >> >>function charIndexOfWord pWordIndex, pTarget >> delete word pWordIndex to -1 of pTarget >> return the number of characters in pTarget + 1 >>end charIndexOfWord >> >> Deletion of chunks works from the first char that makes up the computed >> range, so you are left with all the characters which sit before it. >> >> The index of the character immediately before the start of the specified >> word is the just the number of characters which sit before it; and so the >> index of the first char of the specified word (which is what charIndex gives >> you in a field) is that +1. >> >> The above should work for both +ve and -ve indices, and the obvious changes >> will make it work for other string chunks (i.e. change 'Word' for ). >> > > Mark, > > Thank you very much. This was a brilliant approach and I should have thought > of it myself. However, it is not quite an accurate substitute for the > charIndex property of a field. The following example illustrates the issue: > > pTarget is [The quick brown fox jumps over the lazy dog. The lazy dog was > named "Oz".] > pWordIndex is 8 (having been derived from searching for 'lazy', the 8th word) > > Using [] to quote strings. > delete word 8 to -1 of pTarget -- deletes [lazy] to ["Oz"] but not the period > (.) at the end since it is not considered part of word -1. > This leaves pTarget as [The quick brown fox jumps over the .] > The number of characters in pTarget + 1 is actually not the position of the > [l] in [lazy], which is character 36, but the [a] in [azy], character 37, due > to the period being left. > > There are some similar issues, being off by or more, with sentences and > paragraphs in longer text. > > Thank you very much for chiming in with a good direction to try. > > Paul Dupuis > Researchware > > > ___ > 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: LC on Sonoma beta
On 2023-07-26 21:20, Marty Knapp via use-livecode wrote: Anyone have any input regarding LC apps running on the Apple Sonoma beta? I have not installed it but have some customers who have and saying my app crashes. Unfortunately LC does currently crash on startup on the macOS Sonoma beta releases - https://quality.livecode.com/show_bug.cgi?id=24278 We've investigated and have a fix. As this essentially blocks any sort of testing of LC and LC apps on macOS Sonoma we are currently working on back-porting the fix to 9.6.9 and doing a 'hotfix' release of that version (the fix will obviously then flow into the upcoming 9.6.10-rc-1 and 10.0.0-dp-6 releases). I can't guarantee that there won't be other issues in macOS Sonoma as yet of course (as it is still beta software and a couple of months away from release), but at least we will actually be able to find out! Warmest Regards, 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
Re: charIndex property
On 2023-07-26 18:02, Paul Dupuis via use-livecode wrote: If I have some text in a field, I can use the "charIndex" property (see Dictionary) to obtain teh character position of the first character of a chunk. Does anyone know of a clever way to do the equivalent of the charIndex for an arbitrary chunk expression for a container/variable (i.e. not an actual field object)? This should work I think: function charIndexOfWord pWordIndex, pTarget delete word pWordIndex to -1 of pTarget return the number of characters in pTarget + 1 end charIndexOfWord Deletion of chunks works from the first char that makes up the computed range, so you are left with all the characters which sit before it. The index of the character immediately before the start of the specified word is the just the number of characters which sit before it; and so the index of the first char of the specified word (which is what charIndex gives you in a field) is that +1. The above should work for both +ve and -ve indices, and the obvious changes will make it work for other string chunks (i.e. change 'Word' for ). Hope this helps! Warmest Regards, 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
Re: Livecode 10.0.0dp5 new reserved words
On 2023-07-11 13:26, Mark Waddingham via use-livecode wrote: Anyway, we'll try and figure out what has changed to cause the change in behavior - at the very least we can go back and add a 'breaking change' warning to the release note for the change which caused the issue. Okay so after a bit of digging I can confirm that this is down to an unintended consequence of implementation constant expressions. The behavior prior to that feature was: You are allowed to assign and evaluate variables whose name is the same as property keywords which can only appear as object properties (i.e. require an OF afterwards) and are not also constant keywords ('left' and 'right' I think are the only two which are object properties and constants). Further, if explicitVariables is true then you cannot declare such variables, but you can evaluate them. (In this case, they would act as unquoted literals - you can still assign indirectly using do with explicitVars turned off at the time of the do). The reason it was changed was to fix a problem with the constants 'left' and 'right' being used in constant initializer expressions - but at the expense of object only properties not being able to be variables. That problem needs to be resolved in a different way. So this is a bug/regression - not so much because of the use of 'tExt' (text) but because scripts which use any object property keyword as a variable name will break. As many object property keywords are not dictionary words - but compounds or contractions - this means that even scripts which conform to the long standing rule could fall foul. Warmest Regards, 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
Re: Livecode 10.0.0dp5 new reserved words
On 2023-07-11 13:20, Paul Dupuis via use-livecode wrote: Thank you! Bug filed: https://quality.livecode.com/show_bug.cgi?id=24266 I am fine changing 'tExt'. As Martin just posted, ‘All words in the English Dictionary should be considered reserved words.’ is not a bad rule. Just to illustrate how the eyes and mind can play tricks, I have been using the variable 'tExt' for parsing file extensions for DECADES and ONLY TODAY realized that it was the word 'text'! I never saw it as a dictionary word until today! Yeah - Martin is correct that the rule about words in the English dictionary should all be considered reserved is still very much in force, and has been around longer than I've worked here! Cases of using 'tExt' is not uncommon - as it is really difficult to see that it is 'text'... Another one (which bit Ali recently) is `pLayer'. I'm sure there are a fair few other examples. Anyway, we'll try and figure out what has changed to cause the change in behavior - at the very least we can go back and add a 'breaking change' warning to the release note for the change which caused the issue. Warmest Regards, 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
Re: Livecode 10.0.0dp5 new reserved words
On 2023-07-11 12:28, Paul Dupuis via use-livecode wrote: Does anyone, including folks at the mothership, have a list of new reserved words in Livecode 10? I have used a variable called "tExt" (t for temp, Ext for extension) to pull of the file extension from file paths. i.e. if tFile contains "C:/users/paul/desktop/image.png" set itemDel to "." put last item of tFile into tExt -- tExt contains "png" However, in LC 10.0.0dp5, the word "tExt" (which is "text") now appears to be a reserved work and you can not use it as a variable. This is not true in LC 9.6.9. This has me asking: Are there any other new reserved words I should refactor out of my code before I get mysterious errors? I don't think we knowingly made 'text' not be allowed as a variable in non-explicitVariables mode... You cannot explicitly declare `tExt` as a variable in 10 or 9.x or (I think) ever - but it obviously worked in 9.6.x and before if you don't use explicitVariables. I'm not sure what change we've made which has caused that - file a bug and we'll look into it - its probably a regression, but could be a (necessary, but unrealized) side-effect of another change we've made internally. Warmest Regards, 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
Re: Different default bg color of stacks Mac/Win
On 2023-05-11 15:51, Klaus major-k via use-livecode wrote: Hi Mark, Am 11.05.2023 um 16:49 schrieb Mark Waddingham via use-livecode : On 2023-05-11 15:45, Klaus major-k via use-livecode wrote: See screenshot of a stack with two OPAQUE (and white) text fields created on Mac and opened on Windows. Surprise, surprise... <https://www.dropbox.com/s/n58ahwlivvzygmy/windows_grey_bg.png?dl=0> Is this a bug or feature? If a bug, should I create a report for that? Not a bug - the default is to use 'native' themes on desktop platforms, and that also influences the background color of a stack. aha, thanks for the quick answer. Is this documented somewhere? Yes - in the dictionary entry for the backgroundColor property of objects: ``` Cross-platform note: On Mac OS, OS X, and Windows systems, if the backgroundColor of all objects in the object hierarchy is empty, the background color set by the system is used. ``` Warmest Regards, 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
Re: generate an Array using value for naming the keys?
On 2023-05-11 15:47, matthias rebbe via use-livecode wrote: Mark, thank you very much! i didn't know or remember that the key name of an array can be created directly using strings and variables Maybe i even did that in the past, but could not remember anymore. I really thought i have solved it that time with value() :) No problem - of course, I used & in my example - but when I'm doing stuff like that I tend to use format: put tFoo[format("wp_%s_%s", tMiddlePart, tSuffix)] into tMiddlePartSuffixValue It does the same job, but I find it more readable (as the structure of the string can be seen immediately without having to wade through quotes and ampersands :) Warmest Regards, 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
Re: Different default bg color of stacks Mac/Win
On 2023-05-11 15:45, Klaus major-k via use-livecode wrote: See screenshot of a stack with two OPAQUE (and white) text fields created on Mac and opened on Windows. Surprise, surprise... <https://www.dropbox.com/s/n58ahwlivvzygmy/windows_grey_bg.png?dl=0> Is this a bug or feature? If a bug, should I create a report for that? Not a bug - the default is to use 'native' themes on desktop platforms, and that also influences the background color of a stack. If you don't want that - then you need to explicitly set the background color. Warmest Regards, 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
Re: generate an Array using value for naming the keys?
On 2023-05-11 14:36, matthias rebbe via use-livecode wrote: The middle part of the key names changes and there can be about 50 different "middle parts" and there are 10 main keys (after the middle part) _content, _text _html and so on. So without an idea i would have to create the code to fill all values for the array keys with the middle part aa and then the code for the middle part cd and so on. Is there a way to use value for this. So i could just add the middle part of the key name to a variable and use that then with value() to create and file the array? Perhaps I'm misunderstanding what you are trying to do as you mention using value() for something which doesn't sound like it needs it... Array keys can be arbitrary (string-valued) expressions - i.e. they don't have to be literal strings: e.g. put tFoo["wp_" & tMiddlePart & "_" & tSuffix] into tMiddlePartSuffixValue Warmest Regards, 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
Re: Custom property retrieval incorrect
On 2023-04-27 23:32, J. Landman Gay via use-livecode wrote: Those are exactly the two values I get too. The earliest version of LC I currently have installed is 9.6.7 and it happens there and in three newer versions after that. A custom property named "cVers" works okay. But I've been using "cVersion" for years and years, so not sure what the ripple effect may be if I update my older apps (which is how I found this one.) For now I can change the name of the property, I guess. Thanks for tracking it down, Mark. I'm not crazy after all. On 4/27/23 5:09 PM, Mark Wieder via use-livecode wrote: The 1.0.4 cVersion comes from com.livecode.library.i18n.1.0.4 The 3.0.9 cVersion comes from com.livecode.library.smartcrumbsvcw.3.0.9 Unfortunately the scripts for both are locked, so there's no workaround other than not using the cVersion custom property. @MarkW : Thanks for tracking down which libraries it is. @Jacque (and anyone else): You can just remove those two libraries/extensions from My LiveCode for now (assuming you aren't using them). I've poked the developers of them and asked them to remove the offending getProp handlers from those libraries - hopefully an update will go out next week :) Warmest Regards, 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
Re: Problem using AppleScript of "system events" to click a location on screen
You didn’t mention the kind of mac you are running and whether either the standalone or ide is running in rosetta or not :) To be fair, that part was about the exec error rather than the expected outcome though… The reason you are seeing the effect you are when not doing the request from a separate process is that executing applescript is a modal operation (Ie you can’t get an application to use AppleScript to control itself) - and I suspect the accessibility framework is timing out internally and just doing the best it can in that situation. Warmest Regards, Mark. Sent from my iPhone > On 27 Apr 2023, at 19:22, Ben Rubinstein via use-livecode > wrote: > > Update to note: > > 1) Difference in LiveCode versions. > > Under the IDE in LiveCode 9.6.7 behaviour is as per the standalone; no click, > and 'the result' is the path to the control. Under the IDE in LiveCode 9.6.8 > or LiveCode 10.0.0dp5, 'the result' is "execution error". > > 2) The browser widget is a red herring; relevant only insofar as if it was > some other spot on the stack, I could just the LiveCode "click at ". > Whether over the browser widget or some other part of the stack window, > invoking the applescript returns the identity of the control at that > location, rather than clicking it (in LC 9.6.7 IDE, or standalone built from > any version); or execution error in later IDEs. > >> On 27/04/2023 16:42, Ben Rubinstein via use-livecode wrote: >> I had a need to click on an element in a web page loaded in a browser widget >> on a card. >> There might be an elegant way to do this using javascript injected into the >> widget, but I'm too ignorant to figure it out. >> So to save time (hah!), I though I could use the accessibility functionality >> to just click on that bit of the screen. I could get the location to click >> within the stack, then use globalLoc to convert it to screen coordinates. >> (This is just a personal stack to achieve an objective, nothing that's ever >> going to be shared with anyone else, so any filthy/fragile method is OK if >> it works.) >> I tested this in Script Debugger: >> tell application "System Events" >> click at {917, 667} >> end tell >> It worked fine. >> So then I tried the same script in my stack, via >> do ... as "applescript" >> And after a brief spinning pizza, got the dry result "execution error". >> I expected that this would happen because I needed to give it permission to >> control the computer; but after granting that in System Preferences, there >> was no change. >> Just for fun, I tried building a standalone from my stack. This demonstrated >> a different effect: first I got the same result "execution error". Then I >> granted it permission for this standalone app to 'control the computer'. >> Now, there's still no evidence that it sends a click; but it gives a >> different result, which I think is the path to the UI element corresponding >> to that location. If the point is over a native control in the stack, it's >> something like >> window "Ben Test Stack (1)" of application process "Ben Test Stack" >> of application "System Events" >> (I don't think LiveCode controls are recognisable by the accessibility >> system.) If the point is over the browser widget, 'the result' is something >> like: >> group 2 of UI element 1 of scroll area 1 of group 1 of group 1 >> of window "Ben Test Stack (1)" of application process "Ben Test Stack" >> of application "System Events" >> ("Ben Test Stack" is the name of my stack and of the standalone. My guess >> about the complicated control path is that it reflects the complicated web >> page loaded in the browser widget.) >> So that does suggest that there is something which doesn't quite work about >> giving the IDE permission to use the Accessibility Framework, but which does >> for a standalone. But still doesn't explain what the problem is. >> I finally solved my problem with an even uglier hack: compiling the script >> from Script Debugger as an 'application', and then in my stack, instead of >> executing the applescript directly, using "launch" on that application. >> Yeuchh. >> Can anyone shed light, either on how to grant the IDE permission to use the >> Accessibility controls; or on why the applescript wouldn't work? >> TIA, >> Ben >> ___ >> 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
Re: Weird window behavior
Okay that is strange - but the fact it is happening when levure is loaded suggests it is some property or mechanism it is adding. The engine only really has three things (that I can think of) which change window stacking order… The backdrop - which makes the engine *try* to keep all the windows next to each other, with the backdrop window immediately behind the bottom one; The ‘raiseWindows’ global property which is basically the same as the backdrop feature - except the backdrop has zero width and height. The go command which raises a stack to the top (amongst those with same mode). So i’m not sure how a script in levure could cause that effect - unless it’s setting ‘the raiseWindows’ to true (thus making the problem you are seeing the same as the backdrop issues that others are on Ventura). Anyway, the fact it requires levure to be loaded for it to happen means we can track it down! Warmest Regards, Mark. Sent from my iPhone > On 27 Apr 2023, at 19:58, Marty Knapp via use-livecode > wrote: > > No, not using the backdrop feature. I did try the suggestion on bug 24200 to > change the system setting "Group Windows By Application" in the "Desktop and > Dock System Setting" preference pane to true. Same behavior, even after a > restart. And it is happening in both the IDE and in a standalone. The > standalone is built with the Levure framework. In the IDE the issue only > happens *after* I’ve loaded the Levure framework. > --- > Marty Knapp > >> On Apr 27, 2023, at 9:39 AM, Mark Waddingham via use-livecode >> wrote: >> >>> On 2023-04-19 19:25, Marty Knapp via use-livecode wrote: >>> Ever since I updated to Ventura on my Mac I've had this weird behavior both >>> in the IDE and in two different standalones - if I have more than one stack >>> open, when I click on a stack that is behind another stack to bring it to >>> the front, it very briefly comes to the front (flashes), then goes back >>> behind everything, even windows from other apps. If I click on the title >>> bar it does not do this. In the menubar is still indicates that I'm in my >>> app. It's not happening with any non-Livecode apps and it's occurring on >>> two different Macs. I’m not seeing this behavior on OSes previous to >>> Ventura. >>> Am I going crazy? >> >> Do you (or anyone else who has chimed in on this list) have the backdrop >> feature enabled? >> >> The reason I ask is that the behavior you describe is similar to this report >> https://quality.livecode.com/show_bug.cgi?id=24199 (I think at least) - >> which has now reduced to being due to the backdrop - >> https://quality.livecode.com/show_bug.cgi?id=24200. >> >> Warmest Regards, >> >> 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 > > > ___ > 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: Custom property retrieval incorrect
Intriguing - my guess is that something in the message path in your IDEs has a getProp cVersion handler. Now it could be something built into the IDE - although I’m not sure what - or it could be a plug-in or extension. An easy way to find out is to temporarily rename the ‘My LiveCode’ folder and restart the IDE to see if it still happens… Warmest Regards, Mark Sent from my iPhone > On 27 Apr 2023, at 20:51, J. Landman Gay via use-livecode > wrote: > > I have a custom stack property called "cVersion" that is used to determine > update availability and is shown in an About stack. In LC 9.6.7, 9.6.9, and > 10.0.0 dp 5 the custom property is returned incorrectly. > > I set the cVersion of the stack to 3.0.0 in the property inspector and also > tried from the message box and from a handler. In both the message box and in > a script it returns 3.0.9. I saved the stack, quit LC, relaunched and opened > the stack and it then reported 1.0.4. I don't know where these numbers are > coming from. > > There are three substacks but none of them have any custom properties at all. > When I open the stack property inspector it does correctly say "3.0.0". > > I deleted the custom property completely and then re-entered it. It still > says 3.0.9 on a new launch. > > I created a new custom property called "cVers" and it does report 3.0.0 as > specified. Other custom stack properties also retrieve correctly, it is only > this particular one that fails. > > Anyone seen this? Is there something special about a custom prop named > "cVersion"? This used to work fine, but that was about 2 years ago. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Weird window behavior
On 2023-04-19 19:25, Marty Knapp via use-livecode wrote: Ever since I updated to Ventura on my Mac I've had this weird behavior both in the IDE and in two different standalones - if I have more than one stack open, when I click on a stack that is behind another stack to bring it to the front, it very briefly comes to the front (flashes), then goes back behind everything, even windows from other apps. If I click on the title bar it does not do this. In the menubar is still indicates that I'm in my app. It's not happening with any non-Livecode apps and it's occurring on two different Macs. I’m not seeing this behavior on OSes previous to Ventura. Am I going crazy? Do you (or anyone else who has chimed in on this list) have the backdrop feature enabled? The reason I ask is that the behavior you describe is similar to this report https://quality.livecode.com/show_bug.cgi?id=24199 (I think at least) - which has now reduced to being due to the backdrop - https://quality.livecode.com/show_bug.cgi?id=24200. Warmest Regards, 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
Re: Problem using AppleScript of "system events" to click a location on screen
On 2023-04-27 16:42, Ben Rubinstein via use-livecode wrote: Can anyone shed light, either on how to grant the IDE permission to use the Accessibility controls; or on why the applescript wouldn't work? Not immediately - no :) However, three questions... What version of LC are you using? Are you using an Apple architecture mac? If so, is the IDE running under Rosetta, and the standalone native, or vice-versa (or both the same)? -- 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
Re: more then 1 browser widget in a web standalone?
On 2023-04-24 15:46, matthias rebbe via use-livecode wrote: I can now confirm that more than one Browser Widget will work in Web standalones, but not all URLs that work in LC IDE or Desktop standalones will work in Web standalones. For example this one here fails in Web Standalones. https://www.whatismybrowser.com/de/ The web browser widget is implemented as an IFrame - this comes with it a fair amount of security restrictions unless the website being embedded has appropriate cross-origin settings (or comes from the same host as the surrounding page). In this case, I suspect the website is just refusing to be embedded - indeed if you go to: https://www.w3schools.com/html/tryit.asp?filename=tryhtml_iframe_height_width Then change the src to the website above then it won't work there either. Warmest Regards, 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
Re: Android 13?
But building standalones for minimum Android version 13 is not possible, correct? At least only 5 to 12 are currently possible options in the standalone builder. We really need to make that drop-down work out its values from the built engine somehow :) The min-version controls the lowest version of Android the app will install on - not whether it will run. i.e. You don't set to in order to make the app run on (say) Android 13, but to say that it *only* runs on that version. (If you do need to make an app only run on Android 13, for some reason right now, you would need to use a custom manifest) Warmest Regards, 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
Re: Android 13?
On 2023-04-22 20:41, J. Landman Gay via use-livecode wrote: I believe this is an error relating to the target version embedded in the app. Google's policy says that new and updated apps must target an Android API no earlier than 2 versions behind the current one. Since API 33 is current, your app must target at least API 31. Android 14 will be released very soon (in a couple of weeks I think) and any apps submitted after that will need to target API 32+. Note that the target API is not the same as the minimum supported version which can be much lower. Google have now made it so that the effects on appstore submission are on a fixed date each year - August 31st - https://support.google.com/googleplay/android-developer/answer/11926878?hl=en. So the release of Android 14 won't affect the ability to submit apps or updates. We'll update the engine and s/b appropriately by the August deadline though :) LC 9.6.9 targets API 31. I don't think LC 10 has updated the target yet, so 9.6.9 is your best bet. The target API has to be an LC engine update, we can't change it ourselves. So 10-dp-5 includes all (maintenance related changes) in 9.6.9 - so also contains the updates to Android (and iOS) version targets. Warmest Regards, 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
Re: [[ ANN ]] Release 10.0.0 DP-5
On 2023-04-18 20:58, Mark Wieder via use-livecode wrote: I would so like to like this release: script widgets expression constants (finally!) etc... but it's so wonky on linux that I'd have to write up a slew of bug reports. Essentially unusable for me in ways that dp4 behaves. I'm looking forward to dp6. Heh - well if there is a Linux specific issue that we haven't seen but you do - then its not likely to be fixed in dp-6 unless we know what it is :D We've already identified a problem with the 'after' message which causes the layout of the IDE palettes to not update correctly - and are fixing :) Beyond that, do you get (as many) problems if you run the IDE without any plugins and such? (i.e. an empty 'My LiveCode' folder) The reason I ask is that we have (unusually) made two backwards-incompatible script changes in dp-5 in order to accommodate constant initializer expressions - both touch on edge-cases, but hey, edge-cases happen. There is a small possibility that a plugin or similar which contains such an edge case could break and thus be causing errors and thus destabilize the IDE. Specifically: The tokenization of numeric literals (i.e. numbers) is now much more strict - https://quality.livecode.com/show_bug.cgi?id=23653. Previously a numeric token which had an 'error suffix' would encompass the suffix into the token rather than treat it separately. The right-hand side of an initializer is no longer treated as a token (this is key to having them as expressions at all!) - https://quality.livecode.com/show_bug.cgi?id=19413. Previously if you had an initializer which was an engine constant, then the initialized value would be the name of the constant and not its value (e.g. local tFoo = empty => tFoo = "empty" and not ""). The fix to both is to quote the offending token. Warmest Regards, 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
Re: Which sqlite?
On 2023-04-15 12:13, Neville Smythe via use-livecode wrote: Is it possible to direct LC to use a custom version of sqlite3 rather than its default? I ask because the installed version of sqlite which come installed with macOS, and which I assume LC uses when it initialises its database library, is crippled ---arithmetic functions which come with the standard augmentation of sqlite (such as floor(), log() etc) are not enabled, similarly regular expressions are not enabled. It is easy enough to install a more capable version of sqlite on the Mac, but I don’t see a way to get LC to use it. Possibly there is an environment variable or an initialisation handler which can be edited? (Note that Apple goes to some lengths to make it difficult to overwrite the installed sqlite in the system, and such a change would be lost on the next os update anyway.) If LC is using its own built-in sqlite and dylib rather than the os-provided package, then is there a way to update that to one own version? The version of sqlite we use is compiled in to the dbsqlite driver and thus is independent of any installed libraries. We've already got a pending request (https://quality.livecode.com/show_bug.cgi?id=24051) to update it to a newer version so if you just drop a note on there reminding us to enable the math functions and REGEXP extension then we'll enable those at the same time. The update will likely go into the next 9.6 maintenance release (9.6.10), and also appear in a subsequent 10dp. Warmest Regards, 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
Re: 9.6.9 iOS compile error
On 2023-04-14 03:48, Andrew at MidWest Coast Media via use-livecode wrote: When compiling the same app using 9.6.9 and Xcode 14.2, my submissions are getting rejected by Apple when attempting to upload with Transporter: ERROR ITMS-90502: "Invalid Bundle. Your binary, 'com.midwestcoastmedia.link', has a 64-bit architecture slice, so you must include the "arm64" value for the UIRequiredDeviceCapabilities key in your Xcode project. Learn more (https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/uid/TP40009252-SW3).” I’m guessing I could just update the info.plist manually but I was really trying to avoid that long term. So with the move to Xcode14.2 we can no longer build 32-bit slices in iOS so we have had to remove those from the engines in 9.6.9 - however we did miss the fact that currently the S/B will only include the `arm64` capability *if* the min iOS version is 11.0 and above (the arm64 capability is required as there is only a 64-bit slice!). Thus you can either change the min version to 11.0 - or just tweak the revsaveasiosstandalone script - at around line 1771 there is: -- Building for iOS 11.0 or more only builds the 64bit slice, so update the plist if pSettings["ios,minimum version"] >= 11.0 then put "arm64" after it end if Removing the 'if' and making this unconditional will ensure that the arm64 key is always present. Sorry for the inconvenience. Warmest Regards, 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
Re: Unable to load Preferences LC 9.6.9rc3 and Levure 9.0.5
On 2023-04-08 14:58, bob--- via use-livecode wrote: I'm wondering if anyone might be able to help me out. I’m trying to use LC 9.6.9rc3 with an app built with Levure. With LC 9.6.9rc2 I am able to open the app in the IDE with no issue. When I try to open the app with LC 9.6.9rc3 I get “An error occurred while initializing the application [unable to load external Preferences]”. I’m tracing through the Levure script now and can see in fact the Preference stack is not being loaded. I’ve confirmed Preferences.bundle is at the location referenced in the script. Can anyone steer me in a direction for a fix to this? So you'll need to (for now) use `Get Info` on LiveCode.app in Finder, and ask it to 'open in rosetta'... Then when building any standalones, disable generating a the arm64 slice (you can do this in the MacOS pane of standalone settings). The reason is isn't working is that the preferences external included in Levure does not have a ARM64 slice - so won't load when the engine is running using that architecture. The preferences external will need to be rebuilt with an arm64 slice and included in Levure. (When looking at this the other day, I did notice that Levure has an LCB extension which can do preferences stuff on macOS - bypassing the need for an external, but I couldn't see how you opt to use that instead of the external). Warmest Regards, 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
Re: running platform-native by default
On 2023-03-22 19:45, Phil Davis via use-livecode wrote: I'm using LC 9.6.8 to build some macOS Intel/Silicon ("dual-native") apps. Upon first launch of these apps on my Silicon test machine, I always get the OS dialog that says "To open '', you need to install Rosetta. Do you want to install it now?" I always click the "Not Now" button because I want the apps to run native by default, wherever they are running. (I'm avoiding installing Rosetta on that machine.) I discovered I can avoid getting the Rosetta dialog this way: After installation and before first launch, do a "get info" on the installed app. In the macOS Info dialog, check AND uncheck the "Open using Rosetta" checkbox. Close the dialog and now the app will launch in native (Silicon) mode. MY QUESTION: Is there a way to pre-set my apps so their first launch uses the engine that's native to the platform they're installed on? It seems like there ought to be a way. I can't expect all my users to jump through this manual hoop - and it just looks unprofessional to me. Yes - you just need to tweak the plist - there's an LSArchitecturePriority (or similar!) entry which determines the order the slices in the executable are considered. We made x86-64 the primary architecture in 9.6.8 to ensure by default people didn't potentially use an architecture (i.e. arm64) which hadn't been well tested (i.e. making it optin). In 9.6.9-rc-3 (which is, hopefully, imminent!), we'll be removing the experimental tag from the arm64 slice and make the priority the default - i.e. on arm macs LC and its standalones will run using the native (arm64) architecture by default. Warmest Regards, 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
Re: ChatGPT examples
On 2023-01-20 13:05, Alex Tweedly via use-livecode wrote: We need a better algorithm. If we use a "linear scan", we can change it from essentially Order(N**2) to approx Order(N). Slightly pedantic point (I appreciate that you did say 'approx')... Sorting can not be done in any less time than O(N*log N) - so the revised algorithm is O(N*log N) as you have to sort the input for it to be able to scan linearly. :D Warmest Regards, 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
Re: Standalone riddle
On 2023-01-17 21:39, J. Landman Gay via use-livecode wrote: That's true, but is there a way to avoid including the remote debugger in a test app when the device is cabled to the computer? I think you just need to ensure 'Script Debug Mode' is turned off before clicking Test. (The remote debugger adds and removes itself from an internal list of things to include when using test as the preference/option changes). Warmest Regards, 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
Re: Lock screen and animated gif
On 2022-12-20 18:27, Paul Dupuis via use-livecode wrote: If someone switches to another applications (so a suspendStack is executes and does the currently executing script get suspended?) and then back to a different window/stack, could that also change the defaultStack for the currently executing script when it resumes? It's just another real=world user behavior we see with people using our research tool. No that shouldn't affect things - the way the engine calls handlers responding to an event is such that the defaultStack will always be restored to what it was before the handler is called. The way pending messages are dispatched is such that it will only restore the defautlStack if it is the same as the stack it was when the handler was entered. 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: Lock screen and animated gif
t changing (even rather esoteric?) semantics of things which have been that way for as long as time has a huge risk of breaking existing code... Advice: So, anyway, regardless of whether the current behavior is correct/incorrect/desirable/undesirable or whatever, it is what it is and has been that way (I think at least!) forever - the problem that this lengthy post describes can be completely mitigated by ensuring you always reset the defaultStack on exit of handlers which are called in time - i.e. like the _mouseUp handler above - with the restoration of the defaultStack at the end. Warmest Regards, Mark. P.S. Sometimes evaluating whether long standing behavior should be changed is really hard and is always a balance between whether it is at all likely to break *any* existing code (and if so, how much), and the benefit of the change will bring. However, in this case, I *think* (but do need to consider more) that the chance of it breaking existing code is virtually zero, and the chance of it fixing really hard to track down 'seemingly non-deterministic' bugs in existing code is quite high. Why? In order for existing code to *rely* on the current behavior would require these things to be true: 1) the app in question would need to use nested, dispatching wait loops 2) the app in question would need to use pending messages which explicitly change the defaultStack and not change it back 3) the app would have to have been written such that there were instances of wait with messages, with code following them which explicitly relied on a pending message which changed the defaultStack explicitly to have been run So the number of app using (1) is probably actually quite high - some engine syntax uses nested dispatching waits, and its common to do that in any script which is long running and wants to provide progress updates without the displaying the progress updates taking far longer than the process it is showing progress for. The number of apps doing (2) is hard to assess - having to change the defaultStack explicitly is needed, but how often is another question. However, I'd probably guess that most handlers which do set it explicitly and called as pending message do not - as its not obvious that you need to (due to the not ideal current behavior of pending messags) - so this case is probably reasonable common too. So that leaves (3) - which I struggle to even begin to imagine ever existing! After all the only guarantee with pending messages is that they will be sent as close to the requested time as possible - so for code to explicitly rely on a pending message being dispatched at a specific 'wait for messages' would be so tied to timings of things as to be so fragile that I can't see such code surviving as a 'good idea' for long in the course of an app being built. Of course, there's always the mantra of 'famous last words'... -- 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: [OT} Sunsetting Atom Editor 12/15/2022
On 2022-12-08 18:30, Mike Kerner via use-livecode wrote: mark - what have you fond compelling about vscode? i have never really liked it Three immediate things: 1) it has a terminal pane 2) its find in all files is a right hand tree view and is updated live 3) there is a C/C++ extension which uses Microsoft's Intellisense tech Most of my work involves a combination of LiveCode Script and C/C++, and unit tests - the latter being entirely terminal based. Therefore having it all in one window is a huge efficiency improvement (although it has taken me about a month to *stop* clicking in the dock on terminal, or alt-tabbing to it when I want to run things!). The intellisense stuff and live right hand find in files is much better for navigating large code bases too :) Admittedly I'm probably a very special-case on this list (in terms of doing both C/C++ and LCS dev side by side, mostly to be run from terminal). However, I think VSCode definitely has the edge if you are doing LiveCode scripting in script-only-stacks to use server-side/in lc-server from the terminal due to the integrated command-line... There's also a host of other integrations with online services for development through terminal stuff - e.g. stripe comes to mind. If you are doing LiveCode scripting in concert with the IDE / GUI type stuff - then VSCode vs something else pretty much comes down to personal taste :) 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: Crash on launching LC server version > 9.6.7 using terminal
Hi Ralf, have any of you ever experienced that a version of LC Server newer than 9.6.7 crashes on launching using hashbangs? This is the case for me on a MacBook Pro M1 running macOS Monterey 12.6. Oh! I thought it was something that had changed in recent macOS Monterey versions, rather than something we had changed on our end... Intriguing... I suspect this is related to incorrect code signing, as the crash report shows that the kernel sends the exception "Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))". Unsigned LC versions (LC server version < 9.6.8) are not affected. It would be nice if someone had a recipe to solve the issue. See this forum post for details of how to resolve: https://forums.livecode.com/viewtopic.php?f=9&t=37437 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: [OT} Sunsetting Atom Editor 12/15/2022
On 2022-12-06 19:15, Ralph DiMola via use-livecode wrote: I was wondering what editor the LC community is migrating to? I like Atom with the LCS and LCB packages. I've recently migrated to VSCode (albeit from Sublime Text, rather than Atom) - I have not looked back :) 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: RANT (Mild): revZIP library
On 2022-10-11 20:37, Paul Dupuis via use-livecode wrote: We just got bit by a 4+ year old bug (See https://quality.livecode.com/show_bug.cgi?id=20859) where the revZIP library on macOS can create and read ZIP archives over 2GB, BUT the Windows library can not. Do you ship your app as a 64-bit windows exe? I wonder if its just a limitation of the library we use when compiled for 32-bit archs... 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: PDF Printing
On 2022-10-04 16:20, Dan Friedman via use-livecode wrote: Here are examples of the printouts (the PDFs): Print to PDF - https://www.clearvisiontech.com/WORKING/PrintToPDF1.pdf Print to Printer - https://www.clearvisiontech.com/WORKING/PrintToPDF2.pdf Any thoughts or ideas? Someone had a similar problem in the past (Paul or Klaus maybe?) - it turned out that it was because no explicit font was set on the stack (or controls) - meaning that it was using the macOS 'theme' font. This isn't actually a 'discoverable' font in the various font related APIs - and appears to be (somewhat!) hard-coded in the various low-level Apple graphics rendering APIs. The PDF printer does use the correct fonts and metrics - and CoreText (on macOS) to do font layout - but the actual PDF generation is done using a cross-platform library (so the output is the same on all platforms) which relies on getting the 'real' font data for the given font (which it does not in this case) and not macOS (CoreGraphics-based) printing. The latter appears to be able to deal with the 'magic' fonts (unsurprising as its all Apple stuff), but our pdf printer cannot. If you set the stack to an explicit font then the problem should go away. Alternatively, if this is a mac-only product, you can use macOS's PDF printing capability by setting the printerOutput property to "file:" - on macOS the latter will generate a PDF (i.e. its the same as choosing 'Save As PDF' from the printer dialog). Hope this helps! 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: LC converts phone number to scientific notation
On 2022-09-09 11:40, Klaus major-k via use-livecode wrote: Hi Panos, Am 09.09.2022 um 12:27 schrieb panagiotis m via use-livecode : Hello Klaus, I guess what happens here is that if you fetch item X of line Y and use it directly, LC treats it as a number and displays it in scientific notation. obviously! Panos isn't correct here... None of the code you posted would cause a string to be converted to a number - the engine only does that when you pass a string to something which expects a number (and returns one). Specifically the 'item' chunk is a string chunk - it just manipulates fetches or stores sequences of characters into other sequences of characters. So the problem you are having is elsewhere - and not in the code which reorders the strings of the lines you have imported. It is either happening when you import the data, or when you are displaying it. Indeed, LCS doesn't use scientific notation when converting numbers to strings implicitly - you need to use `format()` to get numbers in that string form. However, LCB *does* use scientific format when converting numbers to strings (currently at least - we've got an item on the todo list to improve that behavior). For example, the variable viewer in the SE is a treeview widget, so if a variable holds a number that will display in scientific notation if it has above a certain number of significant digits. 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: Livecode SQLite
On 2022-08-11 16:16, Tom Glod via use-livecode wrote: I was interested in implementing a relatively new feature where you can index and query json documents and read the keys directly. https://dgl.cx/2020/06/sqlite-json-support I guess, if this is true, is there any documentation about which features of sqlite are implemented and which are not? The version of SQLite is currently 3.34 built with FTS3, FTS3_PARANTHESIS, FTS4, FTS5, RTREE and JSON1 options. So the JSON features (at least as far as those included in 3.34) should be included - perhaps the queries you are trying rely on features (perhaps not JSON related) included in more recent versions? If you file a bug report with what examples of what isn't working, then we'll look into updating to the latest version of the library. 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: Tree Widget: hilitedValue?
On 2022-07-10 21:33, Richard Gaskin via use-livecode wrote: Brian Milby wrote: You could also turn the path into an array (but lose the error checking above): function getValue pArray, pPath split pPath by comma return pArray[pPath] end getValue Thanks, Brian. I keep forgetting we can use an array as an element specifier. Has that been around the whole time, or was it added in recent years? I added it before 6.0 - probably in 4.5 or 5. 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
On API keys...
r - this means you need to set up server side scripts which your app then talks to via a suitable protocol (e.g. HTTP / REST) to perform the operations which use it. The key must never be sent over the wire between your app and the server as this could be intercepted by someone who is using your app locally. BEST PRACTICE FOR APPS WHICH REQUIRE USER LOGIN Of course, the most secure way to use API keys of all types is to have them only ever on a server - however, this is only really suitable if your app is 'always online' and you can do all operations on the server - many services this doesn't work, e.g. Google Maps. However, there is a reasonable middle ground which offers a little more security (and convenience, in the case of compromise!). If your app can only be used by a user *after* they login locally then the best practice for type 1 and type 2 keys (as mentioned previously type 3 keys must NEVER leave your server!) is to not store the keys in the deployed app at all. Instead, once the user has successfully authenticated have the server send the API keys the app needs to use. You can either do this once per session, or if your app allows 'offline' use as long as they have signed in before (on mobile) you can use something like the 'secureKey' library to store them in the mobile devices 'trusted' store. This approach has two main benefits: 1) The API keys are never actually in a file someone can sit and dissect at will (even obfuscated, there are some very persistent bad actors out there!) 2) If your API key is compromised (or you do need to change it, for whatever reason) you can do so without having to have everyone install an app update with the new one in. Anyway, that's probably more than Tom probably needed to know (or perhaps knew already), but hopefully it is helpful (at least for those who have to deal with API keys and such things!). 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: {OT} Are there any ffmpeg "experts" on this list?
On 2022-06-24 17:05, Paul Dupuis via use-livecode wrote: I was unaware of the mediaFoundation library - I had thought that we'd not see support under LiveCode 10 switches from DirectShow to MediaFoundation. Its actually been buried in the product (business/pro features) for a long time - I had forgotten about it until relatively recently... That said, our application is macOS and Windows and the appeal of ffmpeg via shell is that the same code will work across platforms for us. FWIW, I *think* mergAV can do similar things on macOS* to the mediafoundation external on Windows - although the APIs, while similar, do require different code. However, if you are using ffmpeg for things other than concatenating tracks/movies (i.e. the features those libraries provide) then the separate code needed wouldn't be worth it to save inclusion of ffmpeg. 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: How to color a "cell"?
On 2022-06-23 23:54, Richard Gaskin via use-livecode wrote: Thanks Mark - works. I could have sworn I'd tried "line" earlier when attempting to set the backgroundColor, and when it failed was when I switched to trying "paragraph". But it works now so I don't mind being mistaken. Oddly, "paragraph" appears to be synonymous with "line" for the borderWidth, borderColor, firstIndent, leftIndent, textAlign, spaceAbove, hGrid, vGrid, and tabs paragraph properties. I suspect you have dontWrap set and possibly 'table-mode'. Near as I can tell backgroundColor is the only paragraph properties where the "paragraph" chunk type isn't synonymous. If you check the htmlText you can easily see the difference between using 'paragraph' and 'line' to set the aforementioned properties. When set on 'line' - the properties appear on the 'p' tags, and they have an effect on a per (wrapped) paragraph basis. When set on *all other string chunks* (which reduce to char chunks) - the properties appear as runs in the 'p' tags, and they have an effect on runs of text. 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: How to color a "cell"?
IIRC you need to use ‘line’ to set ‘paragraph‘ properties of fields… Sent from my iPhone > On 23 Jun 2022, at 19:29, Richard Gaskin via use-livecode > wrote: > > Craig wrote: > > > Richard wrote: > >> I had hoped the paragraph-level formatting options introduced in > >> v5.x would help, but alas as far as I can tell I can only set the > >> backgroundColor of a run of text, not the full cell. > > > > I think this was discussed on the forum a while back. I do not believe > > you can do what you want without another control overlying the “rect” > > of the “cell”. > > Thanks. I could get away with setting the backgroundColor of the whole line, > but that does the same as setting the backgroundColor of a "cell": it draws > the color only beneath the portion of the line that contains text, leaving > the rest blank. > > The borderWidth and borderColor paragraph properties work as expected, > affecting the full line whether it's filled with text or has no text at all. > > But backgroundColor as a paragraph setting feels broken, as it works the same > as setting that property for a chunk rather than for the field. > > From the v5.5.4 Release Notes: > > - The backgroundColor property allows the color of the content area > (inside any paragraph border) to be filled (note that strictly > speaking this property is not inherited, but the effect is the same > as if it was as the background of the field is rendered before the > paragraphs are so the background color at the field level will > ‘show through’ to the paragraph if the paragraph has no background > color). > > - The borderWidth property determines the width of the border to draw > around the paragraph. > > Pretty much all the other paragraph-level formatting options work just their > their field-level counterparts, but of course limited to the specified > paragraph. > > So I'm surprised the backgroundColor was added in such a way that it appears > to do nothing we didn't already have with setting backgroundColor of chunks. > > I was hoping I was just using it wrong. > > Here's how I set it in my tests: > >set the backgroundcolor of paragraph 2 of fld 1 to yellow > > Unless there's a different syntax I should be using, it would appear the > paragraph-level implementation of backgroundColor is unfinished, no? > > > -- > 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 ___ 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: M1 Macs and LC 9.6.8 RCs and 10.0.0 RCs
On 2022-06-21 12:18, matthias rebbe via use-livecode wrote: Am 21.06.2022 um 11:56 schrieb Mark Waddingham via use-livecode : Why? First, it's more convenient for the developer. I think the end user is more important (in this case) ;) The Intel only and Apple only builds are smaller ins size than the universal build. True - universal builds are double the size essentially (well, resources in copy files are *not* duplicated) - however how important is that really? There's a high chance a user might download an app twice from a page offering two architectures - because they aren't necessarily sure which one they need - at which point, you've lost any advantage in splitting them (and just caused user consternation). [ Similar argument holds when users upgrade their machines, and restore from a full backup - which is what the majority of users do ]. Besides, if size is a real concern here then there are a couple of tweaks we could do to reduce the size of universal binaries (and indeed, Android APKs) which would see the size difference between universal and non-universal drop to maybe 3-4Mb (and probably only 1-2Mb when compressed - i.e. transmission size). [ This would be a *much* better use of time, than adding an edge-case option to the S/B, IMHO ]. So if i want to build those single platform apps to offer the smaller sized apps i have to run the standalone building process twice, right? And before i run the 2nd build process i even have to switch the settings, right? That's not very convenient. Offering two separate downloads to users is not very convenient to them ;) And btw why did this option exist in previous LC versions for an Universal app with PPC and Intel support? Well that was getting on for a decade ago - so can't really remember what the exact rationale was back then. However, I dimly recall that universal PPC+Intel binaries would not run on some earlier versions of 'MacOS X' which we still supported (and people still had!) at the time - so you actually *needed* to offer a separate PPC download if you still needed to support those really old 'MacOS X' versions. These days that's not a problem as there's been a 32-bit -> 64-bit architecture switch since then which means all the macOS versions we currently support work correctly with universal binaries containing slices the OS does not understand. 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: M1 Macs and LC 9.6.8 RCs and 10.0.0 RCs
On 2022-06-20 20:55, matthias rebbe via use-livecode wrote: Anyway, the macOS Apple support is currently experimental, i am pretty sure there will be such an option in future. At least i hope so. ;) Why? The idea of universal binaries is to ensure that a single app/installer can be shipped to users and that will then use the 'best' it can for their machine. They provide a much better end-user experience than Windows or Linux provide in this regard. Whilst you might not have many users using Apple architecture machines right now, you don't know when they might upgrade, so universal binaries mean that when a user upgrades their machine, their apps they already have (backed up, more than likely, and re-imaged on the new machine) will continue to take advantage of their hardware. Warmest Regards, Mark. P.S. I should point out that Apple architecture support *is* experimental, so its fine to include and seed to users for testing purposes, but I wouldn't include one in final shipping releases just yet. P.P.S. That being said, the only Apple architecture related bug we have had reported recently is related to standalone building itself (and is related to macOS High Sierra - 10.13 - and below *not* supported arm64 slices in some of the command-line tools the S/B uses) - and I fully expect the experimental tag to be removed by final release of 10 (and the corresponding 9.6.x maintenance release just after that). -- 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: M1 Macs and LC 9.6.8 RCs and 10.0.0 RCs
On 2022-06-18 21:27, matthias rebbe via use-livecode wrote: So, the question now is, is this a macOS problem or is it possible that a standalone could show the wrong setting due to a wrong configuration or so when it is created. It is a macOS (Finder) bug - I think it was the same when they added 32-bit vs 64-bit, and probably Intel vs PowerPC. There's a plist entry 'LSArchitecturePriority' which is the order in which the different slices should be used - currently we have x86-64 then arm64 and it seems the Finder doesn't use this to determine whether to show the Rosetta box as checked or not when the user hasn't explicitly prodded it in the past (which obviously they won't have done for new apps / those which didn't have the option before!). 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: char as word boundary
Hi Jean-Jacques, On 2022-06-03 14:56, Jean-Jacques Wagner via use-livecode wrote: Hi, Version 6.7word boudary are char number 09,10,11,12,13,32 version 9.67 word boudary are char number 09,10,11,12,13,32,202 Hypercard and livecode 6.7: the number of chars (numtochar(32)& numtochar(202)&numtochar(32)& numtochar(202)&numtochar(32)) = 2 livecode 9.67 : the number of chars (numtochar(32)& numtochar(202)&numtochar(32)& numtochar(202)&numtochar(32)) = 0 Is it a change or a bug considering now numtochar(202) as word boundary, as it is with numtochar(32) This is something we will need to consider - please do file a bug about it at quality.livecode.com (so you can track any further discussion about it). I can see how this change occurred, and it is perhaps more a 'side-effect of implementation' rather than an intended change. Prior to 7.0 - the word chunk used the C library 'ctype' isspace function - which returns true if a character is 'whitespace'. However, the engine *also* tweaked the C library character tables to make it so that NBSP (202 on MacRoman - something else on Windows/Linux - 160 maybe?) was *not* a space character. This was primarily a very dirty hack (which was done before my time!) to allow non-breaking spaces to prevent word breaks in fields (I strongly suspect the effect on the word chunk was never considered!). When we moved to Unicode - we changed the word-breaking detection in fields to use a simplified version of the Unicode algorithm and Unicode character properties (NBSP has the, unsurprisingly, no-break property!). Similarly, we changed the word chunk to use the Unicode 'whitespace' property. In the unicode world - being whitespace, and non-breaking are two separate properties... Hence the difference in behavior since 7. The reason this is 'of interest' is that the word chunk has had quite a hefty performance regression since 7.0 due to the switch to Unicode, so re-looking at what it should *actually* do (taking into account what it would be most useful in the widest possible circumstances) is definitely on the cards. 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: Would anyone miss convertOctals?
On 2022-06-09 20:54, Craig Newman via use-livecode wrote: Mark. Gong the other way, is your task made much simpler by losing “converOctals”? I assume so, or the issue would never have come up. Are there other similar language elements that also are on the block? I'm not sure it makes things 'much simpler' - but it does remove one thing to have to think about. Further it removes a case where script is ambiguous at parse-time - i.e. the token 0123 could mean one of two different things depending on a runtime property. Given the responses so far, it looks to me like convertOctals is an exceptionally rarely used feature (the number of years of LC experience amongst those who have responded is in excess of two centuries, and >80% of the respondents didn't know what the property was). Thus any added complexity caused by having this feature seems a waste of time/effort/mind-space - particularly as there is a more-than-adequate replacement which has none of its problems (i.e. 0o123) - and moreover one which other languages (e.g. JS) adopted a long time ago. In terms of other things which are 'on the block' - then no explicit features per-se but there are a couple of extreme 'edge cases' which will likely be removed. For example, the ability to use 'msg' (which is aliased to the content of the message box) and '$' implicit variables as referenced parameters in handlers. Currently you can do: on mouseUp fillVars msg, $FOOBAR end mouseUp on fillVars @pA, @pB put "foo" into pA put "bar" into pB end fillVars The ability to pass these 'quasi-variables' as references will potentially reduce the potential performance gains of moving to a bytecode-based VM when referenced parameters are used in general, and thus (like convertOctals) their existence seems too high a price to pay for what is almost certainly a rarely used (if used at all) feature. Note: I should stress that the above is *just* removing the ability to pass 'msg' and environment variable globals as reference parameters to handlers *not* removing 'msg' or environment variables in general! 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: Would anyone miss convertOctals?
On 2022-06-09 16:33, Devin Asay via use-livecode wrote: Wait, you said three questions. But no. What are those two hard problems of computer science again? ;) -- 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
Would anyone miss convertOctals?
So I'm currently sitting here about to embark on fixing <https://quality.livecode.com/show_bug.cgi?id=23653> (which is the final thing to sort out before being able to merge my constant expression patch) and I was reminded of 'convertOctals'. Now, generally, I am somewhat averse to actually removing any language feature (even those we have deprecated, unless we absolutely have to!) - however, I would really like to make convertOctals have no effect at all in 10.0+ as it adds a disproportionate amount of complexity compared to (what I think, at least) its utility is (particularly in the context of things 'coming next' like the script compiler). So three questions: 1) Do you know what convertOctals is, and what it does? 2) If you do, have you ever actually used it in any scripts which are actually still in use? 3) If you do use it in any scripts which are still in use, would you be willing to change them to not use it? 4) If you do use/have used it, had you ever noticed that it has been slightly broken for years? Now, its always better to offer a carrot when there is a stick (or in this case, an axe) being wielded and the carrot in this case would be to expand the numeric literal syntax to add both explicit octal and binary number literals alongside hexadecimal: 0xabcdef - hex literal 0o777 - octal literal 0b101110101 The key difference between 0o777 and using 0777 (with convertOctals true) is that the former is not ambiguous at parse time, it doesn't require a runtime property set to true in order for the engine to convert the string to a number correctly. Please let me know your thoughts :) Warmest Regards, Mark. P.S. In the scheme of 'breaking changes' - we've already made a number of them for 10 already, and my gut tells me removing convertOctals is likely to cause less consternation than those we already have - but I could be wrong! -- 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: Generating Random numbers to conform a distribution
On 2022-06-07 21:51, David V Glasgow via use-livecode wrote: Quite a lot of stats and maths packages offer a feature whereby the N, the Mean and the SD are variables specified by the user, and N random numbers are then generated with the required mean and SD. I remember the venerable and excellent Hypercard HyperStat <https://link.springer.com/content/pdf/10.3758/BF03204668.pdf> (1993) by David M Lane doing exactly that. Or is there an elegant formula? I have Googled about and can’t see one, but maybe I don’t know the magic words. And if someone wanted to script this in LC what would be the best approach? (just general guidance here, wouldn’t want anyone to invest their valuable time in what is at present just vague musings) Any hints from the stats gurus? I'm not a stats guru but... I think all you need to do here is to use some of the intrinsic 'properties' of the Mean and SD. Lets say you have a collection X of numbers then the following things are always true: P1: Mean(c * X) = c * Mean(X) P2: Mean(X + k) = k + Mean(X) P3: SD(c * X) = abs(c) * SD(X) P4: SD(X + k) = SD(X) In English, scaling a set of numbers scales their mean by the same amount, and offsetting a set of numbers offsets their mean by the same amount, Similarly, scaling a set of numbers scales their SD by the same amount, and offsetting a set of numbers makes no difference to the SD (as the SD is a relative quantity - it cares about distance from the mean, not magnitude). Now, hopefully we can agree that if you generate a set of a random numbers, then scaling and offsetting them still uniformly does not reduce the randomness (randomness means the numbers form a uniform distribution over the range of generation, if you scale and offset then all you are doing is changing the range - not the distribution). So with this in mind, let TMean and TSD be the target mean and target SD. Then: 1. Generate N random numbers in the range [0, 1] - S0, ..., SN 2. Compute SMean := Mean(S0, ..., SN) 3. Compute SSD := SD(S0, ..., SN) Now we take a small diversion from a sequence of enumerated steps to ask "what offset and scale do we need to apply to the set of numbers so that we get TMean and TSD, rather than SMean and SSD?". The amount we need to scale by is mandated by the SD, specifically: c := TSD/SSD If we scale our source numbers by c and apply SD then we see: SD(c * S0, ..., c * SN) = c * SD(S0, ..., SN) [P3 above] = c * SSD = TSD / SSD * SSD = TSD i.e. Our scaled input numbers give us the desired SD! So now we just need to play the same 'game' with the Mean. We have: Mean(c * S0, ..., c * SN) = c * Mean(S0, ..., SN) = c * SMean However we really want a mean of TMean so define: k := TMean - c * SMean Then if we translate our (scaled!) source numbers by k and apply Mean then we see: Mean(c * S0 + k, ..., c * SN + k) = c * Mean(S0, ..., SN) + k [P1 and P2 above] = c * SMean + k = c * SMean + TMean - c * SMean = TMean i.e. Our scaled and offset input numbers give us the desired Mean! Note that SD is invariant under offsetting (P4) so SD(c * S0 + k, ..., c * SN + k) = SD(c * S0, ... c * SN) = TSD! We can now return to our sequence of steps: 4. Compute c := TSD/SSD 5. Compute k := TMean - c * SMean 6. Compute the target random numbers, Tn := c * Sn + k So, assuming my maths is correct above T0, ..., TN, will be still be 'random' (for some suitable definition of random), but have Mean of TMean and SD of TSD as desired. In LiveCode Script, the above is something like: function randomNumbers pN, pTMean, pTSD local tSource repeat pN times put random(2^31) & comma after tSource end repeat local tSMean, tSSD put average(tSource) into tSMean put stdDev(tSource) into tSSD local tC, tK put pTSD / pSSD into tC put pTMean - tC * tSMean into tK local tTarget repeat for each item tS in tSource put tC * tS + tK & comma after tTarget end repeat return tTarget end randomNumbers Hope this helps! 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: Case sensitivity in Livecode ??
ntax 'X := Y' is to use the syntax 'put X into Y'" Or telling someone learning Java that: "The workaround for defining a global function is to make it a static method of some class" The point being that how you do things in different languages is different... xTalks don't have a concept of 'global constant' because the language and runtime model isn't one which really supports such a thing (as it stands) - however if you need a constant available globally then leverage a function in the message path to do so. Java doesn't have the concept of a 'global function' because it is a pure class-based language - however if you do need a global function, then you can just make a static method in a class. Neither of these things are 'workarounds' - they are how you do things in that language! FWIW, I'm not entirely sure whether what you (Mark) want from 'global constants' is quite the same as what Alex wants from 'global constants', and I'm not entirely sure whether what I *think* you both mean when you ask for 'global constants' is what you are actually thinking of when you ask for 'global constants'... In that vein, what would be helpful is, instead of just going 'can we have global constants', propose problems you need to solve / would like to solve and use-cases you have encountered where the existing xTalky feature set is not sufficient to solve it in some reasonably elegant fashion without 'global constants'.* Warmest Regards, Mark. * I potentially have use-cases for non-script-local constants, but I don't have any for 'global variable'-like 'global constants' which aren't expressible with existing xTalk notions - hence why my request to 'put up or shut up' ;) --- 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: Case sensitivity in Livecode ??
On 2022-06-01 19:54, Alex Tweedly via use-livecode wrote: Also, you'll be able to do things like: constant kPiBy2 = pi / 2 constant kPiBy2Squared = kPiBy2 * kPiBy2 constant kPiBy2String = format("%f", kPiBy2) local sPiMap = { "pi-by-2": kPiBy2, "pi-by-2-sq": kPiBy2Squared } Very good. In fact, great !! Thank you! Would you be ale to do something like constant kPiMap = { ... as above ... } Yes - the initializers in both constant and local keywords are the same - both can use arbitrary constant expressions (any local properties are assumed to be the default values when evaluating). And now I'll push my luck and ponder the possibility of 'global' constants. Haha... OK - 'global constant' is likely counter to the scope concepts. But perhaps they could be done as "write-once" variables, or as a more general "write-protected' variable. put 17 into gkMyMagicValue writeprotect "gkMyMagicValue" and any *subsequent* attempt to change the value would fail. How is that any better than putting something like this in a library or back script: function gkMyMagicValue return 17 end gkMyMagicValue Including the global declaration its the same number of lines (indeed less, as you'd need to put a global declaration in every script which wanted to use said global constant...). 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: Reporting Apple Silicon anomalies (Re: [[ ANN ]] Release 9.6.8 RC-1)
On 2022-06-06 15:50, Ben Rubinstein via use-livecode wrote: This is very exciting, thank you. If we find anomalies in the Apple Silicon side, should we raise them in the first instance - to you directly? - on this list? - straight into LQCC? Just file a bug in the LQCC - indicating that the discrepancy is between Apple and Intel architectures :) 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: Case sensitivity in Livecode ??
On 2022-06-01 17:44, Alex Tweedly via use-livecode wrote: I was surprised to find that constant K = TRUE produces an error, though constant K = true is fine. In other contexts, you can say put TRUE into myVar put true into hisVar etc. but in a constant statement, it seems to be case sensitive. Anyone got an interesting story (or theory) on why ? :-) Its a small mitigation of https://quality.livecode.com/show_bug.cgi?id=19413 - i.e. where the initializer of constants (and locals) is currently treated as a single literal. In explicitVariables mode, unquoted literals are allowed on the RHS only if the literal is a (builtin) constant *and* the constants value is identical to the token you have provided. That extra check is there to ensure that the constants (and initializers) you have used are actually what you intended. Currently - the following does not do what you think: constant kEmptyString = empty Indeed, this isn't allowed in explicitVariables mode, as the constant empty's value is "" and not "empty" - which is what kEmptyString will actually be with explicitVariables turned off. Anyway, this rather odd and obscure facet of the language will disappear in 10 as we've made it so that initializers for constants and locals can be constant expressions. Thus: constant kTrue = TRUE local sEmptyString = empty Will do precisely what they look like they should do... Also, you'll be able to do things like: constant kPiBy2 = pi / 2 constant kPiBy2Squared = kPiBy2 * kPiBy2 constant kPiBy2String = format("%f", kPiBy2) local sPiMap = { "pi-by-2": kPiBy2, "pi-by-2-sq": kPiBy2Squared } Warmest Regards, Mark. P.S. Amusingly, your question came up on exactly the same day I 'finished' my patch for the above - it now awaits review which may result in it not being quite finished ;) -- 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: Set HTMLText and Get Effective HTMLText
On 2022-05-18 17:43, Rick Harrison via use-livecode wrote: I wish it worked with variables though because execution would be faster. If variables could manipulate styled text (aka htmlText) then they wouldn't be any faster than fields ;) 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: drawingSvgCompileIcon(pIconName) always BLACK
On 2022-04-06 18:16, Klaus major-k via use-livecode wrote: Hi all, so sorry, looks like I completely f. up here. Sorry for the confusion, not may day... See: <https://quality.livecode.com/show_bug.cgi?id=23665> Hehe - no worries. So in answer to your original query about wanting to be able to color the icons - the drawing library supports the 'currentColor' attribute in SVG - and this is tied to the 'backgroundColor' property of the image object the drawing is set on. It would only take a small tweak to Brian's extension to make this work - adding `fill="currentColor"` to the path node it generates. Brian's extension works by fetching the path data from the IconSVG library, wrapping it in the necessary SVG XML, and then compiling it with drawingSvgCompile. Irksomely, there does not seem to be any support for marking colors in SVGs as 'currentColor' in any SVG editor we've come across (unless its deeply buried in it). So one strategy there is making sure the colors you want to be configurable in the SVG are set to a known unlikely random color (e.g. #ABCDEF), exporting as SVG XML from the editor and then just doing a global find/replace of (e.g.) #ABCDEF with currentColor. 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: Weird Standalone Builder issue
On 2022-03-24 21:07, Paul Dupuis via use-livecode wrote: I'm on Windows 10, using LC 9.6.6, and building for macOS and Windows ... This is not a problem form me as I can use revDeleteFolder to remove Contents\Resources\_MacOS\Utilities\ on the mac build and revDeleteFile to remove "ffmepeg" from the Utilities folder on Windows and I am left with the right utility for the right platform. I could also just copy the utilities from the project folder each build during the "on standaloneSaved" message handler. I am mostly curious as to why the Standalone Builder splits the files/folder for macOS and leaves them together for Windows? So this is by design although its been so many years since this was done my memory is a little hazy! I think the evolution of this was as follows: - originally copy files were put next to the executable (i.e. Contents/MacOS on macOS) - Apple made that path read-only and things had to be put in .app/Contents/Resources - the s/b started doing that, but we added internal redirects to the low-level file functions in the engine so code wouldn't see a difference - Apple then made it so that Apple executables could not be launched from anywhere except from Contents/MacOS - so we made it so the s/b sniffed the header of all files copied for Mach-O files and left those in Contents/MacOS Basically, we've tried to make changes to Apple's structuring requirements transparent to developers all the way along - and its worked fine up until now, but admittedly looks a little strange if you dig around into things! I've been pondering whether we should ditch the mechanism soon though: - remove the magic redirection - require code to use specialFolderPath("resources") to find non-executable resources - require code to use (a new) specialFolderPath("executable resources") to find executable resources (which would only be different to the above on macOS systems) - keep the magic sniffing of files in the S/B so executables still go in Contents/MacOS This may break some really old code - but would remove some rather fiddly code in the engine which does the magical redirection - and mean things would be structured as expected (with the new definition of expected). FWIW, even with the above you would still have to branch code to do what you want as the macOS exes would be in a different place (because they need to be!) so it wouldn't resolve that - but at least you wouldn't have been 'surprised' by what you found! 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: debugging javascript in html5
On 2022-03-18 10:44, Bernard Devlin via use-livecode wrote: Considering the html5 enhancements might well be the biggest thing in LC 10, I can foresee a whole world of pain when it comes to us debugging Javascript interactions. Yes - this is somewhat painful at present - and we do hope to make debugging web standalones in general less painful in time. However, if you 'Test' your web standalone in a browser you can then open up the Developer Tools for the browser you are testing in - which gives you access to the JS console and all the other tools. In JS you can use `console.log(...);` to have messages emitted to the JS console. Additionally, I *think* you can use `debugger;` to have JS code break into the debugger in said browser's developer tools. I must confess I've not tried this myself (as our debugging is usually debugging the engine running in the browser, rather than debugging JS executed from the engine running the browser) - but I can't see why it wouldn't work. 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: debugging javascript in html5
On 2022-03-18 11:19, Bernard Devlin via use-livecode wrote: Here's a peculiarity I haven't seen mentioned before. I am trying to test the viability of the idea of a function to call back to LC and provide debugging info. Assume you create a LC function lclog(pmsg,pval) and you put a breakpoint in the IDE inside that function body. Set the htmltext of a browser widget to the code below, set the javascriptHandlers of the browser to contain the word: lclog . Your browser widget will have a button 'clickme'. 1) On clicking that button the JS alerts ALL trigger first. 2) After they have fired the first call to lclog() runs, and the second call to lclog() never runs. function lcxhr(method, url) { alert('lcxhr called'); var json = JSON.stringify({ name: "John", surname: "Smith"}); liveCode.lclog('json created', json); alert('you see this alert before the above call to lclog()'); liveCode.lclog('exit js function',''); } So this is quite separate from what happens in the web engine which works very differently. Embeddable browsers are inherently asynchronous in their execution (not necessarily in a multi-thready way, although that does play a part) - but more in the sense that you can't get an embedded browser to do anything and have it 'block' until it is done. The converse is also true - the request to call an LC handler from the browser widget is basically a post - not a send - which means that (really) you can only call LC handlers as tail calls - i.e. as the last thing on a handler. Warmest Regards, Mark. P.S. The web engine is (essentially) the running the LC script 'as JavaScript' so the same limitation does not apply - calling LC handlers from JS in the web engine is synchronous. -- 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: 10.0.0-dp-2 html5 and liburlLastRHHeaders()
On 2022-03-17 13:07, Bernard Devlin via use-livecode wrote: So there is something else going on between LC's libUrlLastRHHeaders() and LC's interaction with the JS XMLHttpRequest(). This something is stripping out most of the headers. As I said, LC is not stripping anything - we are returning what JS returns. However, the difference is that (currently) we use the synchronous mode of XMLHttpRequests (as prior to 10, due to the lack of wait using async wasn't viable apart from for `load url`). I wonder if that might be the difference. Your sample code and example is useful - if you could post to a bug report, then we will look into whether that is the case, or there is something else going on. Warmest Regards, Mark. P.S. We are hoping to move to the async version of XMLHttpRequest now that we can wait - so that might well be the solution. -- 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: :MEMORY: databases and Windows
On 2022-03-16 22:07, Bob Sneidar via use-livecode wrote: Once again you nailed it. Still, this is a bug, minor though it may be. In the past I was told that it MUST be capitalized. Now it seems capitalized only works on the mac while all lowercase works on both platforms. squared. FWIW I don't think this is a bug. In the SQLite documentation it explicitly states ':memory:' lowercase. We don't process the filename we pass to the SQLite library, so I can't explain the difference between macOS and Windows. Looking at the sqlite sourcecode - it does a case-sensitive comparison between the filename passed and ':memory:'. So, I suggest using ':memory:' as stated by SQLite and all will be well :) 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: 10.0.0-dp-2 html5 and liburlLastRHHeaders()
On 2022-03-16 14:15, Bernard Devlin via use-livecode wrote: If one could get hold in Livecodescript of the Javascript Request object that was sent to the server, then one might be able to get hold of the Response headers. https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/getAllResponseHeaders My guess is that the shim is getting hold of this information but for some strange reason it is stripping out most of the headers. We already use that JS API to implement lastRHHeaders - we just return the value it returns verbatim. Therefore, I'm guessing this is something the API is doing. The only thing which may give a hint is (in that doc): 'For multipart requests, this returns the headers from the current part of the request, not from the original channel.' Not sure whether that applies in this case or not (except that POST is generally used in multipart requests I think...) Anyway, file a bug with an example if you can and we'll take a look. 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: Speed up a slow loop
On 2022-03-02 21:57, J. Landman Gay via use-livecode wrote: The loop takes forever. Here it is (sDictFile is a script local): repeat for each line l in pList -- pList is the user word list if sDictFile[l] = true then put l & cr after tCheckedList else put l & cr after tNonWords wait 0 with messages -- prevent ANRs end repeat I added the wait because my Android phone was putting up an "app not responding" warning while the loop was running (or just after, hard to tell.) The loop should be much faster than that. When I added some timing checks though, the timer says the loop takes between 0 and 1 millisecond, and yet the wait on screen remains. If the difference between `the milliseconds` before the loop, and then after is 0 or 1 millisecond - then that is how long it is taking. This means the issue is somewhere else. Are you sure there isn't anything you are doing either before that loop or after that loop which doesn't wait for ages (due to the ANRs you mentioned). With a 3-word user list, the loop takes 4 seconds. With an 8 word user list the loop takes 6 seconds. The more user words, the longer the wait. If there are only 3 reasonable length words in pList (I.e. 3 lines) then there's no way that loop can take 4 seconds. Of course if the words are multiple megabytes long then it might be possible (however the timing you already stated above suggests the loop isn't actually taking 4 seconds!). Even stranger: on my cheapo Android tablet with 4 megs of RAM running Android 9 the response is nearly instantaneous, even if the user list has 200+ words. On my Pixel phone with 8 megs of RAM and Android 12 the response is slow enough to trigger the ANR with only 3 words. I'm building for ARM 64. This strongly suggests it is something else either on your phone, or in your code which your phone doesn't like I think. Warmst 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: Have we lost the Oracle driver?
On 2022-03-01 15:51, Ben Rubinstein via use-livecode wrote: Hi Matthias, Good spot! Thanks for checking. I wonder whether this is an accidental omission, in that Oracle was at one time only available at a certain higher level of license; maybe now that there is only level, perhaps someone forgot to tweak whatever bit of code checked that the 'correct' license was in place? All business-only features were moved to be part of the pro features pack - the oracle driver included. If it isn't working in your current version of LC, check that the license you have licensed LC with does have the pro features pack in it... If you do `put the revLicenseInfo` it should say professional, rather than commercial. If it doesn't say professional, Relicense your IDE using the menu item in Help and flick through the licenses you have available until one says 'pro' in the title. If the revLicenseInfo does say professional then something odd has happened somewhere which will need to look into more deeply! 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: resetall?
On 2022-02-21 20:17, Mark Wieder via use-livecode wrote: On 2/21/22 10:37, Mark Waddingham via use-livecode wrote: Put another way - if you have done 'close socket i', then it is then it should be logically impossible for i to be in the openSockets immediately afterwards. Ah. Sorry - after issuing a closeSocket call the socket does *not* appear in the opensockets. But the socket seems not to be responding until a reboot. And I'm thinking that I may have a blocking read still in play at that point, and the close socket command doesn't affect it. Can you clarify what you mean by the 'socket seems to not be responding'? When you 'close socket', the engine immediately cancels all pending reads, but will not actually close the file descriptor until all pending writes have finished. I'm puzzled by the idea of 'blocking writes' - write to socket without message will block script execution (and messages) until the timeout or the data is sent; so you can't close socket while that is happening (as script will not be executing). 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: Loading a LONG list with images
On 2022-02-21 23:47, Tom Glod via use-livecode wrote: This is how i did it . I hope this helps. First to use the "numberofrecords" way of setting the datagrid data. This is key, that way you only ever trigger loading of visible rows. So I've not got much to add to Tom's method i.e. make sure the datagrid is only creating rows on demand, rather than up front, and then requesting images and updating them when they arrive Beyond a suggestion to ensure the images which are being downloaded are already suitably sized/thumbnailed for display. Decompressing images is a relatively expensive operation - decompressing and then downsizing them (thumbnailing) even more so. So, if you control the webservice that is providing the images it would probably be worth making it so that the server can send you images at the size needed and do the thumbnailing on the server (caching the results alongside the original image on the server). For maximum fidelity you want the width/height * the device pixel scale (which can vary from 1 to 3 these days). 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