Re: web/Happy 4th

The results aren't out yet. Heading to the polls On Wed, 3 Jul 2024 at 23:03, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Merry FREEDOM FROM TYRANNY DAY! LOL! > > Bob S > > > > On Jul 3, 2024, at 10:51 AM, Mike Kerner via use-livecode < > use-livecode@lists.runrev.c

Re: web/Happy 4th

Again - I hope everyone has a great week, and 4th! > What doesn’t kill us ... makes us awesome and mighty. > Life requires that faith and perseverance. Here’s hoping for a > great 2024 for all, whatever it holds, and an even BETTER 2025! Best wishes, Curry Kenworthy Radically Innovative Christ

Re: web/Happy 4th

Merry FREEDOM FROM TYRANNY DAY! LOL! Bob S > On Jul 3, 2024, at 10:51 AM, Mike Kerner via use-livecode > wrote: > > HAPPY TREASON DAY! > > On Wed, Jul 3, 2024 at 8:46 AM Curry Kenworthy via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> I've been wanting to say, with a slight d

Re: web/Happy 4th

HAPPY TREASON DAY! On Wed, Jul 3, 2024 at 8:46 AM Curry Kenworthy via use-livecode < use-livecode@lists.runrev.com> wrote: > I've been wanting to say, with a slight delay... > Thanks for your comment - It's a great year for encouragement! > > I hope everyone has a great week, and 4th! > > Mark Sm

Re: web/Happy 4th

I've been wanting to say, with a slight delay... Thanks for your comment - It's a great year for encouragement! I hope everyone has a great week, and 4th! Mark Smith: > My goodness Curry, how beautifully said. Thanks for sharing > your thoughts. It reminds me of a quote I saw recently, “Resilie

Re: web

any word on web? just curious On Tue, Feb 13, 2024 at 5:09 AM Mark Smith via use-livecode < use-livecode@lists.runrev.com> wrote: > > > On 13 Feb 2024, at 5:02 am, Curry Kenworthy via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > What doesn’t kill us ... makes us awesome and migh

Re: web

> On 13 Feb 2024, at 5:02 am, Curry Kenworthy via use-livecode > wrote: > > What doesn’t kill us ... makes us awesome and mighty. Life requires that > faith and perseverance. Here’s hoping for a great 2024 for all, whatever it > holds, and an even BETTER 2025! > My goodness Curry, how beaut

Re: web

Sean: > forced to abandon my projects, income and business as a result > Good luck waiting for LC10 to be anywhere near ready for stable use. Hi Sean, I feel for you! Sad about the terrible breaks. Whatever you do, NEVER lose heart; I’ve had ‘rug pulls’ here twice – 1. First with FieldTri

Re: web

I'd been waiting since just before the pandemic started, 2019. Had a meeting with the developers of the web platform early days (2015) and just before they were about to abandon the old method of Web deployment using JS for the the newer method in LC10. Paid 3 years of subscription for the newer me

Re: web

I agree that the standalone builder pane for web deployment is strangely under-functional (it would be so easy to just add a few options for title, background colour of the page, custom logo link etc), and it could also so easily include a resize listener per default in the html file. Neverthel

Re: web

