rvk

Did you download the 32 bit version or the 64 bit ones?

The DLL bitness must match your programs bitness.

There shouldn't be any need to set the IdOpenSSLSetLibPath.

But if you want to set it, you can do it with:

Initialization
  IdOpenSSLSetLibPath(ExtractFilePath(Application.ExeName));

Those licenses could also be revoked after some time by Microsoft.

You will never know beforehand.

https://www.howtogeek.com/392080/cheap-windows-10-keys-do-they-work/

1 hour ago, LeusKapus said:

Google is deprecating access to "unsecure apps" for Gmail for Business this February 15th.

This should have no impact for application passwords. Your application doesn't even need to be changed. Just use the application password instead of the regular GMail password.

You don't need LoadLibrary/FreeLibrary if you use a static function definition like "external myDLL". So use either LoadLibrary/GetProcAddress/FreeLibrary or use function/external myDLL.

Also... you use a string as parameter. That is a managed type. I'm not sure but that might give you problems.

2 minutes ago, Lars Fosdal said:

@rvk - My question was due to the comment in the docwiki link that explicitly mentions Firebird and Interbase.

Likewise, in http://docwiki.embarcadero.com/Libraries/Rio/en/FireDAC.Comp.Client.TFDCustomConnection.Transaction - it says "Note: At the moment, this behavior applies only for InterBase and Firebird connections."

Ah, yes. But Dmitry gave an example of SelectQuery.Transaction := ReadTransaction;

So I was talking about setting the actual transaction properties rather than talking about the fact the transaction-property itself is used or not.

It indeed seems to be that some of the explicit transaction assignments only work for Interbase/Firebird (???).

Also for the transaction of a TDataset: http://docwiki.embarcadero.com/Libraries/Rio/en/FireDAC.Comp.Client.TFDRdbmsDataSet.Transaction

Quote

Currently, explicit transaction object assignment is supported only for InterBase and Firebird.

How would one set transactions with specific isolation level for MSSQL and Oracle then ???

Doesn't FireDac support these?

This page does mention setting isolation level but also mentions it is for Firebird/Interbase.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Managing_Transactions_(FireDAC)

(FireDac might be even more rubisch than I initially thought if you can't set isolation level etc for other databases via the standard property)

1 minute ago, Lars Fosdal said:

Is it correct that the custom transactions only apply to Interbase and Firebird?

As long as you use the standard properties and values to set the isolation levels etc., they will work for all databases.

Most databases have transactions and you should be able set them the same way.

i.e. MSSQL and Oracle etc. all have Read Committed transactions levels. So transactions work the same way.

Only when setting special properties via the params, you'll get database specific.

2 minutes ago, Yaron said:

The actual DB call that triggered the deadlock was a view counter, two users viewing the same web page.

What is the best approach to handle such deadlocks?

By setting the correct isolation level, record version and wait-option for the transaction.

https://ib-aid.com/en/how-to-track-deadlocks-in-firebird/

As I said I'm not familiar with FireDac so I'm not sure how to set it.

https://stackoverflow.com/a/56337589/1037511

(Something like read_committed, rec_version and nowait should fix deadlocks on select)

For good measure I would add Connected := false after dbQuery.ExecSQL;

(But my guess this is also done in dbConn.Free)

dbQuery.ExecSQL;
dbConn.Connected := false;

But I see you update the table in the thread. You didn't do that in your original post.

The deadlock can come from using transactions incorrectly (or updating the same record in different transactions/threads),

http://www.firebirdfaq.org/faq151/

18 minutes ago, Fr0sT.Brutal said:

And disconnecting a connection is senseless, it's not much different from creating/destroying a connection object every time.

It's not if you're using a pool. When using a pool the connection is given back to the pool. It's not closed. At least that's what the documentation says.

Setting TFDConnection.Connected to True acquires a physical connection from the pool.

Setting TFDConnection.Connected to False releases the physical connection to the pool, but keeps the connection opened.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Multithreading_(FireDAC)

But maybe the TFDConnection.Free already does that.

What's your code like now?

Maybe putting a amNonBlocking in there?

FDQuery1.ResourceOptions.CmdExecMode := amNonBlocking;

You're not updating anything so I'm not sure why there would be a deadlock there.

You set the TFDConnection.Connected to false afterwards in the thread? (because that releases the connection back to the pool)

Yes, that sometimes happens to me too.

Often this is due to the IDE not recognizing some lines and not knowing it already has a {$R *.res} line.

Sometimes reordering the uses-units and other elements will fix this (if it keeps happening).

(I had to move my {$R} lines above the uses- and {$SETPEFLAGS} lines.)

Look in your project source (the .dpr file)... do you have multiple {$R *.res} lines?

I have no experience with FireDac, but shouldn't you create a TFDConnection in each thread to be used with TFDQuery?

As is shown in http://docwiki.embarcadero.com/RADStudio/Rio/en/Multithreading_(FireDAC)

4 hours ago, PeterPanettone said:

Or is there a way to activate both the 32-bit hook AND the 64-bit hook with ONE SINGLE exe?

I'm not sure but there might be a way to do it from one exe. But that might be really advanced stuff (haven't looked st the details).

