----- Original Message ----- From: "Howdy-Tzi" <[EMAIL PROTECTED]> > > > application will automatically handle whetever the user pastes in. > > "Whatever" is just not feasible. Video? Flash? MP3?
It doesn't have to handle /everything/ I just want to get as close to it as possible so that Joe Sixpack doesn't have to strain his brain too much to get stuff to work. > > The main > > things I am interested in are formatted text (including hyperlinks, > > ideally) > > and images. > > Now that you can do. After the paste you can test for the member type. I know I can do that with images and text, although I would like to avoid pasteClipboardInto altogether. I've tried looking for a small Shockwave safe Xtra that might do it with no luck. Seemingly BuddyAPI has some clipboard functions, but it's not Shockwave safe, so no good. I suppose if one doesn't exist I could put "write a clipboard Xtra" in my todo list for the future :-) > If it's a bitmap you don't need to know much more. If it's text you > need to look for hyperlinks (in the case of HTML) or otherwise assume > it's RTF/text. Only HTML, of course, would have a hyperlink, which > would mean you'd just have to do an offset or similar search on the > suspect item's HTML for an </a> closing tag. If it lacked links > rendering it as RTF would be effectively the same as rendering it as > HTML. Ah, the problem with the default clipboard handling is that it only treats text as plain text. This means that hyperlinks and formatting data are stripped out, so there is nothing to look for. > I think I would actually include buttons in the app. "Paste text", > "Paste HTML", "Paste image". I know it's not as transparent as you > might like, but it might really save you a lot of headaches later. > Users work off those implicit cues, and stay within the presumed > acceptable data types (most of the time). It's not really an option. I'd rather limit the clipboard handling to plain text as it is now than make it more complicated. The whole point of an application like this is userfriendliness. The user should not be expected to even know what HTML is. > > I'm also trying to remove all dependencies on text members so I > > can replace them entirely with imaging Lingo based UI components. > > You will have to have an interim step that uses text members for that. Yeah, I'm trying to decide the best way to go about this now. I can live without text members until it gets to clipboard handling. If I use pasteClipboardInto, I can use a temporary member and delete it afterwards, but I get a warning dialog. The other method I have in mind involves a text member hidden offscreen that always has the keyboard focus. I can attach my keyboard handler to this as a behaviour and trap all events except CTRL+V, which I pass. This gets rid of the alert, but will mess up the event queue. Plus, I don't really want to have anything on the stage, but I suppose I can live with a single member for this. The advantage of pasteClipboardInto is that it allows me to paste images as well as text, but if I can't find a way to paste formatted text I'd rather keep things the way they are which allows people to upload images directly, but does not allow them to be pasted in. > This is an interesting project, I must say. I presume you're going to > be sending format information to a CGI, or doing setPref to keep it all > in the page once done? Because, of course, saveMovie is also not > available in Shockwave... It's linked to a PHP/MySQL backend. - Robert [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
