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.

In HTTP headers, there is always a space after the colon, seems simple but sufficient to confuse servers. Angus

It also has the added benefit that it has an optional Delay parameter, if you need a longer sleep between steps, similar to a timer.

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.

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...

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

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

There's one in DWScript: https://github.com/EricGrange/DWScript/blob/c3a26f0e68a5010767681ea1f0cd49726cd4af5d/Source/dwsUtils.pas#L3169 I haven't used it though but knowing Eric, it's probably both fast and well tested. Pity about the 3-space indents though; Very French 🙂 Other than that: https://github.com/search?q=lang%3Apascal+iso8601&type=code

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.

Rethinking Delphi Floating Point Control Register Management.pdf