Anders Melander

Are you saying that you get an exception when compiling the code? I think you mean when running the code. Going back and looking at your screenshots, I can see that the exception probably occurs in some paint code. That's why you get the cascading errors. A repaint causes an error which triggers a new repaint which causes an error, etc. etc. If you can reduce the project to the smallest possible case that reproduces the problem and post the code in a zip file, then maybe some of those here that actually use C++ (I don't) can have a go at it. For example, if you remove all the 3rd party stuff (including Graphics32), can you still reproduce the problem? No.

...or the slightly less hacky method: EnumDynamicTimeZoneInformation and friends.

Sounds like a good plan. But please use version numbers instead of marketing names. I have no idea what versions Athens or Alexandria refers to - nor do I care to know.

And did you replace all the Form1-> with this-> ?

Sure but the fact that it's only available via WinRT sort of confirms that it isn't, doesn't it?

Again: Not a part of the clipboard system; A layer on top of it. It is not a single global history that is managed somewhere. It is just individual services that maintain their own history. So not "the clipboard" history but "a clipboard" history.

"as short as possible" is not a usable specification. The shortest possible key is zero characters long. The longer the key, the fewer key collisions. You need to specify the exact length you want your key to be. Also, are you really sure that you want to hex encode the key? With hex encoding you are wasting half the bits by using 8 bits (i.e. an ansichar) to represent a 4 bit value (i.e. a hex digit). A more efficient encoding would be something like Base32 (5 bits per byte) or Base64 (6 bits per byte). I believe Delphi has implementations of both. Search the source (or wait for someone here to write what they are, as I'm sure they will do).

I think I can see the problem: You are referencing the Form1 global variable before it has been assigned a value; Your code is in the constructor (or more precisely: an event handler called from the constructor) and the Form1 value isn't assigned until the constructor returns. Do like this instead: void __fastcall TForm1::FormCreate(TObject *Sender) { ... for(j = 0; j < c; j++) { pLayer[j] = new TBitmapLayer(this->ImageBackground->Layers); pLayer[j]->Bitmap->DrawMode = dmBlend; pLayer[j]->Scaled=true; } ... } or simply: void __fastcall TForm1::FormCreate(TObject *Sender) { ... for(j = 0; j < c; j++) { pLayer[j] = new TBitmapLayer(ImageBackground->Layers); pLayer[j]->Bitmap->DrawMode = dmBlend; pLayer[j]->Scaled=true; } ... } Of course it would be best if you could avoid all those global variables (not Form1 but all the others). I don't know if they were just there for debugging this problem.

On my system (Windows 10) the history only contains data copied after first Win+V. Win+V starts the "Clipboard User Service" (svchost.exe -k ClipboardSvcGroup -p). The service is set to manual start. Maybe it's set to auto start on your system? Anyway, the history is not part of the clipboard system. It's just an application on top of it, no different from one that you could write yourself. Trying to access the clipboard history data when there is no public API is IMO a waste of time when you can just replicate what it does. It's not that hard.

AFAIK there's no such thing in Windows as a clipboard history. Applications, and libraries (.NET, UWP, etc.), that offer a clipboard history does so by monitoring the clipboard and making local copies of the content when stuff is copied onto the clipboard. This is why Windows' own clipboard history (WinKey+V) is always empty when you first invoke it. It needs to run in the background before it can collect data from the clipboard; Windows itself doesn't maintain a history. This is also why it is very limited what data is stored in the clipboard history; The clipboard history application doesn't support a lot of formats (mostly text and bitmaps) and some data is only valid at the time when they were copied and require that the data source is live when the data is pasted. You can use the drop target analyzer application from the Drag and Drop Component Suite to see the impact, in terms of requests made to the data source, of running the Windows clipboard history in the background. The drop source analyzer can be used to examine the difference between data copied directly from the clipboard and data that has been through the clipboard history.

I would just use F8 (Step over) but it shouldn't make a difference. Where do you assign a value to c and where is pLayer (which I assume is a dynamic array) initialized? I think you need to show us some more code so we can make sense of what you are doing - and please use the code block.

Seems reasonable; I'll go ahead with that. Even if it ends up a bit higher I wouldn't see a problem with that (for us anyway) but don't let that influence you 🙂 Thanks. Which is also the only reason we need it. Well, to be perfectly honest, although FUDscreen is annoying, I suppose it does guard against the binaries getting tampered with (e.g. infected) after install. They could have solved that another way though but we all gotta have something to do. Who said you can't survive on cutting each others hair (is that even a saying in English?). You misspelled TBD, if that was what it was supposed to say.

Well, aren't I the lucky one? I've just been tasked with finding a code signing solution for our build pipeline. So far the realistic candidates are: Use Bob's test-server PC in the closet and do it manually (Bob's not too thrilled). Use the certificate providers cloud solution and pay per transaction (not gonna happen). Some clever tool that seems to be designed just for our needs. So do you have any idea about what the price will be on this thing?

