LiveCode Forums.

For Jacque and FourthWorld;

On your last parting post comment, my program (you can see it in the code part I sent you yesterday) already allows the user to select as few as one char all the way up to the entire field.
=============================================================================
For Jacque and FourthWorld;

The only reason I did not send you the whole stack which would make everything obvious, is that I am in the middle of changes with breakpoints and temporary code all over the place so the stack won’t run normal/right and would just confuse you at this moment. Reminder: I am working in windows OS.

So the next best thing is to act like the user and select part of the output results containing colored text background. The end intent of the user is to then be able to copy the results selection and paste the info OUTSIDE of LC say into a word processor app like word for windows so that they can work on it even when the app is shut down or when they are away from their main computer.

Based on what the user selected, I will send you the web page LC makes with the issue that causes the backgrounds to come out all black which makes the outputs the user needs useless. I will call this file LC_WebSelections.html

Then after the HTML replacements are done (I sent you yesterday exactly what and how to replace the html), I will send you that file too. I call that file “FixedWebSelections.html”.

You will see that when you open up the “LC_WebSelections.html” file with a web browser, the italics and bold styles are kept but the colored highlights are not. They appear all non existant. Copying the selection is now a useless proposition since the colors are not going to magically appear now.

When you open file “FixedWbSelections.html” in a web browser, you will now see ALL of the retained colored highlights. Now you can copy the entire selection into word for windows (desktop app) or paste then into Google docs’s writer part(online app) so that you can verify for yourself that for both outside of LC instances (desktop and online) the colored highlights are retained in their full glory.

At this point you should be able to compare both html source code and see how the “fix” replaced html turned out. Note I tested all this with the following browsers so this is not just a particular browser “lucky fix”. Browsers in windows OS used to test both files: iexplore, chrome, firefox, Maxthon, Opera and safari probably the most popular browsers being used out there.

For apps like mine that can generate over a hundred pages of Regex outputs related to matches and concise capture group replacements, being able to show helping “colored highlights” (colored text backgrounds) related to found matches and replaced text, main heading directives etc. and being able to transport then OUTSIDE of LC for manipulation/review is CRITICAL. Without this, the user will have a very difficult time zooming in on such results.

This was one of my biggest requests (making the colored output available OUTSIDE of LC) from users when I started to create the program and is something I noticed many LC apps do not offer even when they should have because their transported output type is hard to follow without colored highlights.

Perhaps this was not done before because they were never able to bring colored text backgrounds outside of LC, so the authors may have just gave up.

Let me know if this covers all you need to feel comfortable that the provided remedy does its job as advertised.

[Jacque]
You were not able to get back to me with the answer to my question (see last post) that the clipboard is containing the source html which is not what we need pasted and any attempt to paste this into word for windows does nothing???

Thanks

Thanks, those were the files we needed. The differences are minor. LC uses "bgcolor=" and your "fixed" file uses "background-color" and a "<span>" tag. I don't think the span is strictly necessary, though you're right it's a more modern convention. For starters, try this to catch when the user copies text from a field:
You can alternately trap the copyKey message instead but it won't work in the IDE, where LC blocks it for its own use. It should work in a standalone though. I wasn't able to test the actual pasting because I don't own a copy of Word, but let us know if it works. Also note that once you've altered the clipboard content, it won't paste back into a LC field correctly unless you reverse the replacement again.

The above will capture the keyboard shortcut for copying text. It won't catch a menu selection, you'd have to call "copyFix" from the menu script.

Edit: If this still doesn't paste anything at all, it might be a recurrance of an old LC bug that prevented pasting into Word. Try a different app. If it does paste elsewhere, then a bug report to LC would be in order. In fact, I'm wondering if that isn't the whole problem to begin with.

This topic caught my interest because I do a lot of work with modifying Clipboard contents, and also a lot of generation of Web pages from within LiveCode.

So, keenly motivated, I posted a note about the difference between the "html" and "htmlText" keys in the clipboardData array to the use-livecode discussion list, and the lead engineer, Mark Waddingham, reminded me of the newer fullClipboardData array which turns out to be exactly what the OP needs.

