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\...).

They are not buffer overflows; The protocol for a lot of API functions is to first make a call with a small or no buffer and then repeat the call, if needed, with the required buffer size returned by the first call. So all those BUFFER OVERFLOW are just the first call saying that some of the data returned was truncated to fit the supplied buffer. See: https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/buffer-overflows-in-regmon-traces Apart from that, the very first thing I look for when people have performance problems is cloud storage such as OneDrive, DropBox, Google Drive, etc. The cloud synchronization can simply kill a system. Disable it and only sync when you have to.

Decoupling. In this case the events belongs in the sub-property objects. They do not concern the main component. I understand what you are saying but IMO that view is driven by the fact that we are talking about "components" which is a RAD thing, thus design-time stuff, monolithic design and so on. I'm designing this like I would if there was no design-time to influence things. If I hadn't gotten this to work then the events simply wouldn't have been accessible at design-time. In fact, at the moment the sub-properties are objects that are statically created by the component. The next stage is to make the class type of the objects dynamic and configurable at design-time. And then there's no way I could expose those event on the component because they wouldn't be known at compile-time. So instead of a single class that handles many different button styles (like I have now - see screenshot): property ButtonOptions: TButtonOptions read FButtonOptions write SetButtonOptions; I will get one class for each button style: property ButtonOptions: TCustomButtonOptions read FButtonOptions write SetButtonOptions; property ButtonOptionsClass: TButtonOptionsClass read FButtonOptionsClass write SetButtonOptionsClass; and each class will expose the properties that are relevant to that style.

I have a component which contains sub-properties; I.e. a component property which is itself an object that contains its own properties. The object is derived from TPersistent and one of its properties is an event. The problem I'm having is getting this event to appear in the object inspector. I'm pretty sure that I had it working at one point but whatever I've tried now I can't get the event property to appear in the OI. FWIW, it works without problems in the Lazarus IDE. I've looked through the source of the few ToolsAPI units we have available but I haven't found any clues there. As far as I can tell it should work. So what am I missing? The following source reproduces the problem: unit FooBar.Reg; interface uses Classes, DesignIntf; type TTestSub = class(TPersistent) private FOnEvent: TNotifyEvent; FTest: string; public procedure Assign(Source: TPersistent); override; published property Test: string read FTest; property OnTestEvent: TNotifyEvent read FOnEvent write FOnEvent; end; TTest = class(TComponent) private FSub: TTestSub; procedure SetSub(const Value: TTestSub); public constructor Create(AOwner: TComponent); override; destructor Destroy; override; published property Sub: TTestSub read FSub write SetSub; end; procedure Register; implementation procedure Register; begin RegisterComponents('FooBar', [TTest]); end; { TTest } constructor TTest.Create(AOwner: TComponent); begin inherited; FSub := TTestSub.Create; FSub.FTest := 'Hello world'; end; destructor TTest.Destroy; begin FSub.Free; inherited; end; procedure TTest.SetSub(const Value: TTestSub); begin FSub.Assign(Value); end; { TTestSub } procedure TTestSub.Assign(Source: TPersistent); begin FOnEvent := TTestSub(Source).OnEvent; end; end.

Don't worry. I'll post a link once it's ready for consumption but it's too much to post inline here. In short it involves declaring a placeholder property on the top level class registering a dedicated property editor for this property which in turn redirects to the actual sub-property and then enumerates the delegates/events of that object to create TNestedProperty property editors for each of them.

Okay, so I got it working using the same method as DevExpress: The code required is pretty crazy. I'll post a link to it once it makes into the Graphics32 repository. Functionality like this is really something that ought to be standard.

Yes, I know I could just use TComponent but nope; I'm not letting a deficiency of the IDE dictate my class design.

Ohwaitamoment! I think DevExpress use a custom property editor to get the events listed. I'll investigate.

Most of DevExpress' controls beg to disagree: The sub-properties are derived from TPersistent...

Already tried that; Made no difference.

Yes it does - but map2pdb just produces the pdb files required by the profilers. Profilers that works with pdb files includes Intel VTune and AMD μProf. I believe μProf works with both Intel and AMD processors while VTune only works with Intel processors but use the one that matches your processor to get the most precise results. I use VTune myself. Ask if you need instructions on how to get started. The process is very easy once you know how to do it but it can be challenging to get to that point 🙂