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
-
Gadget pane
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
-
- VIP Livecode Opensource Backer
- Posts: 9842
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Gadget pane
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.
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.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.
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:
Code: Select all
function makePlainText tText
return tText
end makePlainText
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Gadget pane
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
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
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Gadget pane
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.so I'm at a loss to conceive of an input that can be passed to it that isn't already plain text.
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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9842
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Gadget pane
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.dunbarx wrote: ↑Wed Apr 17, 2019 4:56 pmOK. "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.
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.So thanks all for sticking it to me. I mean sticking by me.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn