Leaderboard

Get a dog.

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;

Hi everybody, I encountered the same problem, opened case with embarcadero support that tell me the solution. In iOS 17.4 Simultator, Apple remote OpenGL support, so we must use Metal. In View Source of the project add as first line begin GlobalUseMetal := True; ... Also they told

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

ANN: StyleControls VCL v. 5.76 just released! https://www.almdev.com https://www.delphistyles.com StyleControls VCL is a powerful, stable package of components, which uses Classic drawing, system Themes, GDI+ and VCL Styles. This package contains the unique solutions to extend standard VCL controls and also has many unique, advanced controls to create applications with UWP / Fluent UI design. In new version we added many features, which requested by customers! Also we added new demo with Skia VCL interaction for Lottie Animations (RAD Studio 12.1 Athens)...

You can find some hints in the release notes for 11.2: 11 Alexandria - Release 2

Well, I'm shocked. You were right! I've moved the creation of the components from the initialization part to the Execute procedure and It's the same fast now as Indy. Also this will probably explain WHY my application crashed always ... (link to prev. topic about this problem) Thank you very much for the help! I truly recommend, the future versions of the component should check, and raise an error if: The creation and running thread are not the same? The first initialization (of loading SSL DLLs) and final destruction is not running in the main thread! Property of .Multithreaded is True while running in a background thread? (Can be automated too.) It's not just me, who recommended that:

ICS V9.2 has started the beta process, and can be downloaded from https://svn.overbyte.be/svn/icsv9/ or the overnight zip from https://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp This beta version of V9.2 adds a new feature release of OpenSSL 3.3.0 and fixes a number of bugs mostly introduced in V9.1, but also two long term HTTP URL in the client and server software where missing / delimiters could cause problems, and fixing server authentication issues with POST requests. Several others issues discussed on Delphi-Praxis are also fixed, but not all, yet. This beta also includes a new 'ICS Intermediate Short' SSL certificate to replace the one in V9.0 that has just expired, it is used by ICS to generate temporary server certificates to allow SSL servers to run until a Let's Encrypt or commercial certificate is installed. The OverbyteIcsSslMultiWebServ sample has various improvements to test authentication more thoroughly (the DDService version is not done yet). Only Delphi 10.41 and 10.42 (10.4 with updates 1 or 2) will install correctly with the new install packages, the original RTM version does not support the package LIB suffix: $(Auto) so you must change it manually for each package to 21.0. OpenSSL 3.3.0 is now the default in the OverbyteIcsDefs.inc file and the ICS-OpenSSL path, ICS does not use any of the new features (nor those in 3.1 or 3.2). Now that OpenSSL is more closely integrated with ICS, updating for security fixes will become more complicated, needing files in two or more directories to be updated. When OpenSSL does the next batch of security fix versions (scheduled quarterly), I'll generate a zip with all the new files and directories that can be extracted over an existing ICS installation with all the new files. Angus

{.$DEFINE OpenSSL_Resource_Files} will stop OpenSSL being linked, {$DEFINE] OpenSSL_ProgramData} then helps determine where the DLLs are located. readme9.txt now has a lengthy section describing all the defines. Angus

TIniFile will work on any file that conforms to the INI file format, and it seems the RemoteHost.cfg that you have uses the INI file format. But many, if not most, .cfg files will use a different format that isn't compatible with TIniFile.

Yeah, use threads

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

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.

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

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

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.

Correction, OpenSSL 3.3 was released last week and does not add QUIC for servers, that is scheduled for OpenSSL 3.4 due in October 2024. https://github.com/orgs/openssl/projects/11/views/3 OpenSSL 3.3 for Windows will be released later this week with ICS V9.2 beta. But there are no new features particularly relevant to ICS. Angus

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.

Done @David Millington https://www.delphipraxis.net/214805-arbeite-fuer-den-embarcadero-vertrieb.html

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}

Just to end this thread, I finally got my digital certificate, and I'm signing my applications. I kept a false positive version of the product to test signing it. Well it did work. That version wasn't compiled with DEP or SEH, and signing solved the false positive too. Hopefully this thread will help others

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