Anders Melander

Looks good. You're leaking the TGeneratedRandomStream object though.

I'm apparently not getting the message through; There is nothing special required, by neither the source nor the destination, in order to support copy/paste of files via RDP. The RDP support is transparent. If your remote application copies data onto the clipboard in the FileContents & FileGroupDescriptor formats, then the local destination will be able to paste it. Waitamoment.. I just realized that you just used remote desktop as an example. You will not actually be using remote desktop. Is that correct? So you are actually just asking how remote desktop makes the remote clipboard available to the client and how to replicate that functionality in your own client/server system. Well, I don't know the exact details of how it's done but I know enough about the clipboard and dragdrop that I can guess. On the server, the RDP host monitors the clipboard (there's an API for that). When data is copied onto the clipboard, in one of the formats supported by RDP, the server sends a message to the client with the meta data (data formats, size, etc.) of the clipboard data. On the client, the RDP client receives the message and copies the (meta) data onto the local clipboard using an IDataObject interface. On the client, some application pastes from the clipboard... The local clipboard asks the local data source, via the IDataObject interface, for the data. The local RDP receives the data request on its IDataObject interface and forwards this request to the remote RDP server. The remote RDP server in turn does the same: It asks the remote clipboard for the data, the remote clipboard asks the remote data source (whoever copied the data onto the clipboard in the first place), etc. Once the remote RDP server has the data it sends it back to the local RDP client which then supplies it, through the IDataObject, to the local application. Done. Paste complete. A normal paste can cause data to be sent back, through IDataObject, notifying the source about the paste. I don't know if RDP propagates this information all the way back to the server.

This isn't possible. Only the data source is notified when data is pasted - and it isn't actually notified of a paste but it can deduce that a paste is happening because it is being asked to supply the data being pasted. Also not possible. Only the data target knows the destination of the data. The fact that a paste in Explorer happens to write something to disk somewhere is an implementation detail that is entirely internal to Explorer. There no rule that says that a file being pasted somewhere has to go to disk. The destination could be a virtual device that ends up printing the file in hex onto toilet paper and mailing by pigeon it to the nearest Buddhist temple. How would Explorer communicate that to anyone? I disagree. What makes you come to the conclusion that they do it? Actually, maybe you should explain what problem you are trying to solve. Why do you need to know where a file was pasted?

Seriously? That solution is at best a hack and there are a thousand ways it could break. There is a reason why Microsoft hasn't provided us with a way to determine the target of a drop or a clipboard operation (CFSTR_TARGETCLSID being the exception). Maybe it would be best to not try and circumvent that?

Okay. That is the opposite direction of what I thought you wanted to do but never mind; The same rules apply. They are not really doing anything special. The remote desktop server monitors the remote clipboard. When data is copied onto the clipboard the RDP server notifies the RDP client which then pastes the data onto the local clipboard. Note though that the actual data isn't transferred unto the local clipboard until someone pastes it or the data source is closed (this is normal clipboard behavior and has nothing to do with RDP). Only the meta data is transferred immediately. This is what a paste of a copied file from RDP looks like: Note that even though I copied a file, the normal CF_HDROP (which would contain a filename) isn't there. Only FileContent (the content of the file) and FileGroupDescriptor (the file meta data) is made available. The remaining data are just 3 DWORD flags that aren't relevant to this. It's a bit hard to understand what you are doing since I don't know where "my program" is running or where "the file explorer" is running. My guess is that "my program" is running on the remote system and "explorer" on the local. In that case what you want is what I call a virtual drop source (remember: dragdrop and clipboard, same thing). The library I linked earlier has multiple examples of that; The source (your application) supplies the filename(s) of the data to be transferred (dragged or copied to clipboard) and when the target reads the data (from a drop or from the clipboard) then the source is called to supply the actual file content. See: Transferring Data to and from Virtual Folders