Short answer: Jacque's sample above is almost perfect but with one addition: if you modify the fullClipboardData["html"] you can use it directly without needing to write to a file and then copy from a Web browser.

Long answer: see attached example, which lets you set and modify the Clipboard in various ways, and provides a means of exploring the resulting changes in each of the three array forms LiveCode provides for working with Clipboard data.

EDIT 4:15 PST: I found an error in the Notes section of the attached stack file, and just re-posted it with the change. If you downloaded before now you may want to get this update.

The differences are NOT as minor as you think.

[1] The font tag HAS to be removed. It will never work with it in.
[2]The color diff is also significant because the inline CSS which is caused by the “style” attribute modification cannot use the old color designation because it belongs to the old font tag. It would never work with the old color designation even if you used the correct style attribute.
[2.1] Replace "-color:" & quote & "#" with "-color:#" for the part of the style attribute "background-color:" to correctly accommodate the color number that follows needs to be done right.
[3] The span tag is absolutely necessary else the CSS style for whatever attribute is designated (not just for the background color attribute), would always apply to the entire paragraph <p> tag and not just the PART of the line you need it to be in. There will be many cases where the background colors will not be applicable to the entire line so it is CRITICAL to include the <span> tags EXACTLY where they are.

If ANY of the numbered items above is done wrong you will not get the background color at all or you will get it in the wrong parts of the line. Trust me on this, I ran all kinds of test cases and on ALL the previously specified browsers to verify it will only work with the right tags and as positioned within the lines as specified above as far as inline CSS is concerned.

The bottom line here is you will never get the background colors with the present LC html conversion. You have to make the specified modifications to make the background colors appear. Only when they appear on the web page can one select and copy the pertinent lines and paste it successfully into most existing desktop and online word processor apps.

I will start looking over your new clipboard example and get back to you if I have issue understanding it since the old example just leaves the html source in the clipboard and this is not what needs to be copied. What needs to be copied is the modified launched web page in order to select the displayed contents and copy that to the clipboard. This is not the same as copying the html source into the clipboard.

Thanks for all your help.

Ed_Ray wrote:I will start looking over your new clipboard example and get back to you if I have issue understanding it since the old example just leaves the html source in the clipboard and this is not what needs to be copied.

I have not posted any other example in this thread, nor have I seen an example here that uses the fullClipboardData array.

Three clicks to test, and ultimately just one line of code to do the deed. Worth the minute it takes to review.

Also, I consider the scripted solution a workaround, and based on what I was able to find by exploring the various clipboard options available to us I've sumitted a bug report to include background color among the other style info that already gets mapped automatically to the relevant OS structures:
http://quality.livecode.com/show_bug.cgi?id=19209

For Jacque;

[1] Does send "copyFix" to me in 1 mean send that message to myself in 1 second?

[2] Don’t understand why I need to send a message to myself when Ctrl-C is executed. Why can’t I just immediately do the “put the clipboardData["html"] into tHTML” part as soon as the copy is done?
I tried it doing it immediately without sending any message to myself and the results were the same (info was correctly put in the clipboard) so what is the point for doing this?

[3]The last “set the clipboardData["html"] to tHTML” still just puts the html source code into the clipboard. This is not what we need copied into word for windows or other word processor. Plus nothing gets copied into the word processing app anyway. What am I missing here?

Thanks.

Ed_Ray wrote:[1] Does send "copyFix" to me in 1 mean send that message to myself in 1 second?

One tick, which is a sixtieth of a second. If there is no time measurement indicated, it defaults to ticks.

[2] Don’t understand why I need to send a message to myself when Ctrl-C is executed. Why can’t I just immediately do the “put the clipboardData["html"] into tHTML” part as soon as the copy is done?
I tried it doing it immediately without sending any message to myself and the results were the same (info was correctly put in the clipboard) so what is the point for doing this?

The copyKey and commandKey messages are sent before the new text is placed in the clipboard. Whatever you have from a previous copy is what you'll see if you examine the clipboard when the handler triggers. If you are seeing the same thing as before, it means you copied the same text before. The purpose of the intercept is so that you can interrupt or prevent the actual transfer of data to the clipboard. In my example, I interrupt in order to send the command to fix the clipboard contents once it is available, which will happen in 1 tick. The wait is probably longer than necessary, it could probably be zero.

