Anders Melander

When you recompile a design-time package that is currently installed then the IDE must unload that package before it can be linked. Now, if you at the same time have forms open that uses one of the components in that package, then the IDE must also close those forms and this is where it typically goes wrong (AVs, internal errors on compile, etc.). Why I don't know. It's probably a bug in the IDE:

I invite you to visit the bug tracker for any of Atlassians products (Jira, Confluence, Bitbucket, etc) and look at some of the existing requests. But leave all hope behind before you enter; The most popular requests, be it bug reports or enhancement requests, are often also the oldest - and we're talking decades. For example the request to have Confluence links open in a new window, a feature provided by just about every other web documentation tool, was rejected after almost 20 years of bad excuses. "Buy a third party solution" is their current stance. Unless a change directly translates to an increase in income then Atlassian doesn't give a sh*t if the request is reasonable. They survive on the sunken cost fallacy.

You asked about "things not accessible at the time the constructor is called" which is what I addressed. I can't see how the workings of OnShow and OnResize is relevant to that.

The properties that are calculated/updated on demand when the form or its controls are shown comes to mind. For example the position/size of aligned controls.

There's no problem with just using the components as long as you don't use them at design-time (i.e. place them on forms) as that could create a chicken/egg situation when the forms are opened on a system where the components hasn't yet been installed. If you need to use your components in the package, just create them dynamically in code.

On my system (Windows 10) the mouse pointer color setup is stored in HKCU\SOFTWARE\Microsoft\Accessibility\ in the values CursorColor and CursorType. However... I don't think this cursor color thing works the way you expect. AFAIK the values in the registry are only there so the Mouse Pointer control panel applet can display the current settings. The values indicate how the mouse pointer looks - they do not actually control it. What I think happens, when you change the mouse pointer color in the control panel, is that the applet create a set of cursor files with the desired color/mask and then write the config to the registry so it can display the setting the next time it is run. In other words, in order to change pointer colors, your application will need to: Create some cursor (.cur) files. Write them to the appropriate location on disk. Somehow get windows to load them.

Bite me

No; It works with all drop targets. And if you look at the WM_DROPFILES example there's also an example of working around the UAC restrictions mentioned by Remy: https://github.com/andersmelander/Drag-and-Drop-Component-Suite/blob/de46eb2b804c33921809504d086285da11d4e3e5/Source/DropTarget.pas#L298

Any authoritative sources for this? I've seen people make the same claim many times about both COM (claimed to be superseded by .NET) and GDI (claimed to be superseded by GDI+). Both ridiculous claims. Just because MDI windows doesn't support the same features as SDI windows doesn't mean that they're deprecated. The documentation certainly doesn't give any indication that it is so: https://learn.microsoft.com/en-us/windows/win32/winmsg/multiple-document-interface

No. In Delphi the variant part has to be the last in the record and, if you think about it, the hProcess field would have the same offset even if it was possible to declare it after the variant part. https://docwiki.embarcadero.com/RADStudio/Athens/en/Structured_Types_(Delphi)#Variant_Parts_in_Records

Is there are reason why don't just use one of these? https://github.com/landrix/The-Drag-and-Drop-Component-Suite-for-Delphi https://github.com/andersmelander/Drag-and-Drop-Component-Suite If you don't want to use a ready-made library then I suggest you at least use the DragTargetAnalyzer example application in the above library to diagnose your target.

Good thing we can invent new problems when we run out of actual ones to solve.

It does but the Win32 API is declared delay-load and the RTL resolves it dynamically with fallback to GetTickCount if it isn't available. I also believe Indy uses it but with a similar dynamic fallback. Winapi.Windows.pas function GetTickCount64; external kernel32 name 'GetTickCount64' delayed; // 6.0 System.Classes.pas function InitGetTickCount64: UInt64; stdcall; begin if TOSVersion.Major >= 6 then begin var kernelLib: THandle := LoadLibrary(kernel32); GetTickCount64Func := GetProcAddress(kernelLib, 'GetTickCount64'); FreeLibrary(kernelLib); end else GetTickCount64Func := @Winapi.Windows.GetTickCount; Result := GetTickCount64Func; end;

The required Windows version really depends on the the VCL features you use. If you're using something that is only available in Windows 10 then naturally your application will use Windows 10 specific APIs. Otherwise it will not.

You seem to be confusing "target" and "run on". In theory, all 32-bit compilers can target any 32-bit version of Windows and all 64-bit compilers can target any 64-bit version of Windows. That page just document the IDE requirements and it doesn't really reflect the reality; Before I upgraded to Windows 10 I had been running Delphi 10, 11 and 12 on Windows 7 with no issues. The installer complains but it ran just fine.

No, I can't see it from the sigmycode site either. I'm positive that I read somewhere on the digicert site that you had to use 2-factor-authentication using a USB token but I could very well have misunderstood the context.

TMI; People tend to ignore walls of text. Log operations on the server instead so they can be examined by those who care.

Looks good - and I like the name. Sufficiently distinct to be googleable.

Oh, nice. I didn't know you could do that. It's a real PITA that we have to jump through all these hoops with the physical tokens and the fact that a solution like yours, which is basically a work around, is even possible proves that it was all in vain. But I guess somebody made a lot of money selling the tokens.

Let me guess: The client transmits the file to be signed to the server, and the server (which has the physical token) then signs the file and transmits it back to the client.

...once they have signed in with an USB token. I don't think you can get around the requirement for the signer to have some kind of physical identification device.

Hmm. Okay. I obviously don't know how your build server setup was, or what build system you used, but it should have been possible to completely isolate the different projects. Independent projects, with different developers, tools, etc. on the same build server is nothing out of the ordinary. Anyway, if you are working on different projects, and don't want a centralized solution, then why not just use different certificates?

There's your problem. You should use a single central build server instead of delegating the build task to individual developers. If you don't have a central server which can function as a build server, at least designate one of the developers as the "build master".

Thanks. I just meant this: procedure TReptTextEditor.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); begin case Key of VK_F1: if Shift=[] then Application.HelpCommand(HELP_CONTEXT,HelpContext); VK_F10: if (ssAlt in Shift) then PopupMenu1.Popup(Left+100,Top+100); end; end; ...and that looks okay.

Use TJPEGImage.LoadFromStream to load from the stream Copy the TJPEGImage to a TBitmap using TBitmap.Assign Add the TBitmap to the TImageList using the usual methods