Forum unknown
· Programming
#Paste Function
21 messages in this thread
I am writing a program in which I would like to implement a 'Paste'
function. This function would take an ASCII string, in this case it is the
result of a calculation, and send it to another application to appear in
some data field. The program will be a Pop-Up (like PopCLI) where the user
will press a key to activate it. It can also be run as a non-resident
program. I am interested in getting some opinions on what the best method
is to achieve this. It sounds like a task that may be more complicated than
what it's worth… unless someone has some great secret that I've missed 🙂
Someone has suggested using clipboard.device, but I don't see how that will
work. Wouldn't the target program have to KNOW that it has to retrieve
something from the clipboard? Wouldn't that have to be specifically
programmed-in to the target program?? I'd like to hear any ideas you may
have…. Thanx!
Ray,
Not absolutely certain what you have in mind, but see SnipIt, SNIPIT.ARC,
dl-9.
Doug, SnipIt won't do the job. Let me explain a little better… I got the
idea from some programs on the IBM, one of which the company I work for
sells. The best comparison would be Borland's memory-resident program
called SideKick. SK has a pop-up calculator built in. I find it to be VERY
useful at work. The program that I'm writing is also a pop-up calculator
(for programmers). In SK, you can pop into the program at any time by
pressing the hot-key, and, make a calculation, and then PASTE the result
(contents of the calculator display).
When SK pastes, all it does is stuff the ASCII codes for the number to be
pasted into the IBM's keyboard buffer, and then it returns control to
whatever had control when you activated SK. THAT program will accept the
input into one of it's input fields (assuming you poped-up SK while the
other program was waiting for inout somewhere) because it's in the keyboard
buffer. THIS is what I'd like to implement on _my_ calculator on the Amiga.
The question is, how do you get the data to the application. You have to
make it look like the system has collected the information from the
keyboard. It can be a useful feature, but if it's too difficult to
implement then it's probably not worth it.
That sounds like SnipIt to me. It accept input from any con: window and
dumps it to any window expecting keyboard input.
That sounds like SnipIt to me. It accept input from any con: window and
dumps it to any window expecting keyboard input.
I think what you are trying to achieve would be best brought about
by using ARexx for Inter Process Communications. What you _could_ do is
latch on to ARexx and listen in to all of the ARexx messages running around
on an ARexx'd system. The user would then be able to write ARexx macros
from inside his application that would call your calculator. Your
calculator would perform the calculation and then return the answer through
the ARexx message port to his application. Your calculator wouldn't even
have to come up on the screen, or, it could come up, if the user so
desired.
There is a simple calculator program provided on the ARexx distribution
disk called calc.rexx. Through another application that has an ARexx
interface, I can latch the command 'call Arexx, run calc.rexx, with this
argument — expect a returned value, place it where my cursor is now' to a
key sequence on my keyboard. If I typed 39.95*.6 in a field and then did a
R-Amiga C key sequence it would perform the above ARexx macro and come back
and leave 21.37 in the field where I had called it from. Does this sound
like what you want to be able to do? If so, I suggest that you go out and
buy ARexx (and WShell) as soon as possible and start lobbying every
software artist to include an ARexx interface in their application.
I think what you are trying to achieve would be best brought about
by using ARexx for Inter Process Communications. What you _could_ do is
latch on to ARexx and listen in to all of the ARexx messages running around
on an ARexx'd system. The user would then be able to write ARexx macros
from inside his application that would call your calculator. Your
calculator would perform the calculation and then return the answer through
the ARexx message port to his application. Your calculator wouldn't even
have to come up on the screen, or, it could come up, if the user so
desired.
There is a simple calculator program provided on the ARexx distribution
disk called calc.rexx. Through another application that has an ARexx
interface, I can latch the command 'call Arexx, run calc.rexx, with this
argument — expect a returned value, place it where my cursor is now' to a
key sequence on my keyboard. If I typed 39.95*.6 in a field and then did a
R-Amiga C key sequence it would perform the above ARexx macro and come back
and leave 21.37 in the field where I had called it from. Does this sound
like what you want to be able to do? If so, I suggest that you go out and
buy ARexx (and WShell) as soon as possible and start lobbying every
software artist to include an ARexx interface in their application.
Ray,
The way you'd want to add data to a window as if it were typed from the
keyboard is through the input device using the IND_WRITEEVENT command.
This is the way my program, CoPilot, spits out a keyboard macro. The two
problems you'll have to account for are:
Only the active window will receive a VANILLA/RAW class event, since your
calculator window will have opened, the calling window will have been
de-activated. I think you'll be able to make the pasting function act
intuitive by looking for the IDCMP flags ACTIVEWINDOW and INACTIVEWINDOW.
when you recieve the INACTIVEWINDOW flag, check the IAddress element to see
if it matches your calculator's window pointer. If it does, wait for the next
ACTIVEWINDOW flag, check it's IAddress, if it isn't your calculator, send the
data to the input device. You'll probably need a "PASTE" gadget to enable
this logic sequence.
The next thing is which raw key codes to use for sending the data. I'd go
with the keyboard rather than the keypad in case some programs out there look
at raw key data instead of vanilla. I'm also fairly certain that you'll be
compatible with the 500, 1000 & 2000 this way and even with non-US keymaps
too.
-Jack-
Thanx for that info. It was real helpful. I was thinking this past weekend
about how the user would speicify which window to send the string to, and I
came-up with a scheme which, while maybe not the most intuitive, will give
the user the most control over where to send the data. The user would click
the Paste Gadget and the calculator window would disappear. They could then
activate the window they want the string to go to and position the cursor at
the proper field, then press the calculator hot-key to complete the pasting.
My program will have an event handler in the input stream which would wait
for the hot-key and send a signal to the sleeping calculator program when the
hot-key is pressed. When the Paste Gadget is clicked, a flag would be set to
tell the event handler that the next time the hot-key is pressed that it
should Paste the string rather than signalling the calculator program to
wake-up. This would give the user complete control over where the string
should be pasted, making the whole thing more accurate and useful. What do
you think of this idea?
Ray,
Sorry for the delay in responding. Truthfully, your scheme sounds a bit
complicated, although closing the calculator before pasting sounds good, what
if the user has a few calculations to do in a row? Sort of
calc/paste/calc/paste… and so on?
Second, cursor posistion is pretty elusive too. That is if there even is a
word processor or text editor which will be the target of the pasted data.
What about string gadgets?
Since you plan on using an input event handler I'd look for a mouse button
with one of the other qualifiers, CTRL, SHIFT, ALT or AMIGA to trigger the
paste action. But I'd also leave the calculator on the screen too, even if it
only takes a hot-key to open it I think a user would get tired of having to
open it after each paste. Hope that helps.
-Jack-
Ok…. valid argument… How about this: You pop-up the calculator, make
your first calculation, then click on Paste.
Ok…. valid argument… How about this: You pop-up the calculator, make
your first calculation, then click on Paste.
Whoops! Sorry 'bout that. Let me continue… As I was saying… pop-up the
calculator, make your 1st calculation, then click on Paste. The calculator
window disappears, and the program waits for you to hit the mouse
button-qualifier combination to trigger the actual 'paste'. Once you do so,
the paste takes place and the calculator window re-appears!! How's that? Do
you think you could live with that?? Ray
Ray,
Well, it's not so much me, just trying to picture in my own mind what would
seem "logical" to happen on screen.
You've about got it though, no need to actually close the calculator
though, send it to the back seems good enough… No wait, what if the
application is a backdrop window with no other windows? Nope, that won't
work.
Hmmm, guess your way sounds good… Guess you should try it like that first
and see if others like/dislike it. Should be fine though.
-Jack-
Ray,
Well, it's not so much me, just trying to picture in my own mind what would
seem "logical" to happen on screen.
You've about got it though, no need to actually close the calculator
though, send it to the back seems good enough… No wait, what if the
application is a backdrop window with no other windows? Nope, that won't
work.
Hmmm, guess your way sounds good… Guess you should try it like that first
and see if others like/dislike it. Should be fine though.
-Jack-
Whoops! Sorry 'bout that. Let me continue… As I was saying… pop-up the
calculator, make your 1st calculation, then click on Paste. The calculator
window disappears, and the program waits for you to hit the mouse
button-qualifier combination to trigger the actual 'paste'. Once you do so,
the paste takes place and the calculator window re-appears!! How's that? Do
you think you could live with that?? Ray
Ray,
Sorry for the delay in responding. Truthfully, your scheme sounds a bit
complicated, although closing the calculator before pasting sounds good, what
if the user has a few calculations to do in a row? Sort of
calc/paste/calc/paste… and so on?
Second, cursor posistion is pretty elusive too. That is if there even is a
word processor or text editor which will be the target of the pasted data.
What about string gadgets?
Since you plan on using an input event handler I'd look for a mouse button
with one of the other qualifiers, CTRL, SHIFT, ALT or AMIGA to trigger the
paste action. But I'd also leave the calculator on the screen too, even if it
only takes a hot-key to open it I think a user would get tired of having to
open it after each paste. Hope that helps.
-Jack-
Thanx for that info. It was real helpful. I was thinking this past weekend
about how the user would speicify which window to send the string to, and I
came-up with a scheme which, while maybe not the most intuitive, will give
the user the most control over where to send the data. The user would click
the Paste Gadget and the calculator window would disappear. They could then
activate the window they want the string to go to and position the cursor at
the proper field, then press the calculator hot-key to complete the pasting.
My program will have an event handler in the input stream which would wait
for the hot-key and send a signal to the sleeping calculator program when the
hot-key is pressed. When the Paste Gadget is clicked, a flag would be set to
tell the event handler that the next time the hot-key is pressed that it
should Paste the string rather than signalling the calculator program to
wake-up. This would give the user complete control over where the string
should be pasted, making the whole thing more accurate and useful. What do
you think of this idea?
Ray,
The way you'd want to add data to a window as if it were typed from the
keyboard is through the input device using the IND_WRITEEVENT command.
This is the way my program, CoPilot, spits out a keyboard macro. The two
problems you'll have to account for are:
Only the active window will receive a VANILLA/RAW class event, since your
calculator window will have opened, the calling window will have been
de-activated. I think you'll be able to make the pasting function act
intuitive by looking for the IDCMP flags ACTIVEWINDOW and INACTIVEWINDOW.
when you recieve the INACTIVEWINDOW flag, check the IAddress element to see
if it matches your calculator's window pointer. If it does, wait for the next
ACTIVEWINDOW flag, check it's IAddress, if it isn't your calculator, send the
data to the input device. You'll probably need a "PASTE" gadget to enable
this logic sequence.
The next thing is which raw key codes to use for sending the data. I'd go
with the keyboard rather than the keypad in case some programs out there look
at raw key data instead of vanilla. I'm also fairly certain that you'll be
compatible with the 500, 1000 & 2000 this way and even with non-US keymaps
too.
-Jack-
Doug, SnipIt won't do the job. Let me explain a little better… I got the
idea from some programs on the IBM, one of which the company I work for
sells. The best comparison would be Borland's memory-resident program
called SideKick. SK has a pop-up calculator built in. I find it to be VERY
useful at work. The program that I'm writing is also a pop-up calculator
(for programmers). In SK, you can pop into the program at any time by
pressing the hot-key, and, make a calculation, and then PASTE the result
(contents of the calculator display).
When SK pastes, all it does is stuff the ASCII codes for the number to be
pasted into the IBM's keyboard buffer, and then it returns control to
whatever had control when you activated SK. THAT program will accept the
input into one of it's input fields (assuming you poped-up SK while the
other program was waiting for inout somewhere) because it's in the keyboard
buffer. THIS is what I'd like to implement on _my_ calculator on the Amiga.
The question is, how do you get the data to the application. You have to
make it look like the system has collected the information from the
keyboard. It can be a useful feature, but if it's too difficult to
implement then it's probably not worth it.
Ray,
Not absolutely certain what you have in mind, but see SnipIt, SNIPIT.ARC,
dl-9.