window to window functionality lacking?

[jacque]

I need to fix another livecode limitation where it can’t retain text background colors OUTSIDE of livecode as in the case I have a livecode field that has my output results but the user wants to copy these colored highlights outside of livecode say to a word processing app

LC faithfully includes all styling information in the clipboard when text is copied. It is up to the receiving app to interpret that styling. Text background color is almost never supported in other apps, it is a LC-specific field feature, but I vaguely recall that once in a while it works in some apps. There is nothing LC can do about this. Either the receiving app supports background color or it doesn't.

My fix to this is to launch my OWN LOCAL html file from within livecode that is COMPLETELY MINE not some else’s sandboxed app or someone’s information stored on someone’s remote web server. This launched local html file contains an on-the-fly fix to being able to retain text colored backgrounds.

Sorry, I still don't understand how this would work. "Launch" is a specific LC term that means to open another app. If you launch, for example, a browser, you are no longer in control of what that browser does. You may mean that you open a new LC stack/window. If so, you can control the input and output of fields in that stack and, to some extent, the content of a browser widget in the stack. But I don't see how that will help you transfer unsupported text styling to an app that doesn't support receiving it.

While doing this, the OTHER livecode limitation I need to overcome is that livecode does not seem to provide a way that MY OWN launched web page can communicate back to my current livecode card telling it that it now exists and is now active window.

Again, if the window you launched is in an external browser app, you have lost control over it. You would need to use a system-level extension or DLL to talk to the other app. That is what "do as <script language>" is for in LC.

This is not a limitation of LC per se, it is a limitation of all apps. The examples you posted originally of languages that allow cross-app communication are actually installed as system-level DLLs on Windows.

So in summary livecode does NOT provide the tools to do some VERY SIMPLE task to MY OWN locally launched html file. These are:
[1] Let me know my locally launched web page finally emerged and is now the active window
[2] Let me send it Ctrl-A and Ctrl- C keystrokes for selecting and copying MY own programs information to MY OWN html file.
[3]Let me close MY OWN local html file after leaving it up for 2 secs worth of user feedback.

If the window you opened is in fact a LC stack, then you have complete control over the clipboard and there is no need to simulate mouse clicks or keyboard shortcuts. You can get the clipboard content, manipulate it in any way you like, set the clipboard content, insert any text into any part of a field or set the content of a browser widget to anything you like. You can copy, paste, edit entirely by script without simulating user actions. You can even create an entire web page by script and set the content of a browser widget to show it. But again, I don't see how this will help you get styled text into an app that does not support it.

Jacque, regarding another unanswered but related post whose subject states: “Unclear on using “sample stacks” from the livecode toolbar” can you be kind enough to provide me guidance there so I can distribute my app and quell the past forum complaints folks have had regarding livecode regular expression functions. I think this app has resolved all of those issues and will make many people happy.

In the LC toolbar there is an icon named "Sample Stacks". This opens an interface to stacks that users have uploaded to share. You will need to create an account there, and then you can upload your own stacks for download. (I don't know if you've looked at the latest 8.1.3rc1 release, but it has fixed the slowdown when using regex in certain situations.)

[Ed_Ray]

For richmond62;
No. I do not want to send a keystroke to some ones application.