The "pass" command allows the copy to take place. Without that, copying would be blocked (not to mention all other keyboard shortcuts.)

[3]The last “set the clipboardData["html"] to tHTML” still just puts the html source code into the clipboard. This is not what we need copied into word for windows or other word processor. Plus nothing gets copied into the word processing app anyway. What am I missing here?

If you look closely at the html that results, "bgcolor" is changed to "background-color" so they aren't the same. Since you don't think that's sufficient, use the handler as an example to alter the clipboard content in whatever way you think will work. If that means inserting span tags, you can do that pretty easily (but I still don't think they are necessary; Word should be able to read font tags.) You can substitute anything you like in the altered HTML, then re-set the clipboard htmltext to the result.

I agree with Richard that fullClipboardData is probably a better fit, after seeing the responses on the mailing list. That's a fairly new implementation that I haven't used much, but it sounds promising. The main point is that you can update the clipboard however you want, you don't need to go out to a browser. You only need to figure out what should be there.

The fact that not even plain text gets placed into Word is worth pursuing. If the fullClipboardData doesn't produce even plain text when pasting, then I'm still inclined to think it's a different bug that needs fixing. Are you able to paste into Word if you copy plain, non-styled text from LC?

Jacque; with regards to your "send "copyFix" to me in 1 tick example;
[A]
I do it in a different way with less steps that does not seem to require the sending of a message to myself
and I don't need to pass the commandKeyDown message to make the action (copy) happen.

To make sure it just wasn't info left from the previous clipboard instance like you said I should check, I empty the clipboard out first every time and I can still make it work (meaning have the clipboard filled in with the original user selection without a delay or message to myself and no passing)

Here is the code. Seems to work ALL the time with new/different user selections. What do you think?

on commandKeyDown theKey

if theKey is c then
if selectedText(field "SubStack2Card1Field")=empty then exit commandKeyDown
set the clipboardData["html"] to empty
copy
#This "copy" with no arguments above, AUTOMATICALLY copies the currently selected object or text to the clipboard.
put the clipboardData["html"] into tHTML
#See the tHTML var gets the right copied info without going through all those extra steps and self messages and without needing to pass the message.

end commandKeyDown

Another related note:
From looking at the examples below from the dictionary, it seems that you only pass the message when you don't want to do a required action (opposite of what you are stating). This implies if you want to do an action (like a copy) you just execute it in the current handler without passing it.

From the samples it seems you pass it only when you rather some one else down the path like the stack do something with the keystroke and not the current handler with the focus on the current card. Note. The two samples seem to match up with my previous assertion of taking care of the copy action myself without passing a message to make the action happen.

Are the examples wrong or am I misunderstanding the two dictionary samples below?

on backspaceKey -- in the script of a field
-- clear the whole field instead of removing one character:
put empty into me
end backspaceKey
# See the action done right now in the current handler with NO passing required to make the action happen

on commandKeyDown theKey
if theKey is "5" then go recent card ELSE pass commandKeyDown
end commandKeyDown
#See the pass only happens if you don't want to take care of the action yourself in the current handler
#with the focus on the current card, NOT that you have to pass the message to make the action happen

=========================================================================================

Now back to the end part where the html is rectified with all the right tags, style form etc.
then we do the "final"
set the clipboardData["html"] to URL("file:" & defaultfolder & "/UserSelectedText.html")
Note: "UserSelectedText.html" is the file with all the html source code fixes that if launched, one would see all the rectified text colored backgrounds displayed.

The issues:
[1]When I pasted from the clipboard into LC things like a new field or the message box the bold and italics were retained but NOT the colored text backgrounds. Question since an LC fields or message boxes are not web browsers why don't you just see the html source text when the clipboard data is pasted into them rather than the represented visual output due to the html code?

[2] If I paste ANYWHERE and in any windows app outside of LC (like into word for windows, wordpad, notepad++) NOTHING is pasted not even non formated text. Nothing!!......big problem!