A 64-bit process can access a 32-bit DLL across a process boundary if the 32-bit DLL is loaded into a separate 32-bit surrogate process space, and the application makes use of the built-in IPC mechanisms that support data exchange between 32-bit and 64-bit processes.

https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/

15 minutes ago, jon_bondy said:

One thing that puzzled me was that the code without permissions was working on another Android device, but not this one.

Because with older Android version the permission is given during install (if it's asked for by the program). With newer Android the permission needs to be given during runtime (because during install everybody just clicks through without thinking).

If you set the proper permission in the manifest you might be able to manually 'activate' that permission in the permission section of the App-settings in Android (instead of asking this via your program).

(But for a production program it is best to ask for it in the program itself)

Just now, PeterPanettone said:

... that would be GREAT!

See my previous post, because I already got this working.

27 minutes ago, PeterPanettone said:

Are there any grown-up people here?

Yes, there are... (although I could also appreciate the comment of FredS )

I have it working here in 64 bit.

Besides the INVALID_HANDLE_VALUE I mentioned earlier, you need to use the correct GetMsgProc() definition.

The one now used is only valid in 32 bit.

If you change it into this it worked here (both in the implementation and interface part).

Quote

function GetMsgProc(Ignore: integer; wParam: Windows.WPARAM; uMessage: Windows.LPARAM): LRESULT; stdcall;

(although you might want to avoid a parameter named wParam because it is also a type in the Windows unit which you need, solved here with unit-prefixing)

1 minute ago, PeterPanettone said:

However, I also do not get a callback when clicking on any system menu item in any application.

Yep. That was my conclusion too. There still must be something wrong.

Using WH_CBT you do get some messages. There supposed to be a HCBT_SYSCOMMAND message containing the information but I haven't looked at it further.

22 minutes ago, PeterPanettone said:

The error seems to be in the DLL code in the function Hookup in the line GetMsgProcRec^.Hwnd := Hwnd:

   Access violation at address 0000000003585C9F in Modul 'fwGetMsgProc.dll'. Reading from address 0000000000000000.

The reason for this is because GetMsgProcRec seems to be nil in the DLL.

It seems that the call to CreateFileMapping fails in 64 bit.

For testing this you can add your fwGetMsgProc dll project to the projectgroup of TESTHks and debug the dll-calls.

Set a breakpoint in InitializeDll and you'll see it stops at the first MappedMem line.

Next (on the second try) trace into the procedure with F7 and you'll see the exception for cErrorCreating,['TMappedMem'] is called.

You'll see a $FFFFFFFF as parameter, meaning an invalid handle (see https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createfilemappinga)

But INVALID_HANDLE_VALUE is THandle(-1) which is something different then $FFFFFFFF in 64 bit. (you'll need $FFFFFFFFFFFFFFFF)

So change it to

Quote

    fHandle := CreateFileMapping(INVALID_HANDLE_VALUE, nil, PAGE_READWRITE, 0,  Size, PChar(Name));

Now the hook can successfully be installed.

(I hadn't much luck with catching anything but now you're a step closer )

16 hours ago, PeterPanettone said:

How can I make it sending a message to my application's window?

I don't think 'injecting code' is the best way to go.

I think you need to catch the WM_SYSCOMMAND which is sent to the other application(s).

You should be able to do that with SetWindowsHookEx().

https://social.msdn.microsoft.com/Forums/windows/en-US/f87193b7-ccc2-4c30-9b1e-195addd375c8/how-to-intercept-a-wmsyscommand-sent-to-another-app?forum=winforms

An example in C++ http://forums.codeguru.com/showthread.php?161054-System-wide-hook-for-WM_SYSCOMMAND

Ah, Ok. I wanted my backup script to make transportable backups. nbackup doesn't do that (but is faster because of it). Because speed isn't an issue (because both can backup a database while in use and I only make daily backups, not hourly) I went for gbak.

https://firebirdsql.org/manual/nbackup-overview.html

I did something similar with gbak i.c.w. nextcloud and the task scheduler (inside a cmd-script).

Any reason to prefer nbackup above gbak?

4 minutes ago, aehimself said:

The code I was talking about is about 50-100 lines in Delphi...

Correct. The base of the code from NumWords is just 70-somewhat lines and can easily be adjusted to follow the additional/proper rules.

const
  Digits: array [1 .. 9] of string = (
    'one', 'two', 'three', 'four', 'five', 'six', 'seven', 'eight', 'nine');

  Teens: array [1 .. 9] of string = (
    'eleven', 'twelve', 'thirteen', 'fourteen', 'fifteen', 'sixteen', 'seventeen', 'eighteen', 'nineteen');

  TenTimes: array [1 .. 9] of string = (
    'ten', 'twenty', 'thirty', 'forty', 'fifty', 'sixty', 'seventy', 'eighty', 'ninety');

function DoTriplet(TheNumber: Integer): string;
var
  Digit, Num: Integer;
begin
  Result := '';
  Num := TheNumber mod 100;
  if (Num > 10) and (Num < 20) then
  begin
    Result := Teens[Num - 10];
    Num := TheNumber div 100;
  end
  else
  begin
    Num := TheNumber;
    Digit := Num mod 10;
    Num := Num div 10;
    if Digit > 0 then Result := Digits[Digit];
    Digit := Num mod 10;
    Num := Num div 10;
    if Digit > 0 then Result := TenTimes[Digit] + ' ' + Result;
    Result := Trim(Result);
  end;
  Digit := Num mod 10;
  if (Result <> '') and (Digit > 0) then Result := 'and ' + Result;
  if Digit > 0 then Result := Digits[Digit] + ' hundred ' + Result;
  Result := Trim(Result);
end;

function NumberInWords(TheNumber: Integer): string;
var
  Num, Triplet, Pass: Integer;
begin
  if TheNumber < 0 then Result := 'Minus ' + NumberInWords(-TheNumber)
  else
  begin
    Result := '';
    Num := TheNumber;
    if Num > 999999999 then
        raise Exception.Create('Can''t express more than 999,999,999 in words');
    for Pass := 1 to 3 do
    begin
      Triplet := Num mod 1000;
      Num := Num div 1000;
      if Triplet > 0 then
      begin
        if (Pass > 1) and (Result <> '') then Result := ', ' + Result;
        case Pass of
          2: Result := ' thousand' + Result;
          3: Result := ' million' + Result;
        end;
        Result := Trim(DoTriplet(Triplet) + Result);
      end;
    end;
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  Showmessage(NumberInWords(2120229));
end;

9 minutes ago, Attila Kovacs said:

Rule 2a. Hyphenate all compound numbers from twenty-one through ninety-nine.

Rule 8b. When writing out numbers above 999, do not use commas.

You mentioned a "great solution on a website". https://www.calculator.org/calculate-online/mathematics/text-number.html

It translates 2019 to "two thousand, nineteen"

How does that one follow those rules?

But maybe there are better ones.

But I haven't even seen any ones online that convert according to those rules.

(or maybe this one https://www.tools4noobs.com/online_tools/number_spell_words/)