Actually I did start with a browser widget but there were too many things I
need to do which aren't easy there. I need to get the clickchunk, color
multiple sentences differently in the same field, get user-hilited text,
etc. But the primary reason for switching to a LC field is that I need to
This is possibly your problem if I understand correctly what
you are doing (Browser source -> LC htmltext -> LC styledText).
You try to work, using one LC method (styledText), around
problems that another LC method (htmltext) has generated.
One way to solve this could be to avoid LC's htmltext at
On 2/21/20 2:10 PM, J. Landman Gay via use-livecode wrote:
The only reason I have more than one instance is because there are href links inside the
metadata spans, and LC translates that into separate metadata spans if there is more than one
link, or there's a line break. If it would honor the e
On 2/21/20 2:51 AM, Mark Waddingham via use-livecode wrote:
Both characters and codepoints run the risk of requiring a linear scan of
the string to calculate the length - strictly speaking his will occur if
the engine is not sure whether character / codepoint have a 1-1 map to
codeunits (for exam
Welcome to the party Hermann. :) Unfortunately the HTML isn't under my control and may change
periodically. It's retrieved from a server on demand. The metadata I'm looking for isn't a
link, it's a text property, and is already hidden when displaying text in a field. It would be
similar to looki
Mark Waddingham wrote:
> On 2020-02-21 17:22, Richard Gaskin via use-livecode wrote:
>> This is an interesting detail. Is it safe to surmise from this that
>> in cases where speed is important we should consider using codeunits
>> instead of chars?
>
> Yes - especially if searching for non-lette
Yes, any additions are good to have.
I hope someone updates it.
JB
> On Feb 21, 2020, at 10:41 AM, Bob Sneidar via use-livecode
> wrote:
>
> Yes, that's it, but not sure if some of these recent gems are getting into
> the library.
>
> Bob S
>
>
>> On Feb 21, 2020, at 10:22 , JB via use-li
Yes, that's it, but not sure if some of these recent gems are getting into the
library.
Bob S
> On Feb 21, 2020, at 10:22 , JB via use-livecode
> wrote:
>
> I thought Michael Doub was handling the Master Library or
> are you talking about something else?
>
> JB
__
I thought Michael Doub was handling the Master Library or
are you talking about something else?
JB
> On Feb 21, 2020, at 7:50 AM, Bob Sneidar via use-livecode
> wrote:
>
> Is anyone maintaining the MasterLibrary? Stuff like this really should be
> added to it when the kinks are worked out.
>
Aha! Of course. I should have thought of that. Mark pointed out the same
thing. (And yes, my brief test had the metadata in the third paragraph.)
I'll try his handler when I get back to my Mac. If my guess is correct, the
search won't take any measurable time at all and the primary delay will b
On 2020-02-21 17:22, Richard Gaskin via use-livecode wrote:
This is an interesting detail. Is it safe to surmise from this that
in cases where speed is important we should consider using codeunits
instead of chars?
Yes - especially if searching for non-letter chars as delimiters (e.g.
return,
Mark Waddingham wrote:
>> I'm using chars instead of codepoints because when I tried it, they
>> both gave the same number. Should I change that?
>
> Both characters and codepoints run the risk of requiring a linear scan
> of the string to calculate the length - strictly speaking his will
> occur
Is anyone maintaining the MasterLibrary? Stuff like this really should be added
to it when the kinks are worked out.
Bob S
> On Feb 21, 2020, at 24:51 , Mark Waddingham via use-livecode
> wrote:
>
> On 2020-02-21 00:29, J. Landman Gay via use-livecode wrote:
>> So glad you chimed in, Mark.
Hi Jacque,
Jacque wrote:
> put the styledText of fld 1 into tDataA
> put 0 into tTotalChars
> put 0 into tStartChar
>repeat with i = 1 to the number of elements in tDataA
>put tDataA[i]["runs"] into tRunsA
>repeat with j = 1 to the number of elements in tRunsA
> put tRunsA[j] in
On 2020-02-21 00:29, J. Landman Gay via use-livecode wrote:
So glad you chimed in, Mark. This is pretty impressive. I'll need to
use the "for each element" structure because my tags are not unique,
but it still is much faster. When clicking a tag at the top of the
document that links to the last
So glad you chimed in, Mark. This is pretty impressive. I'll need to use the "for each element"
structure because my tags are not unique, but it still is much faster. When clicking a tag at
the top of the document that links to the last anchor at the bottom of the text, I get a timing
of about 2
Sorry, forgot that some html entities are not displayed in the list:
So assuming (unusual) should read
-- [1] you use the following for a link target
-- Xtarget10X
where X is ("&" & "#1;") ..., the html translation of numToChar(1).
-- LC translates numToChar(1) to " " should read
-- LC t
As others try to optimize ("ping") I'll try an improvement too ("pong")
with using another method that requires to change your link targets ONCE:
Instead of unique targets write in your field
""&numTochar(1)&"target10"&numTochar(1)&"""
Handler replaceTargets below does it (slowly) but you proba
In reply to Mark Waddingham's comments
Thank you Mark Waddingham for the improved scripts and the hints as to why they
improve speed.
I adapted Mark's version for unique occurrence, changed how the position of the
target word is determined in the target line.
It is not safe to assume that the
Of course *all* three of my suggested approaches are wrong - I messed up
the inner loop in each...
On 2020-02-20 07:56, Mark Waddingham via use-livecode wrote:
NON-UNIQUE ANCHORS
repeat with i = 1 to the number of elements in tDataA
local tRunsA
put tDataA[i]["runs"] into tRunsA
repeat wi
On 2020-02-19 21:40, Niggemann, Bernd via use-livecode wrote:
here is Richard's script which I changed to get the number of words of
the line with the tagged word, the number of lines are taken from the
array.
The tagged word is then: word tNumWords of line (current array key)
-
On 2/19/20 3:40 PM, Niggemann, Bernd via use-livecode wrote:
However the loading time of styledText a little more than 300 milliseconds (no
difference between styledText and formattedStyledText, but htmlText loading of
this heavily formatted text is 800 ms).
If you can manage preloading of the
>J. Landman Gay wrote:
>I haven't converted Bernd's script to use formattedStyledText yet but that
>looks like the way to go.
There is no difference to using styledText for this use case. The number of
lines and the number of words are the same between the two.
You mentioned that you want t
, Bernd
Subject: RE: Translate metadata to field content
>Ralph DiMola wrote:
>What is the difference between styledText and formattedStyledText? A
>quick test yielded identical results. StyledText is in the dictionary.
>From what I tested it behaves the same as formattedText. I.e.
On 2/18/20 1:41 PM, Mark Waddingham via use-livecode wrote:
2. FormattedStyledText treats some punctuation as a new run, even if
it has not changed text style. For example, semi-colons are
independent runs. Very odd.
Hmmm - there's no code to do that explicitly (a semi-colon is no different f
On 2/19/20 2:58 AM, Richard Gaskin via use-livecode wrote:
In Peter's view, he would be surprised to find any case where parsing htmlText would be faster
than working with the styledText array.
This seems to pan out. Bernd sent me a nice test stack that uses styledText and does what Mark
W. su
My previous post was accidentally marking a part of my response as quoting
Ralph's question.
This is my response to Ralph's question about the difference between
styledText versus formattedStyledText
>From what I tested it behaves the same as formattedText. I.e. if you have
wrapped text in
>Ralph DiMola wrote:
>What is the difference between styledText and formattedStyledText? A quick test
>yielded identical results. StyledText is in the dictionary.
>From what I tested it behaves the same as formattedText. I.e. if you have
>wrapped text in a field it will keep the wraps when tra
...@lists.runrev.com] On Behalf Of
J. Landman Gay via use-livecode
Sent: Tuesday, February 18, 2020 2:15 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: Translate metadata to field content
Thanks for the reply guys, both Hermann and Mark, and Bernd who sent me
materials offline. I'
J. Landman Gay wrote:
> I was surprised to see two things:
>
> 1. FormattedStyledText appears nowhere in the dictionary. I didn't
> know it existed.
Me neither. Weird, as it's very powerful, the key to solving problems
just like this one, and a great many besides.
I just flagged the omission
On 2020-02-18 19:14, J. Landman Gay via use-livecode wrote:
Thanks for the reply guys, both Hermann and Mark, and Bernd who sent
me materials offline. I'll be going over these suggestions to see what
works best. The file content can be very long especially when
separated into runs (more than 200,
Thanks for the reply guys, both Hermann and Mark, and Bernd who sent me materials offline. I'll
be going over these suggestions to see what works best. The file content can be very long
especially when separated into runs (more than 200,000 runs for an average file) so speed will
matter since th
> JLG wrote:
> I'm still working on htmltext in a field. There are anchors
> that indicate positions elsewhere in the file. A browser will
> automatically find and scroll to the right place in the text.
> I need to reproduce that.
Besides using style runs you could try the following simple
method
There’s the formattedStyledText property which is like the formattedText but in
the form of a style array. If you sum the number of chars in each run up until
you find your tag, then you can should be able to use the formattedheight of
char 1 up to the summed index to get the vscroll you need.
Thanks, I'll save that for someday. In this case though, the text is wrapped and there are
anchors scattered around inside paragraphs. Unless someone else has an idea it looks like I'm
going to have to extract lookup tables. That's going to be quite a job.
On 2/17/20 3:59 PM, Richard Gaskin via
J. Landman Gay wrote:
I'm still working on htmltext in a field. There are anchors that indicate positions elsewhere
in the file. A browser will automatically find and scroll to the right place in the text. I
need to reproduce that.
Is there a way to translate an anchor like "#12345" to the loc
I'm still working on htmltext in a field. There are anchors that indicate positions elsewhere
in the file. A browser will automatically find and scroll to the right place in the text. I
need to reproduce that.
Is there a way to translate an anchor like "#12345" to the location in the visible fi
37 matches
Mail list logo
