Remy Lebeau

Yes, for the most part, a plain DLL can do that. Just be careful about accessing anything across the DLL boundary that is version-specific. Keep the interface between DLL and EXE simple - stick to functions and simple POD types or OS-managed types only. No classes, no Delphi-managed types, etc.

Stay away from 'using namespace std;' !!! https://stackoverflow.com/questions/1452721/whats-the-problem-with-using-namespace-std Your count identifier is likely conflicting with std::count(). The compiler doesn't know which one you want. Consider using this instead: //using namespace std; using std::cout; using std::endl; using std::system; Or, put your count global variable in its own namespace. (Also, you are missing #include <cstdlib> for std::system())

You can't, without patching the EXE or recompiling the RTL. Nor should you be doing so. You should be complaining to CrowdStrike instead. And code-signing your EXE.

The RTL looks for Wine as part of its check to know whether it can use the Win32 API to access TLS (thread local storage) data, instead of using direct access to the GS register.

Those settings only affect WinInet/WinHTTP (which Indy doesn't use), they have no effect on OpenSSL.

This is documented behavior: https://docwiki.embarcadero.com/RADStudio/en/Anonymous_Methods_in_Delphi

It is actually legal code and does compile: https://onlinegdb.com/AYf40CsUy This kind of reverse syntax is not commonly used, but it does have its uses, and the C++ standards allows it. For an array, arr[2] is the same as *(arr+2), and thus 2[arr] is the same as *(2+arr).

Feel free to file a bug report with Embarcadero.

ExecSQL() is not supposed to be used for SQL statements that return data. You normally have to use Open() instead, or set Active=true. That being said, RETURNING values can be accessed using an output parameter, which ExecSQL() should be able to fill. Depending on the driver you are using, the syntax may differ slightly, eg: ... ExecuteQuery(SqlQuery, false); DatabaseId := SqlQuery.ParamByName('RET_database_id').AsInteger; Or: ... with TParam(SqlQuery.Params.Add) do begin Name := 'database_id'; DataType := ftInteger; ParamType := ptOutput; end; ExecuteQuery(SqlQuery, false); DatabaseId := SqlQuery.ParamByName('database_id').AsInteger;

In C++, that example would look like this: #include <iostream> int main() { int value = 42; int *p_int = &value; std::cout << "p_int points to " << *p_int << std::endl; // 42 int arr[] = {100, 101, 102}; p_int = &arr[1]; std::cout << "p_int points to " << *p_int << std::endl; // 101 ++p_int; std::cout << "p_int points to " << *p_int << std::endl; // 102 ++p_int; std::cout << "p_int points to " << *p_int << std::endl; // (OUT OF BOUNDS - UNDEFINED BEHAVIOR!) }

Such a version has NOT been released yet. Still a work in progress. The next Indy version that is pending release (10.7) will be splitting off all OpenSSL support into a new package, IndyTLSOpenSSL, as an add-on to the main Indy packages. It has its own repo: https://github.com/IndySockets/IndyTLS-OpenSSL v1.0 will focus on backwards compatibility as users update their existing projects to include this new package without changing the rest of their code. Then v2.0 will be for adding OpenSSL 3.x. In the meantime, there are a few 3rd party projects already available now that bring OpenSSL 3.x to the current Indy. You cannot have multiple versions installed together. The GitHub version is not compatible as-is with the default bundled version. You will have to use one or the other. I can't answer that. Each 3rd party project that has been released so far has its own way of doing things. Use what is appropriate for whatever project you decide to use. What will end up in the new IndyTLSOpenSSL package is not finalized yet.

Is it really worth it?

You can't normally have multiple versions of the DLLs with the same file names loaded at the same time. But, in this case, you can't just rename the DLLs either, because IIRC one of them depends on the other using the original filename. You could try wrapping the old unit code inside of an Activation Context so it can use the older DLLs while the rest of your app uses the newer DLLs. But, this is a pretty advanced technique. Otherwise, if you can't update the older unit to use the newer DLLs, then you will probably be best off splitting the two codes into separate EXEs with different DLL dependancies.

That code can be simplified: procedure TForm1.PageControl1Change(Sender: TObject); var sheet : TTabSheet; frame : TFrame2; begin sheet := PageControl1.ActivePage; frame := sheet.Components[0] as TFrame2; StrLines.Assign(frame.Memo.Lines); ListBox1.Items.Assign(frame.Memo.Lines); end;

On a side note - the TFrame should have an Owner assigned, not just a Parent, eg: memo := tframe2.Create(TabSheet);

The most direct/efficient way is to put the Memo object pointers into an array or list, and then use the integer as an index into that container.

For the benefit of others who will read this discussion in the future... You are simply missing the closing outer quote: cout << "Looking for the index position of the word \"own\""; ^ You might also consider using your 'word' variable: cout << "Looking for the index position of the word \"" << word << "\""; Also note that C++14 and later has the std::quoted stream manipulator: #include <iomanip> ... cout << "Looking for the index position of the word " << std::quoted(word);

Yes - don't make a copy at all! Use a TFrame instead. https://docwiki.embarcadero.com/RADStudio/en/Working_with_Frames At design-time, create a new TFrame class, put a TMemo on it, and configure it as needed. Then at runtime, you can create a new instance of your Frame class (which will have all of your design-time property values) and assign a Parent to it as needed. In this case, a new TabSheet. With this approach, you also won't need to waste a TabSheet at design-time just to hold your default values. But, if you really want to, you can place your Frame on the 1st TabSheet at design-time, too.

Done RSS-2712: Android Fix Stretched Splash Images

Read the OP's opening message again more carefully. They want to handle WM_DROPFILES manually and disable the default behavior for inserting dropped image files.

Did you file a report to request it? https://qp.embarcadero.com

That is not quite accurate. Yes, the app will terminate if the MAIN Form is closed. But the FIRST Form does not need to be the MAIN Form. The MAIN Form is the first Form created with TApplication.CreateForm(). But you do not need to use CreateForm() to create and show a Form. It is possible to show a Form before the MAIN Form is established.

Are you subclassing the RichEdit to receive WM_DROPFILES? Are you registering the RichEdit with DragAcceptFiles() to receive WM_DROPFILES? Unlike other UI controls, a RichEdit can send an EN_DROPFILES notification to its parent window when you drop files onto the RichEdit. Are you able to receive that notification?

There is not enough information to diagnose your problem. How are you creating and destroying the thread? Are you really destroying the thread TWICE before starting a new thread? What is your thread code doing besides creating the TStringList? We need to see a more complete code example.

I find it interesting that you clearly knew how to access the element values in the 1st range-for loop, but didn't know how to do the exact same thing in the 2nd range-for loop.