Re: windowBoundingRect on multiple monitors? Is this a bug?
Also, I just wanted to add that the windowsBoundingRect property - on the primary monitor - is helpful. We use it to limit maximize to a smaller area because we place a Toolbar palette under the menu and don't want maximized window to disappear behind the toolbar. On 5/25/2019 9:04 PM, Paul Dupuis via use-livecode wrote: Mark, LiveCode, Ltd needs to put the contents of your brain in the LiveCode documentation! Wow, thank you again for the ver helpful clarification. This will make things much easier. Now, go back to bed and get some sleep! On 5/25/2019 8:21 PM, Mark Waddingham via use-livecode wrote: On 2019-05-25 23:19, Paul Dupuis via use-livecode wrote: If you have resizable windows, it is logical to set the windowBoundingRect to the working screenRect, so that windows that are zoomed (OSX) or maximized (Windows) are limited to the area of the primary monitor NOT being used for a menu bar or task bar. Okay so you *shouldn't* have to do this - the windowBoundingRect does not override the platform defaults... Which is to maximise the window within the working area of the pertinent screen regardless. Indeed, if you set the windowBoundingRect to the screenRect, a window will still only maximise within the working area (i.e. the OS automatically constrains things at least that much). [ Note: You can still set windows to be where you want explicitly, this OS supplied effect only happens when you use the maximise button ] It seems to me that with the advent of multiple monitor support in 'the working screenRects' that there should either (1) be the windowBoundingRects (plural) with each one corresponding to each line of the screenRects OR (2) the windowBoundingRect be ignored on all monitors but the primary? I think this might have been an oversight when we moved to Cocoa, there is explicit code in the windows port at least to *only* apply the WBR when the window's screen is the primary monitor. This appears to be missing in the Mac port (although the code is somewhat murky so I could be wrong). Ultimately the WBR is an edge-case feature at most - mostly there for the purposes of the IDE and similar tools and it is somewhat flawed for that. In its current incarnation it should both only apply to the primary screen, and should be able to be set to empty so that the engine does not influence what the OS tries to do with script supplied window rects at all. Warmest Regards, Mark. P.S. I think a work-around for now is to either set it to just the screenRect; and if that does not work, set it to -8192,8192,8192,8192 and see if your windows behave more appropriately. ___ 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: windowBoundingRect on multiple monitors? Is this a bug?
Mark, LiveCode, Ltd needs to put the contents of your brain in the LiveCode documentation! Wow, thank you again for the ver helpful clarification. This will make things much easier. Now, go back to bed and get some sleep! On 5/25/2019 8:21 PM, Mark Waddingham via use-livecode wrote: On 2019-05-25 23:19, Paul Dupuis via use-livecode wrote: If you have resizable windows, it is logical to set the windowBoundingRect to the working screenRect, so that windows that are zoomed (OSX) or maximized (Windows) are limited to the area of the primary monitor NOT being used for a menu bar or task bar. Okay so you *shouldn't* have to do this - the windowBoundingRect does not override the platform defaults... Which is to maximise the window within the working area of the pertinent screen regardless. Indeed, if you set the windowBoundingRect to the screenRect, a window will still only maximise within the working area (i.e. the OS automatically constrains things at least that much). [ Note: You can still set windows to be where you want explicitly, this OS supplied effect only happens when you use the maximise button ] It seems to me that with the advent of multiple monitor support in 'the working screenRects' that there should either (1) be the windowBoundingRects (plural) with each one corresponding to each line of the screenRects OR (2) the windowBoundingRect be ignored on all monitors but the primary? I think this might have been an oversight when we moved to Cocoa, there is explicit code in the windows port at least to *only* apply the WBR when the window's screen is the primary monitor. This appears to be missing in the Mac port (although the code is somewhat murky so I could be wrong). Ultimately the WBR is an edge-case feature at most - mostly there for the purposes of the IDE and similar tools and it is somewhat flawed for that. In its current incarnation it should both only apply to the primary screen, and should be able to be set to empty so that the engine does not influence what the OS tries to do with script supplied window rects at all. Warmest Regards, Mark. P.S. I think a work-around for now is to either set it to just the screenRect; and if that does not work, set it to -8192,8192,8192,8192 and see if your windows behave more appropriately. ___ 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: windowBoundingRect on multiple monitors? Is this a bug?
On 2019-05-25 23:19, Paul Dupuis via use-livecode wrote: If you have resizable windows, it is logical to set the windowBoundingRect to the working screenRect, so that windows that are zoomed (OSX) or maximized (Windows) are limited to the area of the primary monitor NOT being used for a menu bar or task bar. Okay so you *shouldn't* have to do this - the windowBoundingRect does not override the platform defaults... Which is to maximise the window within the working area of the pertinent screen regardless. Indeed, if you set the windowBoundingRect to the screenRect, a window will still only maximise within the working area (i.e. the OS automatically constrains things at least that much). [ Note: You can still set windows to be where you want explicitly, this OS supplied effect only happens when you use the maximise button ] It seems to me that with the advent of multiple monitor support in 'the working screenRects' that there should either (1) be the windowBoundingRects (plural) with each one corresponding to each line of the screenRects OR (2) the windowBoundingRect be ignored on all monitors but the primary? I think this might have been an oversight when we moved to Cocoa, there is explicit code in the windows port at least to *only* apply the WBR when the window's screen is the primary monitor. This appears to be missing in the Mac port (although the code is somewhat murky so I could be wrong). Ultimately the WBR is an edge-case feature at most - mostly there for the purposes of the IDE and similar tools and it is somewhat flawed for that. In its current incarnation it should both only apply to the primary screen, and should be able to be set to empty so that the engine does not influence what the OS tries to do with script supplied window rects at all. Warmest Regards, Mark. P.S. I think a work-around for now is to either set it to just the screenRect; and if that does not work, set it to -8192,8192,8192,8192 and see if your windows behave more appropriately. -- 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
windowBoundingRect on multiple monitors? Is this a bug?
With LC90x+ we have the screenRect (for the primary monitor), the screenRects (for multiple monitors and we can even use the 'working' keyword to get the screenRect less any OS reserved space for menu bar or task bar. Thus, if you have a set up with 2 monitors, the working screenRect returns the available space on the primary monitor leef any menubar or task bar. This is also the first line of the working screenRects and the 2nd line of the working screenRects is the coordinated of the 2nd monitor. If you have resizable windows, it is logical to set the windowBoundingRect to the working screenRect, so that windows that are zoomed (OSX) or maximized (Windows) are limited to the area of the primary monitor NOT being used for a menu bar or task bar. However, there is only one windowBoundingRect, so what about a window on the second monitor that is zoomed or maximized. It ends up being constrained by the windowBoundingRect set based on the primary monitor! So if you second monitor is positioned so most of its area is outside the windowBoundingRect, you will be unable to fully maximize the window on the second display. It seems to me that with the advent of multiple monitor support in 'the working screenRects' that there should either (1) be the windowBoundingRects (plural) with each one corresponding to each line of the screenRects OR (2) the windowBoundingRect be ignored on all monitors but the primary? Anyone else run into this? ___ 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 64
On 2019-05-24 17:21, Bob Sneidar via use-livecode wrote: A 32 bit OS can only address around the first 2 gigs of memory. Not very good for running multiple apps. This was the case before OSes started to use virtual addressing and paging, but no longer. The bitness of the OS determines the maximum amount of memory any one application can access certainly, but they don't *share* this space. Specifically: - iOS/macOS 32-bit: every application has its own 4Gb (32-bit) address space - iOS/macOS 64-bit: every application has its own 256Tb (48-bit) address space* - windows 32-bit (older): every application has its own 2Gb address space - windows 32-bit (newer): every application has its own 3Gb address space - linux/android - I believe these have the same as iOS/macOS The key difference to be noticed here is between windows 32-bit and all others... UNIXy 32-bit OSes completely separate user and kernel space - a context switch between these two modes is required to invoke a system call. Windowsy 32-bit OSes have some kernel stuff in the user space address space (but protected). The difference between older and newer 32-bit OSes started in XP I believe - there is a flag you can set in the boot params for XP which means the kernel is only given 1Gb of user space. (I believe this was always on for post-XP OSes). In 64-bit, all OSes work similarly - the very very very very large address space available to any one context is split into zones. Some zones are kernel, some are user space (for applications). The kernel ones are only accessible when running in the kernel protection mode. Of course, the amount of memory you can actually have in total allocated in the system is limited by physical RAM and disk space (i.e. the paging file) - in 32-bit OSes the amount of this any one app could use was limited; in 64-bit it is still limited, but the limit is so high that it is much less likely to be hit. For most apps the 32-bit vs 64-bit address space differences probably don't make any difference - but for apps which process large amounts of data which would be more performant if they could hold all that data in RAM, 64-bit is a huge boon. Warmest Regards, Mark. * Both ARM64 (AArch64) and x86-64 processors currently only use the lower 48-bits of the 64-bit pointers. However, there is scope in both for this to be expanded in the future to the full 64-bit capability. Of course it might be that it ends up getting used for something else - for example, recent ARM architectures have added an interesting feature which makes use of the 'empty space' in 64-bit addresses - certain critical pointers can use those extra 16-bits to hold a piece of encrypted information which allows the processor to validate use and access within the processor itself. -- 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: Windows 64
On 2019-05-24 22:31, Richmond via use-livecode wrote: What I mean is that LiveCode produces a "Fat" standalone which suffers from the following disadvantages: 1. It's fat, quite literally. 2. I wonder whether MacOS Somewhere_Obscure_In-California (10.15) will not object to those standalones because, as well as containing 64-bit code they also contain 32-bit code. You can choose to produce a slim standalone - the default in the S/B is to produce a standalone with both 32-bit and 64-bit slices... You can choose one, or other or both using the checkboxes at the top of the macOS specific settings pane. The default in 9.0.x and onwards is to *only* select the 64-bit option for macOS for new stacks - however, if you created a standalone from a stack in older versions it will likely have both options set. All macOS hardware which we currently support is capable of running 64-bit apps... However, the reason why we must continue to provide fat binaries, and offer the choice to build for 32-bit on macOS is that we are aware of a number of users who have 32-bit externals which they have yet to migrate (migration, unfortunately, is not necessarily a simple recompile - due to the fact that macOS's 64-bit side does not support a large number of the older, long deprecated, system APIs). In terms of the 32-bit warning that many have been noticing on Mojave, we found the culprit a month or so ago - the auto-updater sitting inside the app bundle is still 32-bit. We had intended to switch it to 64-bit for 9.5-dp-1 but ran out of time to do so. Warmest Regards, Mark. P.S. It would be *immensely* helpful for us at HQ if anyone who still relies on 32-bit externals in apps they are still maintaining (i.e. by continuing to build from the latest and greatest LiveCode versions) could drop a line to supp...@livecode.com so we can keep track and use that information to influence the decision of when to cut 32-bit from the macOS binaries. [ The benefit from doing this is three-fold - it halves the time taken to build the macOS binaries, halves our macOS test matrix and reduces the size of the distribution by upward of 50-60Mb ]. -- 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: Player object controller bar
On 5/25/2019 11:37 AM, Paul Dupuis via use-livecode wrote: On 5/25/2019 11:10 AM, Paul Dupuis via use-livecode wrote: If you are on Pause, the Forward and Rewind arrows step forward or backwards by frame If you are on Play, the Forward and Rewind arrows fast forward or rewind (currently not working under Windows in LC904/5) Play and Pause toggle between one another Dragging the thumb changes the current time However, Alt (Win) or Opt(OSX) clicking forward or rewind arrows jumps you to the end or start respectively I'd like to know what other modifier key in combination with visible controls do what? Without having to try every possible combination of keys and clicking. Another example, SHIFT Clicking on the Forward/Rewind area changes it to a blue slider, which does WHAT? I can find no documentation on the player's object controller bar. I assume it must exists, but I just can't find it. I stand corrected (a tiny bit) as I finally found this among the LiveCode Lessons: http://lessons.livecode.com/m/4603/l/44283-using-players It actually has an annotated picture (at https://media.screensteps.com/image_assets/assets/001/160/690/original/36c81ebf-9b3a-4610-a259-fbc2eacd2843.png) of the controller and the sparse notation: "The controller that appears at the bottom of the player allows the user to start and stop play back(1), control the volume(2) and move to a certain point in the sound file or movie(3,4)." And, yea, I probably could have tried every key and click combination in the time I have spent searching for documentation :-( ___ 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: Player object controller bar
> Am 25.05.2019 um 18:13 schrieb Paul Dupuis via use-livecode > : > > On 5/25/2019 11:49 AM, Klaus major-k via use-livecode wrote: >> why not try by yourself? Your machine won't exlode, promised!:-D >> >> With this slider you can control the speed of playback: >> playback backwards <- drag left- drag right-> playback forward > > You miss my point. It should be documented. A LiveCode developer should not > have to "try by yourself" to learn what ALL the built in functions of the > player controller bar are. yes, sorry, this is true of course! -- Klaus Major http://www.major-k.de kl...@major-k.de ___ 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
how to load a local file into the browser widget?
Thanks, hh, that does it! :)
*answer*file"Choose an html file"
*put*urlEncode(textEncode(it, "UTF-8")) intotPathWithCyrillic
*set*theurlofwidget"Browser"totPathWithCyrillic
Occasional accents & punctuation in the file names are not causing
problems either (so far). But then the spaces..
*replace*" "with"%20"intPathWithCyrillic
didn't work since the urlEncode was inserting "+" where it found a space.
So replacing "+" with "%20" fixes that. Final version:
*answer*file"Choose an html file"
*put*urlEncode(textEncode(it, "UTF-8")) intotPathWithCyrillic
*replace*"+"with"%20"intPathWithCyrillic
*set*theurlofwidget"Browser"totPathWithCyrillic
Thanks everyone!
Curt
You could try to use (for example):
urlEncode(textEncode("брать","UTF-8"))
--
Sent from Postbox
___
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: Player object controller bar
On 5/25/2019 11:49 AM, Klaus major-k via use-livecode wrote: why not try by yourself? Your machine won't exlode, promised!:-D With this slider you can control the speed of playback: playback backwards <- drag left- drag right-> playback forward You miss my point. It should be documented. A LiveCode developer should not have to "try by yourself" to learn what ALL the built in functions of the player controller bar are. ___ 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: Player object controller bar
Hi Paul, > Am 25.05.2019 um 17:37 schrieb Paul Dupuis via use-livecode > : > > On 5/25/2019 11:10 AM, Paul Dupuis via use-livecode wrote: >> If you are on Pause, the Forward and Rewind arrows step forward or backwards >> by frame >> If you are on Play, the Forward and Rewind arrows fast forward or rewind >> (currently not working under Windows in LC904/5) >> Play and Pause toggle between one another >> Dragging the thumb changes the current time >> >> However, Alt (Win) or Opt(OSX) clicking forward or rewind arrows jumps you >> to the end or start respectively >> I'd like to know what other modifier key in combination with visible >> controls do what? Without having to try every possible combination of keys >> and clicking. > > Another example, SHIFT Clicking on the Forward/Rewind area changes it to a > blue slider, which does WHAT? why not try by yourself? Your machine won't exlode, promised! :-D With this slider you can control the speed of playback: playback backwards <- drag left- drag right-> playback forward Best Klaus -- Klaus Major http://www.major-k.de kl...@major-k.de ___ 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: Player object controller bar
On 5/25/2019 11:10 AM, Paul Dupuis via use-livecode wrote: If you are on Pause, the Forward and Rewind arrows step forward or backwards by frame If you are on Play, the Forward and Rewind arrows fast forward or rewind (currently not working under Windows in LC904/5) Play and Pause toggle between one another Dragging the thumb changes the current time However, Alt (Win) or Opt(OSX) clicking forward or rewind arrows jumps you to the end or start respectively I'd like to know what other modifier key in combination with visible controls do what? Without having to try every possible combination of keys and clicking. Another example, SHIFT Clicking on the Forward/Rewind area changes it to a blue slider, which does WHAT? I can find no documentation on the player's object controller bar. I assume it must exists, but I just can't find it. ___ 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: Player object controller bar
On 5/25/2019 10:08 AM, Rick Harrison via use-livecode wrote: My experience with player controllers is that if you just want people to be able to use the built in controls, that should work fine. I just want to see a document that tell me what ALL the built in controls are. Are these all the function of the player controller bar On 5/25/2019 10:28 AM, Sannyasin Brahmanathaswami via use-livecode wrote: I just hoping that there is a little API in the engine itself, that responds to 6 simple function of the controller Play Pause Scrub forward Scrub back Fast Rewind Fast Forward Volume If you are on Pause, the Forward and Rewind arrows step forward or backwards by frame If you are on Play, the Forward and Rewind arrows fast forward or rewind (currently not working under Windows in LC904/5) Play and Pause toggle between one another Dragging the thumb changes the current time However, Alt (Win) or Opt(OSX) clicking forward or rewind arrows jumps you to the end or start respectively I'd like to know what other modifier key in combination with visible controls do what? Without having to try every possible combination of keys and clicking. ___ 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 64
On May 24, 2019, at 1:31 PM, Richmond via use-livecode wrote: > >> A 32 bit OS can only address around the first 2 gigs of memory. Not very >> good for running multiple apps. > Dunno about that: I've been running multiple apps ever since I bought a > Macintosh LC475 running MacOS 7.0.1. Newbie :) More seriously, we had something (switcher?) that let us segment the memory into multiple Macs. I remember using it on a Mac Plus with 1mb, but think I also used it on a my 128k that had been boosted to 512k. Then came multifinder in '87 (?) with system 5. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Player object controller bar
" Some things that seem like they should be easy to accomplish, just are not easy. That is the harsh reality. " Indeed, I been working of weeks get getting the browser to respond properly. Keep on changing with every new release. I just hoping that there is a little API in the engine itself, that responds to 6 simple function of the controller Play Pause Scrub forward Scrub back Fast Rewind Fast Forward Volume == Rick Harrison wrote: The problem arises when you want to do something different that the controller on it’s own normally wouldn’t do. In that case the best solution that worked for me was to hide the normal player controls, and then make my own controller buttons and functions from scratch. == Ahha! __ you did it already. Can you share sample stack on the forum? ___ 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: Player object controller bar
Hi Paul and Sannyasin, My experience with player controllers is that if you just want people to be able to use the built in controls, that should work fine. The problem arises when you want to do something different that the controller on it’s own normally wouldn’t do. In that case the best solution that worked for me was to hide the normal player controls, and then make my own controller buttons and functions from scratch. That gave me full control over everything that was going on, and I was able to accomplish my goal. Was it a pain, and did it seem like there should have been an easier solution? Yes, but the at least LC allowed me to work on the problem on my own. Some things that seem like they should be easy to accomplish, just are not easy. That is the harsh reality. Good luck! Rick > On May 25, 2019, at 9:33 AM, Sannyasin Brahmanathaswami via use-livecode > wrote: > > In a related quest: I just went through the same thing yesterday... > > I would like to trap if a user clicks the play icon on the player controller > itself. I have functions which take the current time etc. allow time based > annotation in field. But they only work if the use clicks my "Play" button > to initiate the handlers. Like you have a little API to the player, all run > from buttons independent of the controller. > > But if the user click the player to start or scrubs forward and backwards, it > by passes the timing currentTime function. I could hide the player, make my > own progress bar to tie to my own "little player API" handlers, but that > seems to be overkill. > > So, this requires knowing what is/can be handled in the background when the > user interact with the controller, that we can track/handle "that is built > into the controller bar itself." > > BR > > > Paul wrote: > >I have searched the dictionary, Guides, and livecode.com but have been >unable to find a annotated picture of the LC9xx player objects' >controller bar and what each control does, especially in combinations >with with modifier keys > >Clearly, some controls are obvious, like play/pause, etc., but I am >looking for detailed documentation so I don't miss anything that is >built into the controller bar itself. > > ___ > 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: Player object controller bar
In a related quest: I just went through the same thing yesterday... I would like to trap if a user clicks the play icon on the player controller itself. I have functions which take the current time etc. allow time based annotation in field. But they only work if the use clicks my "Play" button to initiate the handlers. Like you have a little API to the player, all run from buttons independent of the controller. But if the user click the player to start or scrubs forward and backwards, it by passes the timing currentTime function. I could hide the player, make my own progress bar to tie to my own "little player API" handlers, but that seems to be overkill. So, this requires knowing what is/can be handled in the background when the user interact with the controller, that we can track/handle "that is built into the controller bar itself." BR Paul wrote: I have searched the dictionary, Guides, and livecode.com but have been unable to find a annotated picture of the LC9xx player objects' controller bar and what each control does, especially in combinations with with modifier keys Clearly, some controls are obvious, like play/pause, etc., but I am looking for detailed documentation so I don't miss anything that is built into the controller bar itself. ___ 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 load a local file into the browser widget?
On 5/25/2019 7:47 AM, Paul Dupuis via use-livecode wrote: On 5/25/2019 4:17 AM, Klaus major-k via use-livecode wrote: Sorry, I don't know, someone else needs to chime in here. Obvioulsy "Unicode, it just works" doesn't do with filenames. :-/ Our experience with LC90x has been that Unicode DOES just work with filename, for 'open file , there is a file , put URL into , and most other file related commands and functions. HOWEVER, I would never claim we've tested every LC file related command and function. We've done with with Russian text and Chinese (simplified and traditional) in both paths and file names. Just another data point. That was supposed to say: Just another data point, although we've never tested with a Browser Widget. ___ 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 load a local file into the browser widget?
On 5/25/2019 4:17 AM, Klaus major-k via use-livecode wrote: Sorry, I don't know, someone else needs to chime in here. Obvioulsy "Unicode, it just works" doesn't do with filenames. :-/ Our experience with LC90x has been that Unicode DOES just work with filename, for 'open file , there is a file , put URL into , and most other file related commands and functions. HOWEVER, I would never claim we've tested every LC file related command and function. We've done with with Russian text and Chinese (simplified and traditional) in both paths and file names. Just another data point. ___ 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: play sounds in HTML5
To avoid misunderstandings:
This relates to a HTML5 standalone, not to using HTML5 in a browser widget.
We could use two steps.
Step 1.
Use one certain audio file. Make this work from the html file containing
where audio is a folder at the same location as your html file
(on the server that is running your standalone. Files from other urls
(CORS) may be not available due to SOP/ user's browser behaviour).
Step 2.
You already wrote that step 1 works for you as above (or in a similar way)
with a certain audio file.
You ask now how to play available sounds (which may vary) in random order.
For that you can sort the available filenames in LC by random.
Then set one after the other as the one you play/pause with your buttons.
Using the identifiers from the tutorial this setting can be done as
follows in a HTML5 standalone.
-- assume "guitar-melody.wav" is the randomly chosen filename
-- or the next/previous filename in a fixed order
put "./audio/guitar-melody.wav" into myFile
put "document.getElementById('myAudio').src=" into tScript
do tScript & "'" & myFile & "'" as "JavaScript"
Then use your buttons play/pause as usual.
[If questions remain you could also post in the HTML5 subforum where
you can add attachments.]
___
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 load a local file into the browser widget?
>> Curt wrote:
>> While I'm at it... some of the folders in the file path will
>> be in Russian, which is breaking my current handler...
>> I can run those items of the file path through a quick
>> transliteration function to change брать into brat' etc., but
>> thought it's worth checking...
> Klaus wrote:
> Obvioulsy "Unicode, it just works" doesn't do with filenames. :-/
You could try to use (for example):
urlEncode(textEncode("брать","UTF-8"))
___
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 load a local file into the browser widget?
Hi Curt, > Am 25.05.2019 um 00:43 schrieb Curt Ford via use-livecode > : > > Thanks Klaus, those are great tips! you are welcome! > While I'm at it... some of the folders in the file path will be in Russian, > which is breaking my current handler. Is there a way to run them through some > unicode-type function to make them work in a file path? > > I can run those items of the file path through a quick transliteration > function to change брать into brat' etc., but thought it's worth checking... Sorry, I don't know, someone else needs to chime in here. Obvioulsy "Unicode, it just works" doesn't do with filenames. :-/ > Curt Best Klaus -- Klaus Major http://www.major-k.de kl...@major-k.de ___ 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: identifying macOS folders that are considered to be files?
Mark, Trevor, Thank you. Will test tomorrow. Will report back. Thanks again Kee Nethery > On May 24, 2019, at 6:53 PM, Mark Waddingham via use-livecode > wrote: > > I’m pretty sure bundles always have a PkgInfo file in them too - so you > should (alternatively to using LCB) use ‘there is a file ...’. > > Warmest Regards, > > Mark. > > Sent from my iPhone > >> On 24 May 2019, at 18:06, Trevor DeVore via use-livecode >> wrote: >> >> On Fri, May 24, 2019 at 7:35 PM kee nethery via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >>> Is there any way for LiveCode to tell me that a macOS folder that gets >>> listed with “the folders” is actually treated as a file? For example, .app >>> is a file where View Package Contents is an option but the OS treats it as >>> a single thing. Same with .numbers, .pages, and various other “files”. They >>> can be opened up and the contents can be viewed. >>> >>> Is there any way to know which “folders” are actually treated by the OS as >>> files? >>> >> >> If you don't get any pure LCS solutions you could use an extension. macOS >> has an API for this: >> >> https://developer.apple.com/documentation/appkit/nsworkspace/1529991-isfilepackageatpath?language=objc >> >> I just tested it in my macOS test bed for extensions and it seems to work. >> It is the NSWorkspaceIsFilePackageAtPath() handler in this file: >> >> https://github.com/trevordevore/lc-macos-toolset/blob/master/NSWorkspace/nsworkspace.lcb >> >> -- >> Trevor DeVore >> ScreenSteps >> ___ >> 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: Windows 64
No worries at all: it did, after all, give me a wonderful chance to tease you a bit. Bulgaria is not a 3rd world state: it is a bit "ragged at the edges," but no more than a lot of other countries. If you want to make "big moolah" it isn't the place to be: but one can lead a perfectly decent life here. Richmond. On 25.05.19 1:52, Bob Sneidar via use-livecode wrote: Sorry Richmond I got that from prior posts about the schools you were working with and you mentioned that the reason you wanted to use much older Macs and such was that they could not afford newer products there in Bulgaria. I didn't mean to cast aspersions on your status. Please forgive me. Bob S On May 24, 2019, at 13:31 , Richmond via use-livecode wrote: My "financial situation living and working where you do" sounds almost racist and certainly a bit condescending. You know nothing whatsoever about my financial situation (it's like most people's financial situation: plain boring). You are, if you feel the urge, most welcome to come and stay for a week to assess my standard of living; especially as I refilled the fridge yesterday. ___ 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