I merely want to launch my OWN local html file (this is not some ones else's app) that contains My own information NOT some one else's information and simply select and copy all/part of my OWN information from it (which belongs solely to my app not anyone else's app) so I can paste my OWN information wherever I want.

Clearly by now it should be understood that ALL manipulations described above is NOT happening in or around anybody else's app.

I consider this launched window "external" to livecode ONLY because it was not created inside livecode and thus I can't give it a livecode object name. Since I can't give it an object name I can't use livecode commands such as "type", "send" or the livecode keystroke and mouse click commands etc.

Although this window is external it was launched by MY OWN app, contains MY OWN information and never at any time is it attempting to communicate with some else's window/app/whatever.

Because it is my OWN window with my OWN information and the manipulations ONLY effect MY APP, I am stating then there is no valid reason why livecode does not provide the means to let me relate to my OWN window and my OWN information such as for example when I launch my own window from inside livecode.

One way this could be done is for livecode to allow me to name the object at time of launch within the launch/open process etc commands and have livecode send me a message based on that object initiation when my own launched window finally emerges and becomes the active window so that subsequent livecode keystrokes or mouse clicks don't get prematurely sent and missed.

This is precisely what happens with all the other languages I previously stated. They already do this which is why I am recommending having livecode do the same.

So for my explanation above and in all the prior posts, "External window" was never meant at any time to mean some one else's app. It had ALWAYS meant my OWN window, my OWN information my OWN everything (Unfortunately although all this belongs to MY OWN app my OWN etc as previously mentioned, livecode does not provide the means to create it and have the object named within livecode at time of MY OWN stuff being launched).

Thanks.

[ClipArtGuy]

Does this local HTML file need to actually launch, or could you simply use "Get URL" to read your local html into livecode, put it into a variable, and then extract your required data?

[jiml]

Ed,

If you create a document with LiveCode and display it within a LiveCode window your app will have complete control over it.
If, however, you create a document with LiveCode and display it within another app (by using the 'launch' command) your originating LiveCode app will no longer have control over the copy being displayed within the external app.

But this is not a limitation; it is a blessing.

There is something called interprocess communication, which allows different apps to speak to one another. The extent to which an app cedes control to other apps varies from app to app. On MacOS this is accomplished through Apple Events that are usually made scriptable through AppleScript. On Windows we have Windows Shell Host. You have been given good examples of how to access interprocess communication through LiveCode.

[richmond62]

I merely want to launch my OWN local html file

I wonder exactly HOW you propose to launch an html file without
using a web-browser to do that.

[AxWald]

Hi,

I will give you a concrete example to make this crystal. I need to fix another livecode limitation where it can’t retain text background colors OUTSIDE of livecode as in the case I have a livecode field that has my output results but the user wants to copy these colored highlights outside of livecode say to a word processing app so that he can manipulate all or part of the results once the livecode app has been closed.

My fix to this is [...]

Don't try to fix what needs no fixing. It's not LC (that correctly copies the backcolor!), it's the receiving program that obviously only accepts the RTF part of the clipboarddata. As shown here, in one of your threads, 1.5 months ago.

For your desire to control other processes, in Windows you have VBScript, JScript, the Powershell as well as a full fledged Linux Bash shell now - and if that isn't enough, there's AutoHotkey (& others). All easily to use from within LC, and specialized to fulfill your task. No need to invent the wheel again in LC, for the umphteenth time, right?

And - be careful! What you try to do can quickly get you flagged as "malicious behavior" by some overzealous snake oil (especially manipulation of external browser windows, lot's of malware is doing exactly this), and can fill your mailbox with angry complaints from your customers.
Or, even worse, can get your kid a game ban just for the presence of your innocent & insufficiently hidden AHK process ...

Have fun!

[Ed_Ray]

[Jacque stated:]
“LC faithfully includes all styling information in the clipboard when text is copied. It is up to the receiving app to interpret that styling. Text background color is almost never supported in other apps, it is a LC-specific field feature, but I vaguely recall that once in a while it works in some apps. There is nothing LC can do about this. Either the receiving app supports background color or it doesn't”

Jacque, the problem is that LC is using old font style html that is no longer supported in most modern browsers. If you put that into an html page (LC allows one to do so via “put htmltext of field A into url file: B” and then try to copy the selection that is now in the html file into any word processing app outside of livecode the colored backgrounds are NOT retained.

If you GET RID of these deprecated LC font tags and replace them on the fly with correct inline css styled tags and syntax – this is the ACTUAL true livecode limitation and how to bypass it, you will get a selection that you can copy into virtually ANY word processing app and guess what? If you do what I just stated, ALL the background colors are RETAINED!
If livecode would have done this to begin with, any copied selection would have retained their text background colors in or outside of livecode.

So if you do the right thing, Text background color will almost always be supported in many if not all word processing apps. This is not a mere opinion it’s a fact based on my verifying my fix on hordes of non livecode apps like word processing apps after I pasted my modified web selection into them.

Before my fix no word processing app retained the colors when copied from the original LC created web page. After my on the fly web page modification, every word processing app that gets the pasted selection now retains the colored backgrounds. Let me list the apps that I copied over the colors (EVERYONE of them work now when they did not work before my fix).

Color text backgrounds selections/copies are now retained and have been successfully pasted into all these DESKTOP word processing apps:
word for windows, open office writer, libre office writer, free office writer, WPS office writer, ABI word among MANY others.

Color text backgrounds selections/copies are now retained and have been successfully pasted into all these ONLINE word processing apps:
ThinkFree, Zoho writer, google docs, only office personal, MS word online, live writer, shutterBorg among MANY others.
 
[Jacque stated:]
“Sorry, I still don't understand how this would work. "Launch" is a specific LC term that means to open another app. If you launch, for example, a browser, you are no longer in control of what that browser does. You may mean that you open a new LC stack/window. If so, you can control the input and output of fields in that stack and, to some extent, the content of a browser widget in the stack. But I don't see how that will help you transfer unsupported text styling to an app that doesn't support receiving it. “

I don’t mean to open a new LC stack. I mean to open a new window unique to my app that launched it regardless if there are other surrounding windows. It’s MY OWN unique window within that browser app with MY OWN unique window HANDLE different from ALL the other browser windows handles so there should be no valid reason why I should be losing control of that unique window/handle.

LC should internally figure out that handle based on a unique windows title I have inserted into that locally launched html file. Once I have that window handle I would have full control of that window which is uniquely MY OWN window.
Currently that is how all those other scripting languages mentioned in all my prior posts let me know the launched window became the active window and can then start receiving keystrokes and mouse clicks even though they are a windows external to LC.

This is the basis of my custom made exe file which does all of this perfectly as stated above. All I am saying is if these other scripting language can easily do this based on keeping track of a unique handle/window title even if a launched window happens to be around many other windows, there is no reason why livecode can’t provide this same support.

[Jacque stated:]
“But I don't see how that will help you transfer unsupported text styling to an app that doesn't support receiving it. “

See my answer to your first quote. It clearly states how I was able to “transfer unsupported text styling to an app that doesn't support receiving it.”

It isn’t that the apps did not support receiving the selection, it’s that the original html based selection from LC had deprecated tags within the html source that when selected and copied would not allow the color to be retained. I proved this by making the right modification to the web page to the point that when I selected/copied/pasted the modified web page selection, every single word processing app (100 % of them) outside or inside livecode we tested, retained the text background colors correctly.

 
[Jacque stated:]
“Again, if the window you launched is in an external browser app, you have lost control over it. You would need to use a system-level extension or DLL to talk to the other app. That is what "do as <script language>" is for in LC.

This is not a limitation of LC per se, it is a limitation of all apps. The examples you posted originally of languages that allow cross-app communication are actually installed as system-level DLLs on Windows.”


As stated in my prior statement based on a unique windows title/handle for my particular unique window, I should not have to lose control of my window as previously specified and explained.

A livecode extension / dll to do all of this is what I actually requested from day one of leaving such related posts to avoid having to use a mixture of many other scripting languages working together with the core of LC to get such simple tasks done.

From day one of my related posts, I wanted to avoid having to use other external scripting languages in conjunction with LC hence I want to avoid the use of the “do as <script” constructs or similar pigeon holed external script use.

Unfortunately we kept coming back in circles to this same point because LC does not seem to want to create these extensions/dlls and seems to prefer that the developer end up with a mess of sporadically glued scripting languages working in conjunction with LC in some convoluted manner just to get some simple communications tasks done. I would prefer to not have to do this hence the request to have LC support these simple tasks as a built in extension etc.


[Jacque stated:]
"In the LC toolbar there is an icon named "Sample Stacks". This opens an interface to stacks that users have uploaded to share. You will need to create an account there, and then you can upload your own stacks for download. (I don't know if you've looked at the latest 8.1.3rc1 release, but it has fixed the slowdown when using regex in certain situations.)"

Jacque;
I had already done what you stated (open an account, then do an upload – what to upload is the issue, I can’t upload just a stack, I have other files that have to be uploaded too but there are no provisions for this etc) for the “sample stacks” but there are issues with this and it won’t work as stated which is why I needed you to look inside the post titled “Unclear on using “sample stacks from the livecode toolbar”.

Inside there you will find the necessary details of the issues which will aid you in giving me guidance. Once you see the issue details in that other post, I am sure you will have everything you need to provide me with the necessary guidance.

Thanks.

[Ed_Ray]

To AxWald;

[You stated]
Don't try to fix what needs no fixing. It's not LC (that correctly copies the backcolor!), it's the receiving program that obviously only accepts the RTF part of the clipboarddata. As shown here, in one of your threads, 1.5 months ago.

Its an actual problem which I have resolved. Not a mere opinion. All of the same word processing apps that would not retain the colors outside of livecode NOW do so with my fix. Not some of them, ALL 100 percent of them which did not work before.

Explanation below.

The problem is that LC is using old font style html that is no longer supported in most modern browsers. If you put that into an html page (LC allows one to do so via “put htmltext of field A into url file: B” and then try to copy the selection that is now in the html file into any word processing app outside of livecode the colored backgrounds are NOT retained.

If you GET RID of these deprecated LC font tags and replace them on the fly with correct inline css styled tags and syntax – this is the ACTUAL true livecode limitation and how to bypass it, you will get a selection that you can copy into virtually ANY word processing app and guess what? If you do what I just stated, ALL, 100 PERCENT of the word processors we tested now retain the background colors. I am talking about the SAME ones that did not retain the colors when copied from the original LC web page whose source contained the deprecated font tags.

If livecode would have done this to begin with, any copied selection would have retained their text background colors in or outside of livecode.

So if you do the right thing, Text background color will almost always be supported in many if not all word processing apps. This is not a mere opinion it’s a fact based on my verifying my fix on hordes of non livecode apps like word processing apps after I pasted my modified web selection into them.

Before my fix no word processing app we tested retained the colors when copied from the original LC created web page. After my on the fly web page modification, every single word processing app outside of LC that gets the pasted selection now retains the colored backgrounds. Let me list the apps that I copied over the colors (EVERYONE of them work now when they did not work before my fix).

Color text backgrounds selections/copies are now retained and have been successfully pasted into all these DESKTOP word processing apps:
word for windows, open office writer, libre office writer, free office writer, WPS office writer, ABI word among MANY others.

Color text backgrounds selections/copies are now retained and have been successfully pasted into all these ONLINE word processing apps:
ThinkFree, Zoho writer, google docs, only office personal, MS word online, live writer, shutterBorg among MANY others.

I think this is enough proof.

[You stated]
"For your desire to control other processes, in Windows you have VBScript, JScript, the Powershell as well as a full fledged Linux Bash shell now - and if that isn't enough, there's AutoHotkey (& others). All easily to use from within LC, and specialized to fulfill your task. No need to invent the wheel again in LC, for the umphteenth time, right?"

I know I can do this functionality with other scripting language. That is what I reluctantly did by creating a custom executable with an external scripting language. Nevertheless If you followed the post from the very beginning you will see that the WHOLE point of this entire post was to avoid doing this as previously stated below:

"I am requesting a livecode extension or similar to do this because I am just trying to avoid making a Hodgepodge of different scripting language mixes and ending up with having to resort to crudely added bits and pieces of add on software and overly complicate their code unnecessarily to fit them in, defeating what may have been an original elegantly constructed piece of source code and adding a lot of wasted time to make this patch work do anything constructive”.

Plus seriously who wants to be forced to learn a million more languages to do "this" and to do "that" and "that".... when a fairly simple extension would suffice?

I am sure there are exceptions to what I state next but I have yet to see an elegantly constructed piece of code based on a mixture of different scripting languages that can easily be managed, changed, formally reviewed and concisely associated with continuously changing formal requirements and I have been managing and assisting programmers as a principal Systems Engineer on huge IT projects over thirty five years now.

Similarly, I have seen almost every possible combination of coding constructs some more painful than others but the most painful ones I had to review and send back to the drawing boards were the ones that were based on a huge patch work of different scripting languages.

Thanks.

[FourthWorld]

If you GET RID of these deprecated LC font tags and replace them on the fly with correct inline css styled tags and syntax – this is the ACTUAL true livecode limitation and how to bypass it, you will get a selection that you can copy into virtually ANY word processing app and guess what? If you do what I just stated, ALL, 100 PERCENT of the word processors we tested now retain the background colors. I am talking about the SAME ones that did not retain the colors when copied from the original LC web page whose source contained the deprecated font tags.

If livecode would have done this to begin with, any copied selection would have retained their text background colors in or outside of livecode.

Perhaps so. I would be very interested in seeing the code that does that clipboard manipulation.

[jacque]

After 2 pages of discussion, we finally get to the real issue. The actual goal is to replace some html in the clipboard. This is much different than the original request and doesn't require launching any other app at all. LC gives a tremendous amount of control over the clipboard content. You can likely do what you want in just a few lines of script.

Like Richard, it would be useful to see what "updated" html you want to use. But whatevern it is, put that string into a variable. Then:

Code: Select all

put <whatever the revised html is> into tNewHTML
put the htmlText of fld x into tHTML
replace "<font bgcolor=" with tNewHTML in tHTML
set the clipboardData["html"] to tHTML

You can trigger this with either or both a copyKey handler or a commandKeyDown handler. I usually use both just to cover all bases.

[FourthWorld]

Code: Select all

put <whatever the revised html is> into tNewHTML

Thanks. I'm familiar with the replace command. The part I'm curious about is the "whatever".

[jacque]

Sorry, I was answering the OP. I know you have the dictionary memorized.

[Ed_Ray]

For Jacque and FourthWorld;
Thank you for all your help so far. You guys are always very giving of your time. Really appreciate it.
======================================================================

A few things you have to keep in mind which you may not be considering:

[1] The revised html is based on an output result that is dynamic and can be different every time. So this is not static information
[2] The revised html is based on the selection the user makes of the output result anywhere from selecting everything from the output result which can be more than 100 pages of info, to the selection of a single char. So it won’t always be the entire field.
[3] It’s not as easy as just replacing the "<font bgcolor=” string, there are some additional tricky strings to be concerned about so what you recommended to do probably won’t completely suffice.
[4] I had already tried MANY times before to execute your “set the clipboardData["html"] to blah” recommendation

Unfortunately this only puts the SOURCE html into the clipboard and this is not what I want subsequently pasted. If you attempt to paste this into word for windows NOTHING gets pasted even though I would have thought that the unwanted source html string would have gotten pasted instead. Either way this is NOT what needs to happen.

This is why I needed to launch MY unique handle/titled fixed/modified html page windows on order to re-select/re-copy its local contents which NOW finally contains the needed background colors, then close the window after a 2 sec feedback to the user.

So based on was stated above, unless you can inform me of something else that I have missed, I think you still need to launch the html source in order to visibly see the background colors (not see the html source code) THEN you can select all, then copy the selection, then paste it into word for windows.

My custom executable (which I had been proposing to be done with a LC dll or com object extension), does all this. It waits for the launched window that has my unique window title, to become active before AUTOMATICALLY sending it a CTRL-A (select all) and CTRL-C (copy). The windows is then left up for two secs for user feedback then the custom executable automatically closes the window based on a acquired windows handle due to the original windows title.

Regardless, let me send you the part of my code that contains the recommended remedy which also shows me doing your recommendation in the past in a separate file perhaps you can if let me know if we need to do something else to make this work or if I have misunderstood some of your recommendations. The name of the file is: HtmlFileRemedyForJacque.zip

Note: Really just a .txt file but the forum did not allow me to send a .txt file so I changed it to a zip extension.
Thanks.

[FourthWorld]

Thank you for that script. I'd test it here, but it's a fragment with a lot of dependencies so I'd be guessing.

What does the original htmlText look like, and what does the htmlText look like after the end of the script?

[jacque]

I agree with Richard, what we need to know is the text of the "correct" html. The script will change, so what you are using now isn't too relevant.

BTW, it is easily possible to get the user selection rather than the htmltext of the whole field. See "selectedChunk" in the dictionary. LC is extremely flexible about text parsing; in fact, it's probably its greatest strength.