peter@sugar.hackercorp.com (Peter da Silva) (06/11/90)
In article <8886@wehi.dn.mu.oz> BAXTER_A@wehi.dn.mu.oz writes: > An suggestions for salvaging the clipboard??? A "clipfile:" device. Writing to "clipfile:0" would put something in the clipboard, and reading it would read it back out again. For dynamic clips, a "clippipe:N" device could be used, which would be basically a "pipe:" that went through the clipboard. This would make it trivial for programs to use clips. Right now it is (as you noted) not quite intuitive. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ My other car is a hot-air balloon. v "Have you hugged your wolf today?" `-_-'
BAXTER_A@wehi.dn.mu.oz (06/11/90)
Has anyone out there actually tried to program the clipboard?? I wrote the copy stuff, chacked all my variables, and the text string before it went in and everything. All looked fine. Then I tried to find a bug free program that could show me what was in there. _Bug free_!! I must have been out of my mind!!! Notepad: This must be close to the slowest implementation of a clip board in the world. Pasting text is like swimming in treacle. It always chokes on text >5000 characters, and gives up. Curiously, in a different place each time. I suspect it is trying to read the text a buffer-full at a time, and looses track of where it was up to in the clipped document. Snap: Probably worse. Seems to use a static buffer for text of about 250 chars. Once that is full, no dice. I ended up writing my own viewer. Just a little function to spew the contents out into the current cli. The clip was in there ok, and the copy and paste functions are reasonably fast. It just looks like there is almost no support for the clipboard in the world-at-large. I would like 2 things if someone could email them, please. 1) The latest version of the C= cbio.c functions (in case the ones I am using are a little infested. 2) The latest source to snap, and I'll add dynamic memory allocation so we can snap any amount of text (which I can send in return, if desired). An suggestions for salvaging the clipboard??? Regards Alan
micke@slaka.sirius.se (Mikael Karlsson) (06/11/90)
In message <8886@wehi.dn.mu.oz>, BAXTER_A@wehi.dn.mu.oz writes: [Mild flaming here] >Has anyone out there actually tried to program the clipboard?? Yep, I sure did. I dare say that I've "heightened the awareness" of the clipboard. >I wrote the copy stuff, chacked all my variables, and the text string >before it went in and everything. All looked fine. > >Then I tried to find a bug free program that could show me what was in >there. _Bug free_!! I must have been out of my mind!!! I'm beginning to suspect... >Notepad: This must be close to the slowest implementation of a clip >board in the world. I guess I can agree on that. >Snap: Probably worse. Seems to use a static buffer for text of about >250 chars. Once that is full, no dice. Here I don't agree. If anyone else has had this kind of problems, please let me know. Except if you're trying to paste into the CLI. I guess you do know that the input line is limited. >I ended up writing my own viewer. Just a little function to spew the >contents out into the current cli. The clip was in there ok, and the >copy and paste functions are reasonably fast. It just looks like there >is almost no support for the clipboard in the world-at-large. A sad truth. >2) The latest source to snap, and I'll add dynamic memory allocation >so we can snap any amount of text (which I can send in return, if desired). Actually, I feel quite offended by this. You simply assume that I'm too stupid to handle something like this. Please don't do that. I am able to write some dynamic memory allocation routines, thank you. I can show you the important lines of FetchClip() right here: (VOID)ReadClip(ClipReq, (STRPTR)&ID, 5L, CLIP_CONT); /* #chars */ temp = ID[0]; Snap = AllocMem((LONG)sizeof(struct Snap)+temp, MEMF_PUBLIC|MEMF_CLEAR); Snap->Size = sizeof(struct Snap)+temp; ReadClip(ClipReq, (STRPTR)&Snap->Chars[0], Snap->Size+1L, CLIP_LAST); (Yes, I have added checking for AllocMem() failure, but I didn't think that would be necessary to show here.) If you have any other ideas about things you would like to see in Snap, just send them to me, perhaps including some code on how to do it, and I'll see what I can do. >An suggestions for salvaging the clipboard??? Write some good code, make that available, and try to be a bit more polite about it. >Regards Alan /Mikael -- \_/ Mikael Karlsson, Lovsattersvagen 10, S-585 98 LINKOPING, SWEDEN V | micke@slaka.sirius.se | Absolut Software | micke@slaka.UUCP ~~~ | {mcvax,seismo}!sunic!liuida!slaka!micke
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/12/90)
In <74005.AA74005@slaka.sirius.se>, micke@slaka.sirius.se (Mikael Karlsson) writes: >In message <8886@wehi.dn.mu.oz>, BAXTER_A@wehi.dn.mu.oz writes: > >>Snap: Probably worse. Seems to use a static buffer for text of about >>250 chars. Once that is full, no dice. > > Here I don't agree. If anyone else has had this kind of problems, >please let me know. Except if you're trying to paste into the CLI. >I guess you do know that the input line is limited. It will also not paste more than about 255 chars into Aterm. Snipit does. Thing is, an input line to a CLI (or perhaps any console) is indeed limited to 255 characters. However, the line stops at the EOL character, and it should start counting all over again. >(Yes, I have added checking for AllocMem() failure, but I didn't >think that would be necessary to show here.) > > If you have any other ideas about things you would like to see >in Snap, just send them to me, perhaps including some code on how >to do it, and I'll see what I can do. I have the devil of a time with having spurious characters show up in place of other characters, and rerunning it will sometimes cure the problem, but more often than not, the nature of the replacements will change. For example, I might find that I Snap a line that reads: dh1:foo/bar/bla and have it show up as dh1:foo5bar5bla On the next reboot, using the same SNapped line. it might change to: dh1:foo/b3r/bl3 In fact, here is a sample of what I get for the lower case alphabet right now (just tried it): abcdefghijklm5opqrstuvwxyz I do use a remapped keyboard, but the only remappings are on the numeric pad, which I find useless for anything but handy function keys. I did reduce the severity of the problem by remapping only the ALTed numpad keys, but it's still there to the degree noted. Unfortunately, I value the remapped keys a lot more than Snap, so even though I still use Snap, I watch out for the problem and kill it when it happens, then run Snipit. -larry -- The raytracer of justice recurses slowly, but it renders exceedingly fine. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
UH2@psuvm.psu.edu (Lee Sailer) (06/12/90)
I've never tried to mess with the clipboard. i read the RKM's, and since
it didn't give me any idea why the clipboard even needed to exist (though I
suppose there is one) I just carried on in my own way. (My program just uses
ram:)
Anyway, my two bit notion for saving the clipboard is that we need a Mac-like
ScrapBook. (I suppose this is like the clipdevice:nn idea, in a way,
stated from a user environemtn perspective.)
In brief, when I save something to the clipboard, I want to be able to fire
up my scrapbook, and paste the clip into it. I want to be able to put
multiple clips on one page, and have multiple pages. It should handle
text, graphics, sound, and so on.
Later, when I need something, I can open the scrapbook and cut or
copy out what I need.
I think if this thing existed, and the source was available, then
programmers would figure out how to be compatible with it. Do in
in AREXX, or something 8-)
leepnelson@hobbes.uucp (Phil Nelson) (07/03/90)
In article <25530@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >In article <3675@tymix.UUCP> pnelson@hobbes.UUCP (Phil Nelson) writes: >|I had this problem cutting from and pasting to A-Talk III Release 1.0e, >|it will paste back 256 char max. > >I just received the latest snap from Mikael, and checked with A-Talk III >1.3a (the current version). It works like a champ. I "snapped" an entire >page from a file I was "more"-ing on the Amiga, and sent it to >my host connected with A-Talk III and running Gnu-Emacs. It snapped all >600+ characters with no problem. I tried with AT-/// Release 1.0e, with same >results. Maybe you don't know how to use it :-) Maybe. Then again, maybe your program does not like having chars rammed down it's input buffer :-) I was able to snap text larger than 256 chars by using the "snap -c20" suggested elsewhere (thanks, whoever made the suggestion). I have since upgraded to A-Talk3 version 1.3a, just now I went back to "snap" without any args, and the same problem of not being able to paste back more than 256 characters has recurred, every time I try it. I can paste back the same snap into CED, slow, but it works. Some things that may be somewhat unusual with my setup: I use morerows (but the separate screen setting of A-Talk) and XOn-XOff. I did some experimenting to prove that the problem is not with any single network host (I tried a Sun server and a PDP-10). It is barely possible that the problem is in the Tymnet Dialup that I am connected to, but I doubt it very much, I have in the past uploaded megabytes of ASCII data via Tymnet Consats using X-On X-Off flow control, without losing even a single char. I am curious as to what your program does with keyboard input after it has received an X-Off from the DCE - does it toss the input? don't panic - it's just curiosity, I don't think the Consat is sending an X-Off at 256 chars (I'm not sure, since it is a little difficult to know the configuration of a Consat without special license, which I don't have in my present job) but it might be. >-- Marco -- Phil Nelson . uunet!pyramid!oliveb!tymix!hobbes!pnelson . Voice:408-922-7508 The simple believes everything, but the prudent looks where he is going. -Proverbs 14:15
papa@pollux.usc.edu (Marco Papa) (07/04/90)
In article <3694@tymix.UUCP> pnelson@hobbes.UUCP (Phil Nelson) writes: >In article <25530@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >>In article <3675@tymix.UUCP> pnelson@hobbes.UUCP (Phil Nelson) writes: >>|I had this problem cutting from and pasting to A-Talk III Release 1.0e, >>|it will paste back 256 char max. >> >>I just received the latest snap from Mikael, and checked with A-Talk III >>1.3a (the current version). It works like a champ. I "snapped" an entire >>page from a file I was "more"-ing on the Amiga, and sent it to >>my host connected with A-Talk III and running Gnu-Emacs. It snapped all >>600+ characters with no problem. I tried with AT-/// Release 1.0e, with same >>results. Maybe you don't know how to use it :-) > >Maybe. Then again, maybe your program does not like having chars rammed >down it's input buffer :-) Nah. My program never had any problem of that kind. I actually rammed 4K down its input buffer and it took it no problem. >I was able to snap text larger than 256 chars by using the "snap -c20" >suggested elsewhere (thanks, whoever made the suggestion). I have since >upgraded to A-Talk3 version 1.3a, just now I went back to "snap" without >any args, and the same problem of not being able to paste back more than >256 characters has recurred, every time I try it. I can paste back the >same snap into CED, slow, but it works. My suggestion is wait for the new snap. As I said the problem is NOT with A-Talk III. >Some things that may be somewhat unusual with my setup: I use morerows (but >the separate screen setting of A-Talk) and XOn-XOff. Does the problem appears when you DON'T use morerows and you DON'T use X-on/X-off? Those two experiments would have been the first ones I would have tried. BTW, Xon/X-off with AT-/// is useless at baud rates less thasn 9600. >I am curious as to what your program does with keyboard input after it has >received an X-Off from the DCE - does it toss the input? don't panic - it's >just curiosity, It will just respect the X-off. The keyboard input gets backed up on the input queue, until the X-on arrives, at which point it is sent back out the serial port. >I don't think the Consat is sending an X-Off at 256 chars >(I'm not sure, since it is a little difficult to know the configuration >of a Consat without special license, which I don't have in my present job) >but it might be. That should be fairly easy to check. Turn off X-on/X-off handshake. Select Capture Plain (so that control chars are retained). Open a capture buffer. Snap the buffer > 256 chars. After you're done, close the capture buffer, and check whether the X-off is there. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
BAXTER_A@wehi.dn.mu.oz (07/07/90)
In article <3694@tymix.UUCP>, pnelson@hobbes.uucp (Phil Nelson) writes: > In article <25530@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >>In article <3675@tymix.UUCP> pnelson@hobbes.UUCP (Phil Nelson) writes: >>|I had this problem cutting from and pasting to A-Talk III Release 1.0e, >>|it will paste back 256 char max. >> >>I just received the latest snap from Mikael, and checked with A-Talk III >>1.3a (the current version). It works like a champ. I "snapped" an entire >>page from a file I was "more"-ing on the Amiga, and sent it to >>my host connected with A-Talk III and running Gnu-Emacs. It snapped all >>600+ characters with no problem. I tried with AT-/// Release 1.0e, with same >>results. Maybe you don't know how to use it :-) > > Maybe. Then again, maybe your program does not like having chars rammed > down it's input buffer :-) > This was what my problem was. > I was able to snap text larger than 256 chars by using the "snap -c20" > suggested elsewhere (thanks, whoever made the suggestion). > Me too. Thanks also. Regards Alan