Remy Lebeau

Yes, if you try to open those dialogs at design-time and the control has not been registered with the IDE yet. But if the dialogs create the control dynamically in code, then there is no problem. Probably, yes. It depends on your use case. Are you expecting other projects to use those dialogs? ICEs are compiler bugs, only Embarcadero can address those. You have to change your code to avoid them. Can't help you with runtime errors without more detail.

You are not resetting ms.Position=0 before calling Param.LoadFromStream(). You are also leaking the TMemoryStream.

If you can use the components on external Forms, why would you think you can't use them on internal Forms, too? Not really. Can you clarify the issue you are worried about with more detail?

That code risks pointer truncation in a 64bit build. The integer typecast should be using NativeUInt or UIntPtr instead. Or, use pointer arithmetic via PByte instead. Also, the file list is a double-null terminated list, so make sure you account for that in case multiple files are dragged. Also, depending on the source, the file names may be using Ansi or Unicode characters, so pay attention to the DropFiles.fWide field.

https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#Disabling_Floating-Point_Exceptions_on_All_Platforms

I see only a single retry in that code. Have you tried reconnecting multiple times, perhaps with a small delay in between each attempt?

Why not simply catch the socket error and retry the failed operation?

You don't. The drag code is running inside of the Windows Explorer process. If it is not invoking the IDropTarget object inside of your process, it means the call is being blocked outside of your process, most likely by UAC/UIPI if your app is running elevated. Per the comments on your StackOverflow question on this topic:

It is a underlying Windows issue. Microsoft simply doesn't render MDI windows using modern styles or high DPI support (ie, MDI does not operate under DWM). That is why Embarcadero finally decided to revamp their MDI system in the VCL in Delphi 12: https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#MDI_Reworked_for_HighDPI_and_Styles Not on-hand, but I've seen MS employees verify the issue. I also found this tidbit, take it with a grain of salt: https://www.akadia.com/services/dotnet_software_design.html#The MDI (Multiple Document Interface) Approach Nobody ever claimed that .NET would replace COM. GDI+ augments GDI, but does not replace GDI. It is a well-known fact that after XP, MDI has been left behind in visual handling. MS simply never bothered to update MDI for modern systems. Feels like deprecation to me.

Technically, no. The layout is fine. But, if they had done the "politically correct" thing by extracting the union into a separate type, eg: _SHELLEXECUTEINFOW_Union = record case Integer of 0: (hIcon: THandle); 1: (hMonitor: THandle); end; _SHELLEXECUTEINFOW = record cbSize: DWORD; fMask: ULONG; Wnd: HWND; lpVerb: LPCWSTR; lpFile: LPCWSTR; lpParameters: LPCWSTR; lpDirectory: LPCWSTR; nShow: Integer; hInstApp: HINST; { Optional fields } lpIDList: Pointer; lpClass: LPCWSTR; hkeyClass: HKEY; dwHotKey: DWORD; u: _SHELLEXECUTEINFOW_Union; // DUMMYUNIONNAME maps to 'u' for C/C++ hProcess: THandle; // compilers that don't support nameless unions... end; Then referencing the hIcon and hMonitor handles would have to be done as SHELLEXECUTEINFO.u.hIcon instead of as SHELLEXECUTEINFO.hIcon, etc. The variant part keeps the syntax a little cleaner.

The Form's OnCreate event is not the best place to register the drop target. If your Form's window is ever recreated at runtime, you will lose your registration. Instead, override the Form's virtual CreateWnd() method and do the registration there instead.

It should not be undeclared. It is a public sub-type of TCustomListBox. The following is taken from FMX.ListBox.pas: TCustomListBox = class(...) ... public type ... TItemClickEvent = procedure(const Sender: TCustomListBox; const Item: TListBoxItem) of object; ... strict private ... FOnItemClick: TItemClickEvent; ... public ... property OnItemClick: TItemClickEvent read FOnItemClick write FOnItemClick; end; The following works fine for me in D12.2: uses ..., FMX.ListBox; procedure TForm1.Button1Click(Sender: TObject); var OnClickHandler: TCustomListBox.TItemClickEvent; begin OnClickHandler := ListBox1.OnItemClick; ListBox1.OnItemClick := nil; // ... ListBox1.OnItemClick := OnClickHandler; end; You could also use an inline variable and let the compiler deduce the type: uses ..., FMX.ListBox; procedure TForm1.Button1Click(Sender: TObject); begin var OnClickHandler := ListBox1.OnItemClick; ListBox1.OnItemClick := nil; // ... ListBox1.OnItemClick := OnClickHandler; end;

