PeterBelow

Do it on the string itself, like you learned addition in school. function incrementID(const aID: string):string; var ch: Char; N: Integer; begin Result := aID; N:= Length(Result); while N > 0 do begin ch := Result[N]; case ch of '0'..'8': begin Result[N] := Succ(ch); Break; end; '9': begin Result[N] := '0'; Dec(N); end; '.': Dec(N); else raise Exception.CreateFmt('Invalid character "%s" in ID "%s" at position %d.', [ch, aID, N]); end; {case ch} end; {while} end;

You can change the visibility of properties inherited from an ancestor, you cannot do that with fields. The VCL itself makes heavy use of that.

As far as I can see this function does not wait at all, it just checks the task value and returns. Or does the getter for FTask.Value wait?

Real professionals have to earn money with their works, they don't have the time to reinvent the wheel, debug and validate it. If you want to shoot yourself in the foot be my guest, but don't expect me to supply the bullets...

Attached find a little example program that definitely works . FileEncryption.zip

You don't need to install the component, it is just a convenience wrapper. I'll try to create a small demo over the weekend, no time at the moment.

Make sure that all modal forms have PopupMode set to pmAuto and in the dpr file you have Application.MainformOnTaskbar := true; That avoids such isssues at least on classic Windows systems. I know nothing about Windows RD Web, though.

I use Lockbox 3 for such purposes.

See Tools -> Options -> User interface -> Form designer -> High DPI, the designer itself is now DPI aware and you may have to change the default setting if you design on a high DPI monitor.

Tools -> Options -> User interface -> Form designer -> High DPI

In Delphi 11 the designer itself can be configured to be DPI-aware. Which version are you using?

Unlikely, it would be reported much more frequently in this case. I have never seen it, for example, but in my case the only 3rd party package used is MMX...

Isn't that what it does now?

I think the core of the problem is an ambiguity inherent in the original language syntax inherited from the days of Turbo Pascal and earlier. 'x' can be interpreted either as a character constant or a string constant, and the compiler decides which it should be dependent on the context. A char is also assignment compatible with a variable or parameter of type string (but not vice versa). I see no way to get around this, and changing these rules will never happen since they make sense and changing them would break heaps of older code. Of course the compiler could use more stringent rules for overload resolution, e.g. require type identity and not only assignment compatibility. That would solve the conflict in the case you noticed but would be quite bothersome in other situations, requiring more overloaded versions of a function to be implemented. Think about what a type identity requirement would mean for overloaded functions taking numeric types as parameter. Do you really want to declare versions for byte, smallint, integer, word, cardinal etc. ?

There would probably be a conflict in overload resolution. Anyway, System.StrUtils contains IndexStr and IndexText functions that would serve your need here.

I have seen something like this occasionally (D 11.1 on Win10). Task Manager shows 100% use of one CPU core for the process. Sometimes it resolves itself after a few seconds but often the only option is to kill the process. On restarting the IDE it usually works normally. I have never been able to reproduce it at will.

The VCL is not thread-safe in itsself, creating top-level objects like forms, frames or datamodules accesses some global stuff in vcl.forms connected to reading components from the dfm file. Try to replace your datamodules with a class (not derived from TCustomForm) that creates and configures all components you now place at design-time in code. I dimly remember a tool that could create such code from a dfm file, never used it myself, though. Are all your threads created in the same host thread? If so that should actually mitigate the problem since the thread constructor runs in the host thread, so all datamodules would be created in the same thread. But that may cause another problem: database connections are usually bound to the thread that creates them. If the datamodule creation already creates the connection, which is then later used in the context of the thread that owns the datamodule that may cause problems since the db access library may try to solve the conflict by serializing all DB access in a separate thread. Multithreading using a database can be even trickier than multithreading itself...

As far as I remember this "feature" comes from the original Wirth Pascal in Delphi's anchestry. Dropping it now would break heaps of legacy code, so is very unlikely to happen.

A COM dll usually uses interfaces as callbacks as well, not function pointers. I know nothing about Docker so cannot give you any advice on this topic. .NET has an interface to unmanaged code, which is used to interact with the OS API, though. Your dll would be unmanaged code, you just have to make sure you do not use any Delphi-specific types (especially compiler-managed ones, like String or dynamic arrays) in the functions the DLL exports.

Create a COM dll, Delphi has a wizard for that. Google for "C# com interop" to find examples for how to use such a thing from the .NET side.

ModelMaker Code Explorer (MMX) can do this, as well as a lot of other things. Could not live without it... See https://www.mmx-delphi.de/ It is free and maintained.

The script is looking at the wrong version of the rtl package. 17.0 is not 10.2 Tokyo, that would be 19.0. Check the pathes used in the script or the dproj files it refers to. 17.0 is 10.0 Seattle if memory serves.

The error message looks like the designer tries to read values from a dfm file into a component that has not been created yet. Was this other project created with the same Delphi version? Does it open and compile in Delphi Alexandria? Does the form you are trying to use in the new project use any self-written or 3rd-party components you are not yet using in forms of the new project?

If you used the button OnClick handler from the link you gave it will not work unless uncomment the Application.ProcessMesssages call.

The source of your problem is probably the line TImage1.Picture.Assign(Image); Should'nt that be Image1.Picture.Assign(Image);