I might very well be wrong; I don't know enough about GDPR to say otherwise and I should probably keep my mouth shut about the topic. However, I do have some experience with GDPR having worked at medical device- and a pharmacy POS suppliers, with direct access to client/patient data. Only people who had been given permission to act as an agent of the user/customer were allowed to access user data. My point was not that the screenshot wasn't a GDPR violation but that it wasn't much different from the rest of the bug report. I agree; If the application just gathers data (screenshot or not) and sends it of without user consent to a third-party, which haven't been given permission to act as an agent of the user, then yes, there's definitely potential for a violation. But if the end-user is given opportunity to review the data then I believe it's their problem. With madExcept it's possible to have the user review the bug report data, and the screenshot if there is one, before it is sent. I can't remember if EurekaLog has a similar feature.

...and still not relevant to the OPs request

I don't think they understand what GDPR is about. Sending the screenshot would not be any different from sending a call stack or whatever else is in the bugreport. How the receiver treats the data is where GDPR becomes relevant.

Ah... Me neither 🙂

Don't you have the source?

If you contact a developer I'm sure they can figure out a way to translate this, uniquely identifying number, to a string value of your choice.

You can use the CompilerVersion constant. See system.pas The question really is: Why do you need this information at all? The users doesn't need it and supposedly you yourself know which version you used...

I can't really recommend anything with regard to KVM switches as I haven't used one in ages. But don't buy cables that are longer than what you need 🙂 Make a mockup of the whole setup and then measure the required lengths. Cables that are too long can make a mess of even the best designed system. My own system consists of a desktop PC, a laptop (connected to a docking station via Thunderbolt 4), two monitors and a single wired keyboard and Bluetooth mouse. I mostly just use the docking station for charging the laptop and then use remote desktop to connect to it from my desktop system. Both monitors have multiple inputs so I have them both connected to both the desktop and the docking station and if I want to I can then switch the active input on the monitors between the two systems. The keyboard and mouse I have to switch manually. All in all a bit cumbersome so I rarely do it this way.

Dependency Walker is really old and isn't really up to the task anymore. We used to be able to run Delphi in Dependency Walker and have it trace the loading of DLLs but on my system it just hangs forever when loading bds.exe. I guess there are simply too many dependencies. It also appears that it doesn't know about the rules modern versions of Windows uses to locate and load DLLs. I think your best bet is to use Process Monitor to see which DLLs (or BPLs) it's looking for but can't find. Remember to filter on bds.exe and stop the trace once the error occurs. The two files you listed doesn't matter. Forget about those. For example in my Delphi I have the design-time package GR32_D290 installed. GR32_D290 depends on the run-time package GR32_R290. If I now delete (or rename) GR32_R290 I get the following when I start Delphi: and I get this in Process Monitor: bds.exe FASTIO_NETWORK_QUERY_OPEN C:\Users\Public\Documents\Embarcadero\Studio\23.0\Bpl\GR32_D290.bpl FAST IO DISALLOWED bds.exe IRP_MJ_CREATE C:\Users\Public\Documents\Embarcadero\Studio\23.0\Bpl\GR32_D290.bpl SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened ...etc... followed by a lot of: bds.exe FASTIO_NETWORK_QUERY_OPEN D:\Development\Embarcadero\Studio\23.0\bin\GR32_R290.bpl NAME NOT FOUND bds.exe FASTIO_NETWORK_QUERY_OPEN C:\Windows\SysWOW64\GR32_R290.bpl FAST IO DISALLOWED bds.exe IRP_MJ_CREATE C:\Windows\SysWOW64\GR32_R290.bpl NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a bds.exe FASTIO_NETWORK_QUERY_OPEN C:\Windows\System\GR32_R290.bpl FAST IO DISALLOWED bds.exe IRP_MJ_CREATE C:\Windows\System\GR32_R290.bpl NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a bds.exe FASTIO_NETWORK_QUERY_OPEN C:\Windows\GR32_R290.bpl FAST IO DISALLOWED bds.exe IRP_MJ_CREATE C:\Windows\GR32_R290.bpl NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a ...etc... I.e. one NAME NOT FOUND for each entry in the search path.