In order to use a loop correctly in the OnExecute event, you must call ProcessRequests() with WaitForMessage=false. Using WaitForMessage=true, ProcessRequests() will not return until the service is stopped, and the stop will set Terminated=true, thus making such a loop useless. If you want to prevent the service from being stopped at all while the TProcess is busy, then you can do one of the following: when starting the TProcess, set the service's AllowStop property to false and call the ReportStatus() to update the SCM, and then once the TProcess has finished you can set AllowStop back to true and call ReportStatus() again. leave AllowStop set to true, and have the OnStop event return Stopped=false (and set the service's Win32ErrCode or ErrCode property accordingly) if the TProcess is currently busy. On the other hand, if you want the service to stop normally but wait for the TProcess to finish, then you can handle that in the OnStop event. The service's Status is already csStopPending when the OnStop event is entered. Simply run a loop inside of the OnStop event to call ReportStatus() at regular intervals (not exceeding the WaitHint property) while the TProcess is busy so the SCM knows the service is not frozen. Once the TProcess has finished, then OnStop can return Stopped=true, which will update the SCM with a status of csStopped. As I explained earlier, the OnExecute code you have shown is basically useless and should be eliminated completely. I would not use that approach. The init code should be in the OnStart event. The termination code should be in OnStop event. The OnExecute event should be eliminated whenever possible. Yes, and yes. Yes. For example: void __fastcall TService1::ServiceStart(TObject *Sender, bool &Started) { TProcess->Enabled = true; log1.Log(L"Service started"); Started = true; } void __fastcall TService1::ServiceStop(TObject *Sender, bool &Stopped) { while (TProcess->Enabled) { Sleep(WaitHint-100); ReportStatus(); } log1.Log(L"Service STOPPED"); Stopped = true; } void __fastcall TService1::TProcessTimer(TObject *Sender) { ... if (some condition) { TProcess->Enabled = false; if (Status != csStopPending) ServiceController(SERVICE_CONTROL_STOP); } ... } One thing to keep in mind - you keep saying the TProcess is a "timer method". If you mean a TTimer, then such a loop in the OnStop event would block the timer from firing any further OnTimer events, unless you manually pump the service thread's message queue to dispatch WM_TIMER messages. You would have had to do that anyway in the OnExecute event, if you start the timer in the context of the service thread. Personally, I never do any work in the service thread directly. I always have the OnStart event create a worker thread, and then have the OnStop event terminate the worker thread and wait on it. If I need to do things at regular intervals, I have the worker thread use a Waitable Timer Object or Waitable Event Object in a loop.

Your project was likely missing the relevant package references. Recreating the components updated the project.

Is TSpinEdit present on the Component Palette? Is the "Embarcadero Sample Components" package ($(BDS)\bin\dclsmp280.bpl) installed in the IDE in the "Component | Install Packages..." dialog? That is the correct unit.

That is because you are calling ProcessRequests() with the WaitForMessage parameter set to true. Not only is that blocking your while loop until a new SCM request arrives, but it also runs an internal loop that will not exit until a SERVICE_CONTROL_STOP request is received. ProcessRequests() will call Terminate() when processing a SERVICE_CONTROL_STOP request. So, your while loop will run AT MOST 1 iteration when using WaitForMessage=true. If you need to call ProcessRequests() yourself and be able to do other things in between calls (ie your Sleep(), etc) then you must call it with WaitForMessage=false instead, so it will exit immediately if there is no SCM request pending. Correct, because you are satisfying the condition that ProcessRequests() is waiting for. See above for why that approach will not work as you are expecting.

You can use ServiceThread->Terminate() instead. Yes, that will work, too. You can send it any control code that you can pass to ControlService(), such as SERVICE_CONTROL_STOP. If that is all the code your OnExecute handler has then you don't need to have the handler assigned at all. When OnExecute is not assigned a handler, the service handles SCM requests automatically by default. When you assign an event handler, you become responsible for handling requests yourself.

What is the goal here? GetTickCount64() is available in Vista (6.0) onward. The page you quoted says the 64bit tick counter existed in 5.1, but wasn't actually in use until 5.2. So 5.2->6.0 is a pretty small window if you are just looking to emulate GetTickCount64() on pre-Vista systems.

You are accessing a 64bit tick counter that is located at fixed address (0x7FFE0000+800), but according to this discussion: https://groups.google.com/g/comp.lang.asm.x86/c/zA0WcO6_5AU, in XP SP1 and earlier at least, the tick counter was a 32bit integer located at address (0x7FFE0000) instead. According to the history outlined here: https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/ntexapi_x/kuser_shared_data/index.htm, Windows deprecated the 32bit counter and switched over to the 64bit counter in v5.2 (ie, XP Pro 64bit) onward.

They are called Unit Scope Names, not qualifiers. And don't confuse them with Namespaces, which uses a similar naming syntax but different semantics. Here is a useful site: List of Delphi Pascal Features and When Introduced

See the documentation: Properties (Delphi): Storage Specifiers

Sounds like the property isn't declared/coded properly. But without a specific example that demonstrates the problem, it is very hard for anyone here to diagnose it.

Sorry, but there is no native option for that. Only 3rd party solutions like GExpert. Can you be more specific?

https://github.com/IndySockets/Indy/wiki/Documentation/ https://github.com/IndySockets/Indy10Demos The link itself works just fine. Perhaps you are referring to the fact that the website has pages missing? https://www.indyproject.org/2021/02/10/links-to-old-indy-website-pages-are-currently-broken/

Why are you looking at Indy 9 snippets and not at Indy 10 snippets? Yes. All of the I/O methods that were present in the TIdTCPConnection class in Indy 9 were moved to the TIdIOHandler class in Indy 10, eg: IdTCPClient1.IOHandler.WriteLn('start'); ListBox1.Items.Add(IdTCPClient1.IOHandler.ReadLn); Also, many of the older writing methods in Indy 9 were renamed to Write() overloads in Indy 10.