Remy Lebeau

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.

Focus Mode hides everything except the code editor.

I was simply fixing the broken syntax in uligerhardt's reply.

const OTHER_FLOAT_CONSTANT = Double(0.005);

You should file a bug report about that. Embarcadero spend a lot of effort revamping the MDI system in 12.0.

It is true that variables can't be initialized when using the 'var' block at the top of the function. But inline variables can be initialized: begin var foo: Integer := 10; // OK

Does it have to be Win10 specifically? Or is Win8 enough? The ability to use the WS_EX_LAYERED style on child windows was added in Win8.

Or, simply run each build in a separate cmd.exe instance so they each have their own environment. Changes made to the environment variables are local to each instance, not saved globally or across instances.

They stopped publishing roadmaps publicly, there hasn't been a new roadmap shown for several years now.

Have you read the documentation yet? https://docwiki.embarcadero.com/RADStudio/en/MSBuild https://docwiki.embarcadero.com/RADStudio/en/Building_a_Project_Using_an_MSBuild_Command

Do you have the same problem if you use MSBuild instead of invoking the compilers directly? Building a Project Using an MSBuild Command

You have that backwards. It doesn't. Libs that are shipped with the IDE are separated, but user-provided libs are not. So either separate them yourself, or don't have them both installed at the same time.

That won't work. SetPairs() expects a list, not a Set or an array. You would need to use this instead: JsonObject.SetPairs(TList<TJSONPair>.Create); This is because SetPairs() takes ownership of the new list, freeing the old list. The list can't be nil or else you risk crashes on future operations on the TJsonObject.

The "crew" is me. Since Indy 11 has been pending for a very long time, I've been considering lately about updating Indy 10 just to bring it more inline with Embarcadero's releases (ie, adding LIBSUFFIX, etc) sooner rather than later. Dropping older compilers, etc will still wait for Indy 11 for now.