Very Important Question: Since we are not directly selecting and copying the colored text backgrounds from a launched web page, why were you expecting to get anything other than the html source text pasted back onto a word procesing document from the clipboard in which one previously copied only the html source text into?

Results Conclusion:
[1] I don't care so much about the colors not working inside LC after a clipboard paste that much, since I have my original LC results fields with all the right colored text but this should not be happening inside LC (colors missing after a paste) so you probably need to look into this right?

[2]Is VERY problematic because then this solves NOTHING and we will then have to launch the remedied web page to re-select/copy the colored backgrounds in order to be able to paste the colored highlights into supported word processors outside of LC like my custom code was doing when we ran into this problem.
========================================================================================
[C]
<Span> tags need shown with a tangible example:
<p>Replacement string value for Match 7:=<i><b><span style="background-color:#F9C3ED"><img src="project-GoodNight.bmp" alt=""></span></b></i></p>

Note without the span tag the line selection between the paragraph tags which was uncolored in the first part of the line and colored on the second part of the line would both have the same colored background since the style attribute would now belong to the entire paragraph which would be incorrect. Worse than that is that doing this one has changed a regex match or replacement hilight so the meaning of the output has been inadvertently and insidiously changed to give a wrong result to the user. This can NEVER be allowed to happen.

The original font tag essentially had a "virtual" span built into it by means of where the start and end font tags were situated within the line since a line could have multiple font tags as in the case where text can have multiple foreground colors. Once the font tags are removed and replaced with inline CSS style attributes, one has to keep track of where a span starts or ends. Luckily by observing where multiple open font tags had existed in a same line, the replacement spans can align with their prior placements replacing them correctly per line.

In the user selection example I had previously sent you, what you saw was paragraphs where the span just happened to be the entire line but that was just an example. In reality many user selections can very well run across non colored text and colored text OR different colored text merged together as part of the selection and since LC makes every line even ones that should be together a paragraph with blank spaces separating them, something that I feel should have not been done that way, you need to provide the specified separations with the span tag.
=================================================================================
[D]
Lastly when you talk about "I agree with Richard that fullClipboardData is probably a better fit", what does "fullClipboardData" mean and why is it supposed to be better? I don't see it mentioned anywhere in the dictionary.
Perhaps a tangible example could help.

As always thanks for all of your help.

Ed_Ray wrote:Lastly when you talk about "I agree with Richard that fullClipboardData is probably a better fit", what does "fullClipboardData" mean and why is it supposed to be better?

It's explained with a demo that lets you explore the differences between the various clipboard arrays LiveCode offers in the stack I attached to my message for you yesterday, a few posts up.

I don't see it mentioned anywhere in the dictionary.

Which version of LiveCode are you using?

Perhaps a tangible example could help.

See above.

Sorry, your message is too long to reply to in detail.

I do it in a different way with less steps that does not seem to require the sending of a message to myself
and I don't need to pass the commandKeyDown message to make the action (copy) happen.

Your way will work too, LC often offers more than one way to do things. My method passes the message so that the engine will handle both replacing the clipboard content accurately and doing the copying, freeing me from having to do those things in script. Your method is manual. Both will work.

It's true you pass messages when you want something farther downstream to handle it. That's why I pass the command key sequence, which then passes to the LC engine for handling. I generally follow the rule to "let the engine do it" whenever possible. It's faster, more reliable, and often makes the script shorter. But there are times when you want to do all the management yourself, which is okay too.

It is necessary to pass the commandKeyDown message whether or not you handle the copying yourself. If you don't, no keyboard shortcuts will work at all. In your handler, you wouldn't want to pass the message if the key is "C" because you're handling all the details there, but you'd want to include an "else" clause that passes all other keys. If you don't, the engine will never know the user has pressed command-S, V, X, O or any others.

For Jacque and FourthWorld;

The most important thing from my last post 45 is that after we get the remedied/modified web page contents into the LC clipboard by “set the clipboardData["html"] to fixedHTML” the following conclusions were observed:

