Leaderboard

Yes, you are going to use IOTA but you really need to read up on this topic until you understand it. The basic steps you must take is something like this (pseudo code; don't try to compile it): // Open the file in the IDE (BorlandIDEServices as IOTAActionServices).OpenFile('my_unit.pas'); // Get the file "module" var Module: IOTAModule := (BorlandIDEServices as IOTAModuleServices).FindModule('my_unit.pas'); // Iterate the module files for var i := 0 to Module.GetModuleFileCount-1 do begin // Get a module file editor var Editor: IOTASourceEditor; if not Supports(Module.GetModuleFileEditor(i), IOTASourceEditor, Editor) then continue; // Make the editor visible Editor.Show // Get an editor view if (Editor.GetEditViewCount = 0) then continue; var EditView: IOTAEditView := Editor.GetEditView(0); // Set the caret position var Position: TOTAEditPos; Position.Col := 1; Position.Line := ... EditView.SetCursorPos(Position); // Scroll to make caret visible and 15 lines down from the top Position.Line := Max(1, Position.Line-15); SetView.SetTopPos(Position); end;

That's easy to fix. You just make sure that they call internal methods only. Not really. You can store the FPCR to a local variable in the exported method. The thing is, the change in Delphi 12 isn't actually causing any new issues. These issues always existed. It's just a consequence of the "design" of DLLs not making FPCR part of the ABI.

The first patch for the just released RAD Studio 12.1 Athens is available: RAD Studio 12.1 Athens Patch 1 Available

It just looks like the easiest to implement, but most of the time it turns out to be the hardest to get it done right. Another approach is to wrap the code into some TThread.ForceQueue construct. F.i. a loop calling Applicaton.ProcessMessages can be refactored like this: procedure DoAllTheThings; begin DoSomething; while DoWeNeedToWait do Application.ProcessMessages; DoWhatEverIsNecessary; end; Refactored: procedure DoAllTheThings; begin DoSomething; DoTheRest; end; procedure DoTheRest; begin if DoWeNeedToWait then TThread.ForceQueue(nil, DoTheRest) else DoWhatEverIsNecessary; end; All the code is still executed in the main thread, but there is no loop blocking anything.

And for convenience, use a global variable to store the state ... gd&r

FPCR can be set in a thread safe manner. it is just that Delphi RTL doesn't do that on Windows platform. David has written about it see and https://stackoverflow.com/a/27125657 I have also written about it in my book Delphi Thread Safety Patterns. Working with masked FPU exceptions is the norm across various languages. Also even before Delphi 12, all other Delphi platforms except Windows VCL has masked FPU exceptions. So if you had written FMX application it would have been working the same way it is working now across the board. So the best option is moving to the masked FPU exceptions as this will create the least amount of trouble for the future. Of course, if you are dealing with Delphi built DLLs which don't honor that, you will have to adapt. Another option is to unmask exceptions and proceed as usual, but doing that in multithreaded application is not advisable unless you also patch the RTL as it is not thread-safe. Even having masked FPU exceptions is not thread-safe, but it is much harder to trigger the issue and much easier to avoid RTL API that uses unsafe parts than with unmasked exceptions.

That is just like Application.ProcessMessages works: It processes the messages in the queue. If one of those messages calls Application.ProcessMessages in a loop, the outer Application.ProcessMessages will only get control back when that inner loop ends and the event call returns. IMHO, you can safely remove the frivolous in your last statement.

By definition, a TryXXX() function does not raise an exception into user code. TryISO8601ToDate() is no different. Now, it may be that it generates an internal exception on failure, but that is merely an implementation detail, such an exception will certainly not escape into user code. If you don't want to see the exception inside the debugger, you can configure it to ignore EDateTimeException and EConvertError exceptions. Regarding that exception, TryISO8601ToDate() is implemented backwards than other TryXXX() functions. In most RTL functions, DoX() calls TryDoX() to do the actual work, and then raises an exception if TryDoX() fails. But TryISO8601ToDate() is different - it calls ISO8601ToDate() to do the actual work, and then suppresses any exception that ISO8601ToDate() raises. What they SHOULD have done instead is move ISO8601ToDate()'s logic into TryISO8601ToDate(), and then make ISO8601ToDate() raise if TryISO8601ToDate() fails. But, it turns out that ISO8601ToDate() raises a different exception message depending on why it fails. Perhaps they could have created a new internal function do perform the actual work and have it report the failure reason to the caller, then TryISO8601ToDate() could ignore the reason, and ISO8601ToDate() could raise an exception based on the reason. Oh well...

Have you tries with the SDK/NDK/JDK that are shipped with the Delphi originally? https://delphiworlds.com/2024/04/delphi-12-1-and-codex-2-2-released/ I think this might be critical, because of the deep changes in this Android tools and internals. I would recommend to stay with the original D12.1 setup and files in the first place, if there is no specific need to really upgade the SDK.

We are talking about a DLL here, so your code might not be multithreaded, but the caller's still might be.

Disappointing, as other Tryxxx routines avoid raising exceptions.

The patch is available via getit, I just installed it.

DLLs should take charge of this. They should either make it part of their contract that the host sets the fp control state to a specific state. Or they should set it on entry, and restore it on exit. My DLL does the latter.

Lots of talk not much code... Here is my test type IImplementsStuff = interface(IInterface) ['{83B3CBFA-9854-4BFC-A7B3-A015BE6B8B0B}'] // Interface methods end; [TestFixture] StringUtilsTests = class public [Test] procedure InterFaceToGuid; end; implementation uses SysUtils; procedure StringUtilsTests.InterFaceToGuid; var GUIDStr: string; begin GUIDStr := GetInterfaceGUID(TypeInfo(IImplementsStuff)); Assert.AreEqual('{83B3CBFA-9854-4BFC-A7B3-A015BE6B8B0B}',GUIDStr); end; Here is my implementation: function GetInterfaceGUID(const TypeInfo: PTypeInfo): string; var TypeData: PTypeData; GUID: TGUID; begin Result := ''; if TypeInfo.Kind = tkInterface then begin TypeData := GetTypeData(TypeInfo); // Correctly handle the conversion from byte array to TGUID Move(TypeData.IntfGuid, GUID, SizeOf(TGUID)); Result := GUIDToString(GUID); end else raise Exception.Create('Provided type is not an interface'); end; Hope it helps you as well as anyone else who needs it

Can we stay on the topic, please? Are there any practical languages that are applicable to writing the same variety of solutions as Delphi, that are actually memory safe? Even if you manage your memory in Delphi, it is not hard to get corrupted data due to a dangling or misdirected pointer, even in Delphi.

Yes, although more of a helper. Removes the with identifier do [and begin/end statements if present] and copies "identifier." to the clipboard so you can easily paste it where needed. It does not automatically determine which fields need the "identifier." added. Very simple example: Before: with Form1 do begin Left := 200; Top := 100; end; Invoke MMX Convert with: After: Left := 200; Top := 100; And "Form1." is in the clipboard to be manually pasted where needed.

Actually, in my case it sometimes is "just because I can". I use Delphi not only to pay my bills, sometimes I just want to have some programming fun, and I imagine I'm not alone. But yes, there are actual reasons to use features in Delphi that are frowned upon by some people, even the discouraged goto.

Yeah, you are wrong. Such people exist. I am one. Not necessarily. No reason why pointer arithmetic should be faster than, for example, plain indexing of arrays. Again, good compilers are often better than humans. I don't think pointers are used in the RTL especially more than other libraries, and I don't think pointers are used there fore for optimisation and performance. As far as this whole memory safety debate goes, you can't exclude the RTL from it. That code executes in the code that is subject to attack.

The way Swift works is that you can declare value with either the keyword let or the keyword var. If you use let the value cannot be changed. But the expression you assign to a let value can be anything available at that point.

The biggest issue with the Delphi code is that it forces heap allocation on you which is the real bottleneck.

Better to use CompilerVersion (and RTLVersion) instead, then you don't need to update the defines every time a new version is released, only when you need to add a new define, eg: {$IF DEFINED(DCC) OR (CompilerVersion < 23)} {$DEFINE EC_DELPHI} {$IFEND} {$IF CompilerVersion >= 20} // Delphi 2009 {$DEFINE EC_UNICODE} {$IFEND} {$IF CompilerVersion >= 34} // Delphi 10.4 {$IF CompilerVersion < 35} {$DEFINE EC_VCL27} {$IFEND} {$DEFINE EC_VCL27_UP} {$IFEND} {$IF CompilerVersion >= 36} // Delphi 12 ... {$IFEND}

Those few cycles mean nothing comparing to constructing the whole component over and over again. So this kind of safeguard can be easily implemented without having any negative side effects. The property itself could be left as-is, but initial value can be set in constructor depending on the thread ID value: FMultiThreaded := TThread.CurrentThread.ThreadID <> MainThreadID;

This looks like two questions. The first part is not currently possible using Delphi code, since there's no option to use AccessibilityService (there is for a plain Service and JobIntentService) In order to use UssdResponseCallback you need to write Java code, since you need to create a descendant of it (this is otherwise not currently possible in Delphi), and override its methods. You could define a Java interface that the descendant takes as a parameter in its constructor, and uses to redirect the overridden methods, much like I have in the code here: https://github.com/DelphiWorlds/Kastri/tree/master/Java/Base/Connectivity This Java code would need to be compiled into a jar which the Delphi app can consume. You would need to import the Java code into Delphi code. Using the same example above, this is the corresponding Delphi import: https://github.com/DelphiWorlds/Kastri/blob/master/API/DW.Androidapi.JNI.DWNetworkCallback.pas The next step is to construct a class that implements the interface defined earlier. Following the same example, that is TNetworkCallbackDelegate in this unit: https://github.com/DelphiWorlds/Kastri/blob/master/Features/Connectivity/DW.Connectivity.Android.pas You would then create an instance of the "delegate", and pass a reference to that when creating an instance of the descendant. Again following the above example, it would be similar to the code here: https://github.com/DelphiWorlds/Kastri/blob/82da3db3d0a526f6e93a30f3eb1a6c14779399bb/Features/Connectivity/DW.Connectivity.Android.pas#L98

Rethinking Delphi Floating Point Control Register Management.pdf

Example of a "large" VCL app (120 MB exe, using dll's, DB,...) running on VirtualUI. App is intended for desktop only, but VirtualUI allows to support users on MAC's, Linux... Works just fine, but needs a few more lines of code to handle uploads, downloads, etc. but it's doable. Resource use is heavy, but basically a matter of hardware on the server side. Go to: http://coolselector.danfoss.com/ and launch "Coolselector Online" a bit down the page.