Unless your application is the source of the clipboard data, then I don't believe it is possible. TLDR; No The destination might not even be a directory. It could be anything since it's completely up to the target what it does with the data. My guess is that the remote desktop client monitors the local clipboard for supported formats. When data is copied onto the clipboard it pastes copies of the data onto the remote clipboard. In the case of files/folders, the actual transfer of the files are only done, on demand, if an application reads data from the remote clipboard. This last part isn't specific to RDP; The same thing happens when copy/pasting on a local system. That part is easy because the system asks the source for data when it is needed - i.e. when it is pasted. I suggest you experiment with all this using the Drop Source Analyzer and Drop Target Analyzer tools that are part of the Drag and Drop Component Suite (drag and drop and the clipboard are the same thing, in case you wondered). This will give you a better understanding of how the clipboard works internally. Here's what a clipboard copy/paste from the target to the source analyzer looks like: Unfortunately you can't use the target analyzer with remote desktop because it doesn't put the file formats onto the clipboard that remote desktop supports. You can use it see remote desktop asking for data though. I can probably modify it to add the required formats if there's demand.

That's stretching the definition of native Windows control quite a bit.

You are replying to a 6 year old post...

Yes, I knew you would run into that problem. I just wanted to see if you could figure out the solution on your own 🙂 The behavior you observed is what @dummzeuch was alluding to. The reason is that once you have moved the controls the alignment is applied based on the current position of the controls. Since you have two bottom aligned controls (the splitter and the memo) then the topmost will always be aligned above the other. If you make the memo higher then the top position will be smaller than that of the splitter so you have to move the splitter too. The fact that you have the top control (instead of the bottom) client-aligned actually makes this a bit more complicated but never mind. Here's what you need to do to makes it work (I hope - alignment can be a bitch): You have 3 controls: MemoTop, align=client Splitter, align=bottom MemoBottom, align=bottom 1) Resize MemoBottom and manually reposition it so it is still bottom-aligned. 2) Reposition Splitter to be above MemoBottom. SavePos := MemoBottom.Top; DeltaSize := 100 - MemoBottom.Height; MemoBottom.Height := 100; MemoBottom.Top := SavePos - DeltaSize; Splitter.Top := MemoBottom.Top - Splitter.Height;

The PegTop track and range bars are quite nice and easy to use: https://www.pegtop.net/delphi/components/common/screenshots.htm ...and there's couple in the SO post: https://stackoverflow.com/questions/4387690/component-similar-to-trackbar-to-enter-a-range-of-values ...and if you can wait a week or so I will be releasing one of my own (based on Graphics32 though). I have the track bar part completed so I'm starting on the range bar part now. DevExpress also has a range bar and I believe TMS has one too. Personally, if I weren't writing my own 🙂, I would go for the PegTop range bar; I have used it with success in many projects.

Memo2.Height := 100;

That's a bit... unnuanced. I thought it was helpful. Even though the "problem" is pretty obscure, and I haven't encountered it myself, it's a point of data that might come in handy some day.

No. You have no way of knowing what the caller has put on the stack (or in the registers), what the called method does with it, what it returns and how. You can probably make it work for very simple delegate types (TNotifyEvent for example) but I think it would be better to find a less fragile solution.

IMO this effectively invalidates virus protection for the whole system since you have little control over which files the IDE will load explicitly and what it will open indirectly due to path, shell extensions, embedded browsers, etc. etc. I don't use Windows Defender but unless it's complete crap, it should only live-scan newly created or modified files. The static files already on the system have supposedly already been scanned and must be assumed to be safe to access. If not, the system can be assumed to be already compromised in which case the scanning is pointless anyway.

The installation location you chose is for static files such as the compiler, IDE, tools and all their packages, etc. Per-user data files goes to %APPDATA% and "CSIDL_MYDOCUMENTS" and the like. It's probably documented somewhere. Process Monitor should be able to tell you that. Filter on process name=bds.exe and event class=file system. After Delphi has finished startup, pause the procmon capture and go to Tools, File Summary, By Folder. This is what a launch of Delphi 12.1 on Windows 10 looks like on my system. Approximately two thirds of the time is taken by accessing Delphi's files, the rest by DevExpress (d:\Library\...).