If I paste ANYWHERE via Ctrl-V in any windows app outside of LC (like into word for windows, wordpad, notepad++) NOTHING is pasted not even unformatted text. Nothing!!

Attempting to do this programmatically by doing something like:
put clipboarddata["html"] into X or set htmltext of X to clipboarddata["html"] where X is a window external to LC such as word processing won’t work since LC does not provide a means to communicate with windows that are external to LC (if LC did guess what? Then it would work).

Looking at my past programming notes I had already tried to use the clipboard with the modified info more than two months ago but abandoned the idea when the results then were the same as they are now…unsatisfactory

I just wanted to follow you in the last three posts in hopes that I would run into something new or different that would make it work but as you can see this has not happened hence the reason to launch an external window that had my unique handle based on my unique windows title.

Auto re-selecting/copying from the launched window seems to be the only way to be able to paste the colored text backgrounds into most true word processing documents (desktop and online versions)

So unless you have any other ideas I will have to go with the launching of the remedied local web page as I was doing before. At least I proved that you can in fact copy colored text backgrounds into most word processors, if you do it the right way.

I just wanted LC to consider making the simple functionality of:
[1] Getting a handle from a windows that it launched so I could tell it came up and is now the active window
[2] Allow sending of keystrokes to that unique window (and no one else). Ctrl-A (selecting all) and Ctrl-C for copying
[3] Closing the window based on the acquired windows handle.

Into a dll or com object based LC extension.

This would preclude having the LC developer from having learn three or more scripting languages, learn their IDEs , test and debug them troubleshoot their interface with LC etc. Way too much work just to execute the simple functionality specified above in order to have my LC app to be used in three different OS (windows, Mac os x and linux).

For the custom exe I have created so far supporting windows OS and some tools that allow keystrokes and allow window to interact with other windows in linux and mac os x, for the intent of only interacting with my own local window, all worked WITHOUT any security warnings of any kind in those OS. So there really are no security issues as long as one interacts EXACTLY as I have stated throughout these posts.

Thanks.

@Ed:

I just tested on Windows, and using the copy command in LC 9 dp4 works as expected out of the box, allowing me to paste into Wordpad with all styles preserved, including backgroundColor.

What version are you using?

Also, I noticed you're still working with the clipboardData, and not the fullClipboardData as suggested several times above. Have you tried the demo stack I prepared for you?

Lastly, I didn't see where you'd submitted the bug report for the empty Windows clipboard, so although I was only able to reproduce it when modifying the fullClipboardData["html"] property (which is apparently no longer needed in v9 on Windows anyway), I took the time to submit a bug report on that for you:
http://quality.livecode.com/show_bug.cgi?id=19225

Follow-up: the bug I'd reported yesterday has been fixed, for release in the next builds:
http://quality.livecode.com/show_bug.cgi?id=19225

I am using LC ver 8.1.

In reference to the LC 9 dp4 version copy command are referring to the actual “copy” command or the Ctrl-C keystroke or will both copy to clipboard correctly in that version?

I was still working with the clipboarddata because all the examples and recommendations to do things as we were working the issues were still referring to the regular clipboarddata in the actual script samples. None of the ongoing examples included the demo clipboard items..

The other issue was that I had mentioned that the fullclipboarddata and the rawclipboarddata references were not found in my LC 8.1 dictionary So I don’t like proceeding with something I don’t understand what it means. My regular dictionary no longer comes up within the IDE so I have been using the online LC 8.1 version via this link: https://livecode.com/resources/api/#livecode_script/%24.

You can see that if you put in “clipboard” in the search box very little comes back certainly not fullclipboarddata and the rawclipboarddata.

Nevertheless I did exercise your demo and the only one that retained the right html code (includes the inline css mods), was fullclipboarddata[“HTML”]. Unfortunately when I used any word processing app to paste the information (tried 4 different apps) via Ctrl-V, I got nothing on the screen. Not even unformatted text.

But if I launch the modified web page and select/copy all directly from the screen then go to the same 4 apps that did not paste before they now all get the pasted colored information perfectly.

So perhaps you can recommend something here in case you feel I missed something from the demo.

Thanks for submitting the bug report for me.

