background color of text with metadata

[bamakojeff]

I echo Bernd's sentiments, "This bug is weird..." I think I have something that works, but then I change the font or the font size, and nothing works any more. <SIGH>

I have filed a bug report, so we'll see if anything comes of that.

For the moment, I'll go with changing the foreground color to highlight the text. Perhaps inspiration will strike in the middle of the night, and I'll see a clever answer.

Thanks for all the help.

[dunbarx]

Here is a first shot at the kluge. It places a colored field over any hilited portion of the field text on a single line. I did not lock the screen so one can view the process. It would be a greater, though similar exercise to expand this to multi-line hilited text.

Craig

ColorizeSelection copy.livecode.zip

(1.51 KiB) Downloaded 14 times

[dunbarx]

The first kluge stack I uploaded was the wrong stack. The one currently available is the right one.

Craig

[bamakojeff]

Craig, that's very clever. I've never thought of using the mouse position to "scan" along a line in order to know where the selection stops and then use that information for positioning the overlay. I will definitely play around with this. Even if I don't end up using it here, thank you for another tool in my toolkit!

Jeff

[dunbarx]

Jeff.

They don't call them "kludges" for nothing.

The question for you is whether this works well enough to trust and love. Will there be multi-line selections? Will there be more than one hilited chunk?

If you ask me, I will try to make such a thing. Beats working...

Craig

[dunbarx]

The real issue is that there is no native LC property that defines the botRight of a selection. The "selectedLoc" does the topLeft.

That must be done at home. But once in hand, and knowing the textHeight, filling in the blanks with pre-made colored fields or even colored polygon graphics that look like a tetris shape could be built for any sort of selection.

Craig

[dunbarx]

Jeff.

So if there is no way out of those pesky thin white lines, can you bring yourself to put aside the "standard" method of doing this, that is, the "backColor", and trust the kluge? The reason I ask is that I do not know when, if ever, that bug will be fixed.

Craig

[bn]

Jeff,

I made another attempt at being able to set the backgroundColor of words in a text and provide metadata for each word.
For me this works. I store the metadata of words in the metadata of line 1 of the field.

Have a look at the demo stack and see if it fits your needs.
There is a little more information on how it is done in the stack.

Kind regards
Bernd

[dunbarx]

Bernd.

So the metadata is never set as a property to the words themselves, but rather in the "owner" of those words, that is, the line?

In that case how do you pull the individual metaDatas for each word? Is the line metadata an associated list of pairs, each word in the line to a string of some sort?

Wouldn't a custom property also do that job, and be easier to manage? All this because, and I apologize, I have not looked at your stack.

Craig

[dunbarx]

I never appreciated that the metaData of a chunk is much like a custom property of that chunk, though more limited in scope, since only strings may be assigned. Thanks to Bernd, this is an interesting new tool to consider.

I am not sure how it might solve problems that ordinary custom properties do not, but that needs work to figure out. Off the bat, it allows a much smaller "object" that is, a line, a chunk, a word or even a single character to have data associated with it.

For example, a line of text in a field might be "Now is the time for". If one sets the metadata of word 3 of that line:

Code: Select all

 set the metadata of word 3 of fld 1 to "t,X" & return & "h,Y" & return & "e,Z"

One can then:

Code: Select all

 answer item 2 of line 2 of the metaData of  word 3 of fld 1

and get "Y"

Hmmm.

Craig

[bn]

Bernd.
So the metadata is never set as a property to the words themselves, but rather in the "owner" of those words, that is, the line?
In that case how do you pull the individual metaDatas for each word? Is the line metadata an associated list of pairs, each word in the line to a string of some sort?
Wouldn't a custom property also do that job, and be easier to manage? All this because, and I apologize, I have not looked at your stack.

Craig, I tried to stay as close to Jeff's structure as possible. Of course you could use to custom property to do the same. But I had the impression that Jeff used htmlText a lot and that does not work with custom properties.

So the metadata is never set as a property to the words themselves, but rather in the "owner" of those words, that is, the line?

Actually I use the metadata of line 1 to make a pair of wordnumber:text of property then I can query for each word that does have metadata the content of the metadata.

I was thinking of using the actual line of a word to store the metadata but opted for a central repositorey in line 1.

Kind regards
Bernd

[dunbarx]

Bernd.

Nicely done. It solves the problem of metadata corrupting the backColor. But yours is a kludge as well, and I wonder how Jeff will choose...

Craig

[paul@researchware.com]

The real issue is that there is no native LC property that defines the botRight of a selection. The "selectedLoc" does the topLeft.

'the formattedRect of chunk of field; where the check reference is the selectedChunk will get you the rect of the selection. We do it in our app allthe time. The formattedHeight of char x to y of field z or the formattedWidth of char x to y of field z also work

Beware, there was a nasty bug in earlier versions of LC 9.x where the formattedRect or formattedWidth of a chunk would cause a crash that was fixed in LC 9.6.1+ (see https://quality.livecode.com/show_bug.cgi?id=22882)

[bn]

Nicely done. It solves the problem of metadata corrupting the backColor. But yours is a kludge as well, and I wonder how Jeff will choose...

Craig,

Speaking of kludge:
Here is a version of your stack that hilites more than one line, makes extensive use of formattedRect, creates a graphic that is underneath the field.
The field is now non-opaque. This version is char based, not word based.

Select any portion of the text and hit button "colorize"
To get rid of the marker graphic set a blinking cursor in the field and hit button "colorize"

Have a look

Kind regards
Bernd

[stam]

Bernd, you previous solution is clearly superior - this kludge is fine but scrolling and multiple highlights are an issue... if having to scroll multiple highlights this would quickly escalate into a slow-grinding nightmare!

I quite like what you did with your previous solution... goes to show there is (almost) always a workaround.