LiveCode Forums.

Oh, and on a b*tchy note: it's generally not a bad idea to trawl the Forums before you reinvent the wheel:

https://forums.livecode.com/viewtopic.php?t=14342
-

dunbarx wrote: Wed Apr 17, 2019 2:58 pm I had early on mentioned the sample stacks. I was thinking more of sample handlers..

We have at least four options for satisfying that goal:

1. Local stack: The old MetaCard example Bogs showed is a good one, easily reproduced in minutes. Any of us can make one for ourselves easily.

2. revOnline ("Sample Stacks"): There "stacks" is merely a reference to the container format; "Code" is among the four types suggested for upload there. The advantage of using it is that it exists, is explicitly designed for this purpose, and is non-trivial to reproduce. Making resources shareable requires account management, with authentication, password reset, and a whole host of other features that can easily consume a hundred hours or more to design, test, and refine for use, in addition to server admin tasks.

3. Roll our own: Given sufficient time and interest, it's expensive but not necessarily prohibitive to roll our own replacement for revOnline. But if we were to do so only for the purpose of providing a better UI for one of revOnline's four suggested data types, in addition to the non-trivial time required for the team designing and building it we also introduce a usability issue for end-users: once delivered they would have two tools to choose among, and they'd have to remember which one is used for which type of shared resource.

4. Github: If having multiple places for shared resources based on type alone is not seen as a significant impairment to the user experience, we can at least avoid the time sink of needing to reproduce a purpose-built system from scratch by using an existing one. Github is designed for exactly this, sharing code examples.

There may be others as well. These are just the pros and cons of the options that come to mind at the moment.

Am I not making myself clear? If I copy a bit of text from a webpage, what lives in the clipBoard is likely very heavily styled and may contain properties (such as textSize) that may differ from one part of that text to another. If I then paste directly into a LC field, say, all that styling and all those properties are preserved.

Right?

Now then, oftentimes I want just the "raw" text. Not the styled text. The raw text. Not the styled text.

What am I missing? It must be something.

Re-read Klaus' comment, and mine, and experiment. When you pass a string to a function, that's what the function receives, the string value. If you want to also include the style metadata, you need to use one of the special forms for that: a styledText array, or plain text in htmlText or rtfText formats.

Try this: in whatever stack you've tested that function in, temporarily replace it with this one and let me know if the result you get is any different: LC makes using the Clipboard super-easy, masking the underlying complexity in ways that can lend themselves to this sort of conceptualization issue. We get a one-liner to paste, and it carries both the string value and styling metadata along for the ride. This simplicity can cause us to forget that LC is working really hard under the hood to make that happen, slicing and dicing complex OS data structures. These are exposed to us in the clipboardData array, very useful to poke around in to appreciate the work the engine does to keep our lives simple (and also providing useful insight into the many options recent versions of LC have provided for even very specialized clipboard handling).

OK. "return tText"

And this is simpler even than "set the clipBoardData to the clipBoardData".

I was determined to promote user handlers, and may have been a little obtuse about what you and Klaus were trying to tell me. I thought you all were saying that you did not understand what sort of text was IN the clipboard, as opposed to ways to get "raw" text out.

So thanks all for sticking it to me. I mean sticking by me.

Craig

so I'm at a loss to conceive of an input that can be passed to it that isn't already plain text.

It works because when you get a text chunk, in this case a single character, no styling instructions ride along with it. Craig could have easily gone word by word or line by line.

Since the clipboardData already has a plain text version in its array, extracting that is faster and more efficient. But the parsing example extracts the same thing, only in smaller chunks.

dunbarx wrote: Wed Apr 17, 2019 4:56 pm OK. "return tText"

And this is simpler even than "set the clipBoardData to the clipBoardData".

I was determined to promote user handlers, and may have been a little obtuse about what you and Klaus were trying to tell me. I thought you all were saying that you did not understand what sort of text was IN the clipboard, as opposed to ways to get "raw" text out.

Simpler still: once we recognize that the value going into either function is already the plain-text string, we avoid having to call any function at all.

So thanks all for sticking it to me. I mean sticking by me.

I included you in the special recognition portion of last year's Community Roundup session at LC Global for exactly this reason: you don't think like most people. This thread is a rare case of merely overthinking, but always you come at things from an angle few others see. And not surprisingly, your threads tend to spawn some of the longer and more enjoyable discussions.