Ed_Ray wrote:I am using LC ver 8.1.

Thank you for that. It's very helpful to note the version number so we can better understand the details of what you're experiencing.

You may want to try the current Stable build, v8.1.2.

All builds going back several years are available here, with the most recent at the top:
http://downloads.livecode.com/livecode/

When I test the current version on Windows 10 I'm able to copy text from LC with the "copy" command, and pasting into Wordpad preserves all style attributes, including backgroundColor.

In reference to the LC 9 dp4 version copy command are referring to the actual “copy” command or the Ctrl-C keystroke or will both copy to clipboard correctly in that version?

The LiveCode IDE is written in the LiveCode language. Any UI elements, such as the Edit menu, ultimately use the same language we do in our own projects.

To simplify things in a way that most closely matches what we'd deliver in a standalone, the example stack I prepared for you has a fairly short script in its "Copy Field Text" button; aside from a little housekeeping, the only relevant command there is "copy" (line 3).

I was still working with the clipboarddata because all the examples and recommendations to do things as we were working the issues were still referring to the regular clipboarddata in the actual script samples. None of the ongoing examples included the demo clipboard items..

Yes, the team has been hard at work enhancing the LiveCode language. As with any evolving language, over time newer elements will have less supplemental documentation available for them than older ones that folks have been using longer.

That was one of the reasons I created the example stack for you, and added at least brief notes there describing the history and purpose of both the clipboardData and the fullClipboardData arrays.

The other issue was that I had mentioned that the fullclipboarddata and the rawclipboarddata references were not found in my LC 8.1 dictionary So I don’t like proceeding with something I don’t understand what it means. My regular dictionary no longer comes up within the IDE so I have been using the online LC 8.1 version via this link: https://livecode.com/resources/api/#livecode_script/%24.

You can see that if you put in “clipboard” in the search box very little comes back certainly not fullclipboarddata and the rawclipboarddata.

It may be that the web copy of the Dictionary needs an update (to be honest, I'm not even sure why they post the entire Dictionary; seems a lot of extra overhead to maintain). I filed a bug report on that ( http://quality.livecode.com/show_bug.cgi?id=19232 ), suggesting that either its updates be automated, or perhaps the web copy could be simply removed altogether to avoid confusion among users who may be using a different version than the one reflected in the web copy of the Dictionary.

Rather than leave LiveCode while I'm working in it, I find it more convenient to use the Dictionary provided right in the IDE (see the button toward the right-hand side of the main toolbar). The IDE's Dictionary is always the most recent available for the version it's included in.

I've never used v8.1, but I see that in the current Stable build, v8.1.2, the Dictionary includes "fullClipboardData".

Nevertheless I did exercise your demo and the only one that retained the right html code (includes the inline css mods), was fullclipboarddata[“HTML”]. Unfortunately when I used any word processing app to paste the information (tried 4 different apps) via Ctrl-V, I got nothing on the screen. Not even unformatted text.

That fits the description of the fullClipboardData bug I noted above.

But since the current version appears to copy all relevant style attributes, the workaround of altering that array's "html" element doesn't appear to be needed.

But if I launch the modified web page and select/copy all directly from the screen then go to the same 4 apps that did not paste before they now all get the pasted colored information perfectly.

My understanding of the purpose of using a separate program like a browser was as a workaround for not being able to copy directly from LiveCode in a way that retains the backgroundColor.

Since the current version appears to address that, the complication of adding another program to the mix would seem unnecessary.

Is there a benefit to the user in adding a browser app into this procedure that I've overlooked?

So perhaps you can recommend something here in case you feel I missed something from the demo.

As a general rule, whenever you run into a bug or limitation in LiveCode it can be helpful to try the most recent Stable version.

If the problem is still evident there, then try the most recent Developer Preview edition. I often find that by the time I encounter a bug others have already reported it and the team has already fixed it, as seems the case here.

If a problem persists even in the most recent Developer Preview build, then I file a bug report. When submitting a report, if I provide a recipe for reliably reproducing the problem I find the team can usually identify and resolve it quickly.

Thanks for submitting the bug report for me.

Happy to help.