I've not been able to get anything worthwhile to work on web. All the working examples that I've seen (e.g. Andreas's example last week of interaction between browser and LC) , have involved a significant amount of html + JS being written. The default shipping web wrapper is completely under-f

Re: Web help needed

You can use Unison: https://www.cis.upenn.edu/~bcpierce/unison/ I use it to synchronize several servers between them. It works like a Charm. Best On 7/12/20 2:30 PM, Richard Gaskin via use-livecode wrote: Bill Prothero wrote: > Sorry if this is off, but what about just transferring them with

Re: Web help needed

Andre, Your the closest yet to what I was thinking about.  I did not think it was a good idea to have the cue sheets rebuilt on the server.   I was going to rebuild them on the desktop and push them to the server thru a special endpoint. Let me study the links you provided and well see if they

Re: Web help needed

Folks, I think that either you're all misreading the original intent, or I have read it wrong. >From what I have read, Mike has a webapp that converts from one file format to another and wants to do bulk conversion. Rsync and FTP will not help there, what he needs to to be able to call that form

Re: Web help needed

Bill Prothero wrote: > Sorry if this is off, but what about just transferring them with ftp? FTP is good enough for a small number of files. But for automating large numbers of file transfers rsync is hard to beat, a much smarter tool making things much more efficient. By default, rsync will

Re: Web help needed

HostM does support rsync but you have to request SSH to be enabled. I was able to get an sftp client to work.  Im not sure if LiveCode supports sftp. -= Mike On Jul 12, 2020, 1:13 PM -0400, Mike Doub , wrote: > I just sent a request to HostM to see if they support rsync.  If they do then > one

Re: Web help needed

I just sent a request to HostM to see if they support rsync.  If they do then one option would be to create all of the pdfs and csv on the mac then rsync them to the server.  This leads me down a new set of unknowns... How do you set up rsync? I assume that there is some configuration required o

Re: Web help needed

Sorry if this is off, but what about just transferring them with ftp? Bill William Prothero http://es.earthednet.org > On Jul 12, 2020, at 9:57 AM, Mike Doub via use-livecode > wrote: > > The server is hosted on HostM and they are very good a keeping Livecode > Server current. I am assuming

Re: Web help needed

The server is hosted on HostM and they are very good a keeping Livecode Server current. I am assuming it is a Unix variant of some sort.  My desktop is a mac. Let me tell you the details of what I am trying to do.   I have written a tool in livecode that takes a RideWithGPS route and generates a

Re: Web help needed

On 7/12/20 9:10 AM, Mike Doub via use-livecode wrote: Thanks Richard.   I guess I was not clear.   I was looking for the best ways to do the file transfer with LiveCode and LiveCode server. Why? get shell("rsync ")... -- Mark Wieder ahsoftw...@gmail.com __

Re: Web help needed

Hi Mike, I think we are lacking some key information in order to solve your problem. Is your LC Server on a Mac? If so, what is preventing you from just dragging and dropping a folder of your files across the network from your desktop Mac to your LC (Mac?) Server computer? Once your files are o

Re: Web help needed

Thanks Richard.   I guess I was not clear.   I was looking for the best ways to do the file transfer with LiveCode and LiveCode server.   -= Mike On Jul 11, 2020, 10:50 PM -0400, Richard Gaskin via use-livecode , wrote: > Mike Doub wrote: > > > I need to move hundreds of files from my desktop Ma

Re: Web help needed

Mike Doub wrote: > I need to move hundreds of files from my desktop Mac to my server. > I’m looking for advise as to how best to do this. rsync -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ___

Re: Web fonts

> Peter B. wrote: > Crazy question, but is it possible to use a web font within a > internet-connected LiveCode application? Of course in a browser widget, but not for use in other LC objects. ___ use-livecode mailing list use-livecode@lists.runrev.com

Re: Web fonts

Web fonts are usually .woff and LiveCode can’t use that internally, AFAIK. But if you use the browser widget they do work! You can of course download the font in .ttf format and use it that way but then make sure that the licence allow you to do that. Håkan Liljegren On 17 May 2018, 00:34 +020

Re: Web fonts

I've never tried it ...but the easy way to test is to "set the htmltext of field "Text" to html_text" .. if your html has inline font definition chances are it should work. let us know. On Wed, May 16, 2018 at 6:22 PM, Peter Bogdanoff via use-livecode < use-livecode@lists.runrev.com> wrote:

Re: Web vs Native (was Re: HTML5 limitations?)

Wow! Quite the discussion! and here I was away from the list adding one last (hehe maybe not) feature to V1 of the SivaSiva app (hope to release by Aug 15) which was to create a "news channel" of course the obvious way to do this is have an HTML page on line, that you call into a browser widge

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-29 13:10, Jonathan Lynch via use-livecode wrote: So... if we use the wait command, and deploy to HTML5, the engine converts it to JavaScript with extra functions because the engine added in asynchronous timeouts? And you preserve all the variable values of the source LC script across t

Re: Web vs Native (was Re: HTML5 limitations?)

Hi Jim, One can have interruptible animations by using a handler that progresses the movement a single step, then calls itself using a send-in-time construction to initiate the next step. I recently posted a momentum scrolling script on this list that uses this technique. Does that help? Sent

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote: > > I think the first thing we would need would be builtin > gesture support. In this case, this isn't even 'a gesture has happened' > but 'it looks like a swipe is just starting' (I think at least). e.g. > swipeBegin / swipeContinue /

Re: Web vs Native (was Re: HTML5 limitations?)

Hey, Mixed answer below: > - when the app needs access to the phone's functions (notifications, GPS, > screen dimming, text messages, etc) > There are Web APIs for: * Geolocation https://developer.mozilla.org/en-US/docs/Web/API/Geolocation * Notification (both local and push): - Local: https

Re: Web vs Native (was Re: HTML5 limitations?)

Hey, I think I am on a special position to talk about this as I have been on the bleeding edge of the Web trenches for a while. Instead of boring everyone here to death, I will do a quick TL;DR first with the actual info and then digress a bit about the current situation. = WEB: * The we

Re: Web vs Native (was Re: HTML5 limitations?)

Here is an example of using wait in my app... It seems to work better if I first load the map, then add markers from my database, rather than doing both at once. There is not a good trigger to detect when the map is fully loaded and displayed. So, I set an event listener for the page load, to

Re: Web vs Native (was Re: HTML5 limitations?)

You are right, Hermann - did not mean that to be mean-spirited to my home country, which I actually rather love. My apologies. I do think that "wait" can be useful sometimes, but not often. I was just surprised at the effort they are taking to reproduce "wait" in HTML deployment. Sent from m

Re: Web vs Native (was Re: HTML5 limitations?)

Hi I took that to be a self-deprecating comment and not anything to be offended by unless your comment hermann is supposed to be ironic in some sense? Regards Lagi On 29 July 2017 at 13:51, hh via use-livecode wrote: > #wait > I don't miss the "wait" handler in HTML5 and I wouldn't miss it in

Re: Web vs Native (was Re: HTML5 limitations?)

#wait I don't miss the "wait" handler in HTML5 and I wouldn't miss it in LC Script. I even don't know of any use case where "send in " (which works perfectly in HTML5) isn't superior to "wait". Especially when connected to move/animation. Also I don't miss "wait" in LC Builder. There OnTimer() is

Re: Web vs Native (was Re: HTML5 limitations?)

So... if we use the wait command, and deploy to HTML5, the engine converts it to JavaScript with extra functions because the engine added in asynchronous timeouts? And you preserve all the variable values of the source LC script across these multiple functions? This was the easy solution? Eith

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-29 07:11, J. Landman Gay via use-livecode wrote: On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote: P.S. At some point I'll write at length about the 'wait' problem in HTML5. Whilst I try not to let myself be kept awake at night by engineering problems related to work - if e

Re: Web vs Native (was Re: HTML5 limitations?)

Indeed! That is the crux of the problem. Neither Android nor iOS have 'wait' (or the underlying OS feature you need to implement it) either. However those platforms have general threads so you can emulate it. HTML5 does not have general threads (although it probably will in about 2-3 years - a

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote: What specific problem do we really need to solve... i.e. Is card-level swiping generally important enough to warrant an approach which isn't quite so general (very specific, one might say!)? The thing here is that we could well consid

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote: P.S. At some point I'll write at length about the 'wait' problem in HTML5. Whilst I try not to let myself be kept awake at night by engineering problems related to work - if ever there was one which did, it would be that one! When yo

Re: Web vs Native (was Re: HTML5 limitations?)

I thought that JS/HTML5 did not have a wait function? One can loop the engine, which is horrible, or one can set timeouts for functions. What functionality do you access to induce a wait? Sent from my iPhone > On Jul 28, 2017, at 8:29 PM, Mark Waddingham via use-livecode > wrote: > > Hi Herm

Re: Web vs Native (was Re: HTML5 limitations?)

Hi Hermann, First of all please don't take any offence at my email as none was intended. I was mainly trying to explain that whilst there are many things the HTML5 engine does not do, which means many stacks will not work without changes/workarounds (indeed, somewhat significant ones) - ther

Re: Web vs Native (was Re: HTML5 limitations?)

On 07/28/2017 11:41 AM, Mark Waddingham via use-livecode wrote: This is, of course, why I sometimes take 1000 words to say things which could have been said in 10 ;) Wouldn't have it any other way -- Mark Wieder ahsoftw...@gmail.com ___ use-live

Re: Web vs Native (was Re: HTML5 limitations?)

Mark Waddingham wrote: > On 2017-07-28 20:17, Richard Gaskin via use-livecode wrote: >> I think we're closer on this than might have originally seemed: > > Indeed - on this and most things I think. > > I've always assumed that you tend to ask certain questions, or phrase > things in a certain in

Re: Web vs Native (was Re: HTML5 limitations?)

> Mark wrote: > However, there is one VERY important point I do need to make. It is easy > to get hang up on saying 'oh the HTML5 engine doesn't do this, and oh it > doesn't do that' - and this might well be true. *However* the only important > metric in this regard is - does it allow a suitable

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 20:17, Richard Gaskin via use-livecode wrote: I think we're closer on this than might have originally seemed: Indeed - on this and most things I think. I've always assumed that you tend to ask certain questions, or phrase things in a certain in way to give us (well, me, generall

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 12:53 PM, J. Landman Gay via use-livecode wrote: I think we could discuss here on the list how it might work and then add to the feature request if we come up with something. After writing my response, I see that Richard has provided a nice description in the bug report that covers

Re: Web vs Native (was Re: HTML5 limitations?)

Mark Waddingham wrote: > On 2017-07-28 18:34, Richard Gaskin via use-livecode wrote: >> A sense of smooth liquid flow is the hallmark of modern UI. If >> support for this were limited to one widget that requires JavaScript, >> we might as well use the other tools you mentioned above. > > This is

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 19:53, J. Landman Gay via use-livecode wrote: One thought: locking the screen "for swipe effect" might lock the screen while any navigation or card changes are made, and then the unlock command would track the gesture until mouseUp (or touchEnd.) While the tracking is taking place,

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 12:01 PM, Mark Waddingham via use-livecode wrote: That is the standard process for all enhancement requests. They are HIBERNATED until we have the time to evaluate and prioritise - if we were to do anything else, we would end up never getting any work done - and work we are doing rig

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 19:01, Mark Waddingham via use-livecode wrote: Right now JS/HTML5/CSS etc. has the edge over LiveCode in creating these rich UIs. Now, to be honest, the acceleratedRendering mode of LiveCode (which has been around for years) is no different from the underlying tech in browsers which

Re: Web vs Native (was Re: HTML5 limitations?)

On Fri, Jul 28, 2017 at 11:43 AM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > > At the end of the day, it might not be that making it synchronous *is* the > solution, but instead tweaking engine syntax and semantics to make it > easier to deal with this asynchronicit

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 18:34, Richard Gaskin via use-livecode wrote: A sense of smooth liquid flow is the hallmark of modern UI. If support for this were limited to one widget that requires JavaScript, we might as well use the other tools you mentioned above. This is simply not true. All tools have the

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 18:28, William Prothero via use-livecode wrote: on myRequest —send a POST or GET request, whatever, with a callback handler specified. —display a mask that inhibits new mouse clicks and sets a busy icon. end myRequest on myCallbackHander myReturnData —do whatever you want

Re: Web vs Native (was Re: HTML5 limitations?)

Sannyasin Brahmanathaswami wrote: > As for web app vs native app, @Richard Gaskin You *can*, obviously, > build a "web app" (html5+js+css) and package it in the app and run > it off line. another lad here on our team builds in ionic/React > /Angular. But his app is "native" to the phone, appear

Re: Web vs Native (was Re: HTML5 limitations?)

It requires setting up chained handlers on both the LC and JS side, but as long as you structure it well, it is not that bad. I can tell you that for working with maps, it is essential. Sent from my iPhone > On Jul 28, 2017, at 12:28 PM, William Prothero via use-livecode > wrote: > > Folks:

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-26 23:06, hh via use-livecode wrote: There are, sadly, still very basic things missing, which make the HTML5 standalone builder, TMHO, not yet ready for "beta"-state. Well - yes - the 'beta' state as I mentioned was a slip (mainly in that we don't do 'beta' in our dev process as I e

Re: Web vs Native (was Re: HTML5 limitations?)

Folks: As a long term Director developer, I found the use of listeners and callbacks to be quite easy to implement. I don’t see the problem. on myRequest —send a POST or GET request, whatever, with a callback handler specified. —display a mask that inhibits new mouse clicks and sets a busy

Re: Web vs Native (was Re: HTML5 limitations?)

Although I am one of the people calling for more browser widget development... I have my doubts about the ability to make it synchronous with LC. JavaScript is not even reliably synchronous with HTML5, forcing JS developers to use callbacks and event listeners in weird places. Unless you guys a

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote: Hence oft-repeated prayer that we get the browser "widget" to become a true member of the LC message hierarchy, they we can leverage the web apps eye candy layer (easy to build, responsive, CSS is already done for us…) with L

Re: Web vs Native (was Re: HTML5 limitations?)

Matt wrote: Except that they've aged out of the phase where it's easy to learn new things. So they feel like an idiot baby and it takes way too much effort to push through the learning curve. LOL, hence my surprise after listening to some complaints by older folks about the navig

Re: Web vs Native (was Re: HTML5 limitations?)

> On Jul 27, 2017, at 10:48 AM, Matt Maier via use-livecode > wrote: > High market penetration of smartphones doesn't mean anyone actually has any > idea how to use their smartphone. Most people are at about the > Fischer-Price My First Shapes and Colors level. Except that they've aged > out of

Re: Web vs Native (was Re: HTML5 limitations?)

Word. I barely have any experience and I've already run into multiple users/customers who think that "add to homescreen" is impossible hacker magic. High market penetration of smartphones doesn't mean anyone actually has any idea how to use their smartphone. Most people are at about the Fischer-Pr

Re: Web vs Native (was Re: HTML5 limitations?)

Which point illustrates something I'm sure seasoned developers have known for a long time: There is no way to write an app so that it will satisfy everyone, especially these days with all the ways to deliver an app! To illustrate, I had a gal here in the office lose some documents, because I h

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> RG wrote: >> - What are the use-cases where a native app is a better choice than >> a web app? >> - What are the perceived benefits of web apps and native apps? >> The first question is about actual capabilities, and the second >> is about the psychological drivers of clients and c

Re: Web vs Native (was Re: HTML5 limitations?)

Add to list as necessary. I've already pulled in a few items from other posts. We can come up with a referendum/consensus on the topic. Traditional Apps: UP SIDE Better performance No dependent on an internet connection (if server is not installed locally) Many people still prefer to own product

Re: Web vs Native (was Re: HTML5 limitations?)

On Wed, Jul 26, 2017 at 5:27 PM, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > hh wrote: > >> RG wrote: > >> My bigger question here is what needs to be delivered specifically > >> in a web browser window vs a native app, and why? > > > > This questions browsers ("the w

Re: Web vs Native (was Re: HTML5 limitations?)

> RG wrote: > - What are the use-cases where a native app is a better choice than a web app? > - What are the perceived benefits of web apps and native apps? > The first question is about actual capabilities, and the second is about the > psychological drivers of clients and customers, which may or

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> RG wrote: >> My bigger question here is what needs to be delivered specifically >> in a web browser window vs a native app, and why? > > This questions browsers ("the web") as platform in general. > TMHO, you are too late with that question, by 25 years. Perhaps just poor writing on

Re: Web vs Native (was Re: HTML5 limitations?)

> RG wrote: > My bigger question here is what needs to be delivered specifically > in a web browser window vs a native app, and why? This questions browsers ("the web") as platform in general. TMHO, you are too late with that question, by 25 years. ___

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> Mike K. wrote: >> My perception is that the web experience is very close to a desktop- >> native experience, and the two are almost interchangable. Running an >> app in a browser feels and works almost the same as a native one >> does. > > The HTML5 standalone builder... ... > @Mike.

Re: Web vs Native (was Re: HTML5 limitations?)

> Mike K. wrote: > My perception is that the web experience is very close to a desktop-native > experience, and the two are almost interchangable. Running an app in a > browser feels and works almost the same as a native one does. The HTML5 standalone builder has greatly improved within the last y

Re: Web vs Native (was Re: HTML5 limitations?)

My perception is that the web experience is very close to a desktop-native experience, and the two are almost interchangable. Running an app in a browser feels and works almost the same as a native one does. However, once you get to mobile, the web app experience is nowhere on par. Even mobile w

Re: Web vs Native (was Re: HTML5 limitations?)

> JLG wrote: > In my case, the app is courseware and students are complaining they want it > to work on their mobile devices. Some don't have laptops and don't want to > use the computer lab. The options are to create mobile apps or alternately > run it in the mobile browser. There is currently

Re: Web vs Native (was Re: HTML5 limitations?)

J. Landman Gay wrote: > In my case, the app is courseware and students are complaining they > want it to work on their mobile devices. Some don't have laptops and > don't want to use the computer lab. That's an interesting subset. Do you have a feel for what percentage of that audience doesn't

Re: Web vs Native (was Re: HTML5 limitations?)

On July 26, 2017 9:20:17 AM Richard Gaskin via use-livecode wrote: I believe Rick's "Why" here is key to much of what we may be doing over the next couple years. In my case, the app is courseware and students are complaining they want it to work on their mobile devices. Some don't have lapt

Re: Web vs Native (was Re: HTML5 limitations?)

Roger Eller wrote: > As for in-house or "corporate" mobile, they seem to also want > everything to be web based as well. I tried real hard to get > LiveCode accepted for mobile development... Well at least they're consistent in their desire for web apps. I keep coming across people who insist

Re: Web vs Native (was Re: HTML5 limitations?)

As for in-house or "corporate" mobile, they seem to also want everything to be web based as well. I tried real hard to get LiveCode accepted for mobile development, but they only wanted a tool that could create secure html5 apps. This was back when LC html5 was only in early planning. ~Roger O

Re: Web Browser in LC 8

On February 20, 2016 at 6:04:53 AM, Mark Waddingham (m...@livecode.com) wrote: So there is no need to do anything different for android or iOS - it should 'just work'. Mark Aloha, Mark Wow that's awesome, thanks for making that happen! ___

Re: Web Browser in LC 8

The browser widget works on all platforms and should do so uniformly - any platform specific aspects will be marked in the dictionary as such in the usual way. So there is no need to do anything different for android or iOS - it should 'just work'. Mark Mark Sent from my iPhone > On 20 Feb

Re: Web Browser in LC 8

Hi BR, I have not tried the browser widget on mobile. If you have any use for a tree view, consider trying the tree view widget with arrays. Set the arraydata of widget “MyTreeView” to tArray Another trick I learned from an early Kevin Miller video was to turn on “Message Watcher” under

Re: Web Browser in LC 8

On February 20, 2016 at 2:40:56 AM, Trevor DeVore (li...@mangomultimedia.com) wrote: You have to switch to the browse tool to see the contents of the browser. Did you try that? oh... duh... yes, that works :-) @ james... thanks for the encouragement, it seems w

Re: Web Browser in LC 8

On Friday, February 19, 2016, Sannyasin Brahmanathaswami wrote: > Is the Browser widget in LC 8 ready for production? Not in do-14. On Windows the browser doesn't scale properly on hi-dpi displays and it doesn't always behave. There are a number of fixes coming in DP-15 though. I'm trying to pu

Re: Web Browser in LC 8

Hi BR, I’m having good luck with LC8 DP14. I just posted our latest beta of the Global Warming Reader at GlobalWarmingApps.org/GlobalWarmingReader.html This uses the browser widget and 2 tree view widgets. Use the drop down menu in the upper left hand corner of the Dictionary to get more

Re: Web page fields

Hey, if this is for an external browser, and you have control of the page being accessed, there is no reason you can't set up a url with a GET, that is used by the receiving page to set the default value. If the page is straight html, and not php or .lc processed, i'm not sure how you can inject a

Re: Web page fields

This works.. I have this in a hidden field: document.getElementById("query <>").value='the text to search for here'; And do this.. get revbrowserexecutescript(sBrowserId,field 1) and have a browser instance with your form example loaded. It successfully places "the text to search here" in the box w

Re: Web page fields

Ah k. I should have read better. You want to fill in the slots, not just jump to the results. The javascript would be something like document.quick_search_form.query.value='the text to search for here' Since it sounds like you're using the LC browser object, you can probably build the string as ab

Re: Web page fields

Firebug shows: GET https://company.batchbook.com/search/autocomplete?query=NameToSearch When I enter the URL as https://company.batchbook.com/search/autocomplete?query=NameToSearch

Re: Web page fields

If the page isn't too complicated and you can figure out how things are being sent.. (easy if the page works with GET requests.. just look at how it structures the url, and build your own with your query in place of your experimental query) If its a post, you might be able to figure out what is bei

Re: Web Apps

Hi Vaughan, Didn't see anything come up when I was browsing away... Anyway, I'll drop you an email. Sent from my iPhone > On 23 Feb 2014, at 9:39 am, "Vaughn Clement" wrote: > > Hi Nakia > > I tried to chat with you on my site but you blocked me. You might try my > email. > > Thank you >

Re: Web Apps

Hi Nakia I tried to chat with you on my site but you blocked me. You might try my email. Thank you Vaughn Clement Apps by Vaughn Clement (Support) *http://www.appsbyvaughnclement.com/tools/home-page/ * Skype: vaughn.clement https://secure.joi

Re: Web Apps

Folks: Are there any docs on the assert function? Seems like it might be useful, but searching the livecode site and the docs turns up nothing. Bill William Prothero http://es.earthednet.org ___ use-livecode mailing list use-livecode@lists.runrev.co

Re: Web Apps

A nice enhancement would be for a LC plug-in that would translate a stack interface to one that would look the same on the web, using css, perhaps javascript too. It's beyond what I would want to take on, given my minimal css and javascript expertise, but I'd pay some bucks for a plug-in that

Re: Web Apps

would be great!) >>Noting above, needs to be able to send reminder emails based on >> certain conditions >> 4. Support is a big thing as this is Perfect Forms biggest downfall. >> >> >> I hope this makes sense? >> >> >> >> >&

Re: Web Apps

t; > > > > > -Original Message- > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On > Behalf Of Vaughn Clement > Sent: Friday, 21 February 2014 13:03 > To: How to use LiveCode > Subject: Re: Web Apps > > Hi Nakia > > WaveMaker is no

RE: Web Apps

d be great - Needs to be able to be hosted on a Cloud -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Mark Schonewille Sent: Friday, 21 February 2014 13:35 To: How to use LiveCode Subject: Re: Web Apps Nakia, What I understand from your

Re: Web Apps

Nakia, What I understand from your e-mail is: - you need to fill out web forms - you need to send e-mails What other _technical_ requirements do you have? Automate paper processes and begin a workflow aren't really items that belong in a list of technical requirements. So far, you give me th

RE: Web Apps

- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Vaughn Clement Sent: Friday, 21 February 2014 13:03 To: How to use LiveCode Subject: Re: Web Apps Hi Nakia WaveMaker is not even 50% of what LiveCode can offer. I spent about 2 months trying to work wit WM before I

Re: Web Apps

Hi Nakia WaveMaker is not even 50% of what LiveCode can offer. I spent about 2 months trying to work wit WM before I found LivCode. Alex has the point at hand, what are you trying to do? As you can see I am mainly a database developer, and I've used about every kind of DB app over the last 35 year

  1   2   >