David Mitchell wrote: > Dan Bron wrote: >> R.E.Boss' question and Eric's response made me wonder what other >> conveniences we might be losing by switching to a browser frontend for J >> development, and how we might compensate for them. >> >> One big loss that springs to mind is wdclipcopy and wdclipread . J is my >> primary scripting language and general computer utility, so I use these >> verbs all the time, for ad hoc parsing of data (e.g. phone bills), quick >> calculations (e.g. expense report sanity checking), and more. >> >> Since the server's clipboard is obviously different from the client's, I'm >> worried that I'll lose these tools, and wondering how we can compensate [1], >> and generally what other tools we might be losing. >> >> Can anyone tell me what other habits I might have to change? Obviously, any >> broken tools would come at the boundary between J and the machine, because >> J's staying the same, "the machine" has a new definition. >> >> -Dan >> >> [1] Put a "paste here" frame in the UI?, have the 11!:0 callback ask >> Javascript for favors? >> > > If you are using Windows, you may be interested in this: > > http://www.jsoftware.com/jwiki/Scripts/WindowsClipboard > > It works for me on Win7 with J602 and J701: > > setcliptext'Mooga Mooga' > 3276804 > setclipfiles'This';'is';'files' > 3276812 > getclip'' > This > is > files > > getcliptext'' > 0 > getclipfiles'' > This > is > files >
Sorry, I replied to the wrong message. I can see that accessing any client resources from the server session will have to have some sort of cross system sharing established. The UI "paste here" window seems like it could work fine for client->server data. Server->client seems a bit trickier. It looks like built-in JS access to the clipboard is possible on a browser by browser basis. I found this tool for Firefox: AllowClipboard Helper 0.6.2. -- David Mitchell ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
