I am using one program to monitor the keyboard for input but would like to use that same program to populate the clipboard then automatically paste to the cursor location of the other program? Can this be done... I am using Delphi 4 Pro.
It's possible, but this is very poor design. The clipboard is provided for the benefit and use of the user, not the programmer. You will end up trashing pre-existing clipboard data. It is not possible to 100% faithfully and reliably cache the clipboard contents and restore it later.
That said, you can send Ctrl+V keystrokes or WM_Paste messages to the other window.
Send the target window a wm_Paste message.
But only put data on the clipboard if the user has told you to. The clipboard is something that should always be under control of the user, or else you run the risk of clobbering other data the user was already storing there.
Related
In my application I want to lock the clipboard to prevent other application from changing the clipboard. How can I achieve this using Delphi 2007?
There is no facility for that. The user is the ultimate owner of the clipboard. When the user wants something else on the clipboard, the user will cut or copy something new. You, as the application developer, don't get a vote. (Users who discover programs trying to assert votes they don't have are likely to uninstall those programs and give them poor reviews.)
You can monitor the clipboard to discover when it changes with wm_ClipboardUpdate, but by the time you receive the notification, there's already something new there.
The purpose of the clipboard is to make data stored in it to be available to any program at any time and therefore provide easy way from transferring such data between different applications.
Because of that there is no official mechanism which would allow blocking access to the clipboard.
Any way if you are perhaps thinking of trying to block other application of accessing the clipboard in order to avoid them to be able to intercept some data from your application that has been stored there for copying purposes (which is the only reason I can think of why you would want to do this) there is another even better way.
Instead of using Windows default clipboard for string parts of data for copy and paste operations go and implement your own custom clipboard that will only be available from your own application similar as Microsoft does with its Office Clipboard (https://support.office.com/en-us/article/Copy-and-paste-multiple-items-by-using-the-Office-Clipboard-714a72af-1ad4-450f-8708-c2931e73ec8a).
In order to do this you only need to design a storing mechanism and then override default Cut, Copy and Paste shortcuts to use your mechanism instead of the default Windows Clipboard.
I use Delphi XE5 and have to realize the possibility for the user to drag different files (docx, xlsx, pictures (jpeg, gif, ...), E-Mails, ... into a component. The component should show the filename or the header of the E-Mail.
Than i want to save this file into a Blob-field in the SQL-Server Database.
Can anyone tell me whats the best possibility if possible with a short example.
Can i realize this with the standard delphi components or is it necessary to install special components.
Your component needs to be derived from TWinControl (TCustomControl, etc) so it has its own HWND to drag things onto. Then:
if you just want to capture dragged filenames, your component can process the WM_DROPFILES window message. This is a legacy message, but it still works. However, it only works when dragging physical files from the file system onto your window. For more advanced scenarios (dragging virtual data, dragging data from other apps, etc), you need to...
a. implement the IDropTarget interface instead. Write an object that implements IDropTarget, or use a third-party implementation such as from Ander's Melander's Drag&Drop suite.
b. register that object for your component's HWND using RegisterDragDrop() after it has been created (the best place to do that in in your component's overridden CreateWnd() method), and unregister the object using RevokeDragDrop() when the HWND is being destroyed (such as in the overridden DestroyWnd() method).
c. when the user drags something onto your component's window, your IDropTarget.DragEnter() implementation will be called. Examine the provided IDataObject to see if it holds a data format + transport scheme that you support (there can be multiple combinations at one time). Each piece of data will be identified by a unique clipboard format identifier, and a TYMED value indicating how the data is transferred. Some clipboard formats are pre-defined (see Shell Clipboard Formats), and some can be registered dynamically at runtime (see RegisterClipboardformat()). If you find a combination that you support, return DROPEFFECT_COPY to accept the drag, otherwise return DROPEFFECT_NONE to reject the drag.
d. if the user drops something onto your component's window (if accepted by DragEnter()), your IDropTarget.Drop() implementation will be called. Extract the data from the provided IDataObject and use it as needed. When dropping physical files, you will receive their paths+names and/or their ITEMIDLIST identifiers, then you can open and read the files as needed. When dropping virtual data/files, you will get the actual data instead (which is usually transferred as a block of memory in an HGLOBAL that you can access using GlobalLock(), or as an IStream interface, but there are other possibilities available).
See MSDN for more details:
Transferring Shell Objects with Drag-and-Drop and the Clipboard
Shell Data Object
Handling Shell Data Transfer Scenarios
Further to my post on custom format clipboard, I am considering the possibility of writing my own custom clipboad monitoring component.
Prior to the statement:
ClipboardWindow:=SetClipboardViewer(Form1.Handle);
I have seen in a sample code I studied the following snippet:
OpenClipboard(Form1.Handle);
EmptyClipboard;
CloseClipboard;
whereas others don't include a cleaning code at all. I am confused.
I believe Clipbrd.TClipboard.Clear just does the same the VCL way.
My question is:
When clearing the clipboard before joining the clipboard chain is mandatory ?
No, there is no need to clear the clipboard. Indeed, you shouldn't. Other clipboard monitors will needlessly react to the update, and the user may want to paste that thing that you just destroyed.
Additionally, there is a lot more to clipboard chain monitoring than just adding yourself to the chain. You must pass the events along to the next window (result handle from SetClipboardViewer), and you must, without failure, remove yourself from the chain when your app exits. Also, you need to avoid blocking the clipboard unnecessarily. Typically, this means waiting to register for the clipboard events until you're ready to actually process events. For example, don't make it the first thing in your startup, if you're going to subsequently open a dialog asking the user where he wants to store the data, if he has a license key, etc..
I have tips, as well as common pitfalls here:
http://www.clipboardextender.com/developing-clipboard-aware-programs-for-windows/6
The rule is as simple as possible: if you want to delete the clipboard content (so other apps can't use it) delete it. if not, keep it.
You don't know if your use wants to keep the data OR You want to implement something fancy?
Do you know those applications (Paint Shop Pro is one of them) that are asking: "You left a large image (10MB of data) in clipboard. Do you want to keep it or clear it?"
You could do something similar. :)
How would I hook into a file that's currently in use by another program, which constantly writes out to it? Let's say, there's a text file with 10 lines. When I start my app it has to detect and read any content from there on everytime the writing program saves its content. Can this be done without a constant check on the filesize/date?
You could monitor the folder for changes using the ReadDirectoryChangesW API.
Keep track of the last position you read to, and when you receive a change notification for that file, read from there to the end of the file (as it currently stands).
An example of how to use the ReadDirectoryChangesW API is here:
Why does ReadDirectoryChangesW omit events?
Kinda similar to this:
Monitor files similar to System Internal's/Microsoft's FileMon/Process Monitor
sorry for this little bit strange title, didn't found a better one..
I've got the following situation:
I have a PC with an RFID reader connected via USB.
I now need a program which pops up when ab transponder was scanned the the RFID reader and shows the scanned value. (The reader just simulates keystrokes)
Problem: the value of the transponder is something like 0001230431, and I can't change it. (To prefix a hotkey combination or so)
So I have thought about using a global keyboard hook, check if three zeros where typed in, capture rest of data and when the 10 digits are complete, call the application through an automation object and show the number.
But I'm not very exalted about using a global keyboard hook. Many AV programs don't like them very much, they are not so easy to handle with Delphi and I guess that's not very resource-friendly for such a little task...
So I'm looking for an alternative solution...maybe somebody has an idea?
Big thx!
ben, you can use the RegisterRawInputDevices and GetRawInputData functions.
first you must use the RegisterRawInputDevices function to register the input device to monitor and then you can retrieves the data from the input device using the GetRawInputData function.
Check theses functions too
GetRawInputDeviceList retrieves the list of input devices attached to the system.
GetRawInputDeviceInfo retrieves information on a device.
Why not make sure the Delphi app with a text edit control has focus before the scan is done? Then the keystrokes will go straight into your Delphi app.