You are inspecting the value of j too early; It hasn't been assigned a value yet. The debugger stops on the breakpoint at the location just before code is executed. Not after the code has been executed. If you step one line into the loop then j will have been assigned the initial value.

https://github.com/graphics32/graphics32/blob/e38452f2eeb1dd234cf6dae91edee51488453602/Source/GR32_System.pas#L146 // Set process affinity to exclude efficiency cores function SetPerformanceAffinityMask(Force: boolean = False): boolean; procedure RestoreAffinityMask;

First of all, I can confirm that this happens. I'm responding to this old post because I just had to deal with this problem myself; Our product has had this bug for many years but it was low priority and none of the attempts to fix it had any success. Anyway, when calling BeginDrag(False): The drag isn't started until the mouse movement exceeds the configured threshold. The drag image is displayed immediately. #1 is as excepted and documented. #2 is a bug in the VCL and it's been there for decades. The way one would normally use BeginDrag(False) is from within a OnMouseDown event handler. Since the drag image is shown immediately, before a drag is detected or not, it means that simply clicking on the drag source will display the drag image and then immediately hide it again. Clearly not the intention. Like the VCL docking code, the dragdrop code is so convoluted that I imagine that the Embarcadero engineers would rather find a new job than try to fix it. Instead they changed the documentation so it's now unclear when the image is shown. In the end the only way to solve this is to avoid BeginDrag(False) and implement the start-drag logic manually. This means: Capturing the mouse. Monitoring mouse messages for mouse-up and mouse-move and detect movement beyond the drag threshold. Monitoring keyboard messages for the [Esc] key. Start the drag, regardless of movement, if the mouse stays down for 500mS. Luckily Windows provides us with a function that does all this for us: DragDetect Unfortunately DragDetect has some side-effects (and a few bugs of its own). Notably it eats the mouse-up message (WM_LBUTTONUP et al.). For us this was a problem because it meant that the control that was clicked (if it was indeed a click and not a drag) didn't get to handle mouse-up. In our case the control was a DevExpress grid and without the mouse-up message it became impossible to get a cell into edit-mode by clicking on it with the mouse; Not acceptable. So what to do? Well, I finally remembered that I had solved a similar problem, many, many years ago and, long story short, the solution is to use the DragDetectPlus function from the Drag and Drop Component Suite. procedure TMyForm.SomeControlMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); begin if (Button <> mbLeft) then exit; // Various additional logic to determine if we should initiate a drag goes here... // Initiate a drag (* Doesn't work; Drag image is shown immediately SomeControl.BeginDrag(False); *) (* Doesn't work; DragDetect eats WM_LBUTTONUP if DragDetect(SomeControl.Handle, ClientToScreen(Point(X, Y))) then SomeControl.BeginDrag(True); *) // This works; DragDetectPlus doesn't eat WM_LBUTTONUP if DragDetectPlus(SomeControl.Handle, ClientToScreen(Point(X, Y))) then SomeControl.BeginDrag(True); end; With this solution the drag is only started, and the drag image is only shown, when and if the mouse is moved (or the time expires) - and the mouse-up event is left in the message queue.