Leaderboard

Or just buy it and support the author.

...and still no multithreading 😄 Moreover, rewriting GUI wrapper, as in subject, in Python is twice senseless.

Like Remy said this would be much easier to handle if you transmit the whole input string after the user has entered it. There are ways to figure out which character would be created from a virtual key code and the current state of the modifier keys (Shift, Alt, Ctrl), see the MapVirtualKeyEx Windows API function, but this pointless if you have to deal with accented characters or other composites that are created by a sequence of keystrokes, or Alt+numpad input. Let Windows do this work for you and use the OnKeyPress event; it gives you the character directly.

Are you using VCL or FMX for the sending app? I do not recommend sending individual characters. Send whole strings instead. And be sure to encode them in a platform-neutral encoding, such as UTF-8. For instance, what you consider to be a single "character" may in fact be composed of multiple Unicode codepoints grouped together to create a grapheme cluster, which can't be obtained in a single UI event or transmitted as a single byte/char. Rather than transmitting characters as they are being typed, I suggest having the user type into an Edit control first, and then when Enter is pressed, or a button is clicked, etc, then send the entire text in one go. That will be much easier to manage. In VCL at least, the OnKey(Down/Up) events deal in "virtual" key codes, whereas the OnKeyPress event deals in character codes. Only because Microsoft decided that the virtual key codes for ASCII characters would be the same numeric values as their ASCII character codes. That is not the case for non-ASCII characters. Correct. Virtual key code 222 (0xDE) is VK_OEM_7: "Used for miscellaneous characters; it can vary by keyboard. For the US standard keyboard, the 'single-quote/double-quote' key" You don't, because there is no ASCII code for that character. The best way to deal with non-ASCII characters is to deal with Unicode strings.

Yes, better to use Delphi, where you can be sure it contains serious security issues! I don't think we're in a position to snipe... what follows is a portion of the log Core Security Technologies kept of their attempt to report the VCL Buffer Overflow vulnerability to Embarcadero. You might want to have some tissues handy.... Report Timeline 2014-05-29: Core Security Technologies attempts to contact Embarcadero. 2014-06-03: Core Security Technologies asks for a reply. 2014-06-09: Core Security Technologies attempts to contact vendor again. 2014-06-12: Core Security Technologies contacts the US-CERT for assistance in order to coordinate the "coordinated disclosure" of the advisory. 2014-06-16: US-CERT answers assigning the following tracking code to the report: VU#646748. 2014-06-30: First release date missed. 2014-07-10: US-CERT informs that they were able to contact the vendor and that a public bug tracking link was published by Embarcadero. 2014-07-10: Core Security Technologies contacts the US-CERT asking for vendor's contact information and informs them that the Embarcadero's bug tracking entry forces us to publish the advisory because the vulnerability details are now public. 2014-07-28: Core Security Technologies receives a reply from Embarcadero stating they expect to have a tentative date for a fix the week of July 28,2014. 2014-07-29: Core Security Technologies replies to Embarcadero that considering there is a public bug tracking report link, we would like to publish the advisory as soon as possible in order to help to protect the users. 2014-08-04: Embarcadero informs Core Security Technologies that they have a fix ready which is currently under internal review. They hope to give Core Security Technologies an expected release date by the end of the week. 2014-08-08: Expected release date (or reply) not received from Embarcadero, Core Security Technologies writes again asking for an update. 2014-08-11: Core Security Technologies notices the status of the public bug tracking report was changed to "fixed". Core Security Technologies emails the Embarcadero asking for clarification about the new status. Two questions are submitted to the Embarcadero (1) Core Security Technologies asks Embarcadero to confirm whether the new status means the fix was made public and (2) in case the fix is still not public, Core Security Technologies requests the tentative release date. 2014-08-11: Embarcadero informs Core Security Technologies that they are testing the fix internally and that they are planning to release it publicly on August 15, 2014. 2014-08-11: Core Security Technologies requests Embarcadero link to the fix so it can be include in the coordinated advisory report. 2014-08-11: Embarcadero replies to Core Security Technologies stating that the link will be delivered August 15, 2014. 2014-08-12: Core Security Technologies requests the estimated time when the fix will be public on August 15, 2014. 2014-08-12: Embarcadero replies that they estimate the fix will be released on August 15, 2014, at 3 p.m. PDT. 2014-08-14: Core Security Technologies requests Embarcadero to postpone the fix release day to August 18, 2014 in order to give users time to patch their software and avoid giving a two-day head start to potential malicious parties. Core Security Technologies informs Embarcadero that it will release the advisory on August 19, 2014 if they accept the postponement. Additionally, Core Security Technologies offers help in contacting third parties affected by this vulnerability. 2014-08-14: Embarcadero agrees with suggested release approach and will postpone the publishing of the fix until August 18, 2014 at 10 a.m. PDT. They also state they are internally discussing how they will notify their customers. 2014-08-15: Core Security Technologies requests Embarcadero deliver the support article and fix so it can be verified. 2014-08-15: Embarcadero sends Core Security Technologies a copy of the support article. 2014-08-15: Upon review of the proposed fix, Core Security Technologies informs Embarcadero that the fix seems incorrect. 2014-08-15: Embarcadero indicates they will investigate based on that assessment of the fix, and says they will need to delay the publishing of the fix until the issue is resolved. 2014-08-15: Embarcadero confirms a problem with the proposed fix was included in the support article and indicates they have a fixed the problem. Embarcadero requests confirmation from Core Security Technologies regarding the new article that includes the updated fix. 2014-08-18: Embarcadero informs Core Security Technologies of updated content in the article, and proposes publishing the same day. 2014-08-18: Core Security Technologies didn't reply due to a national holiday affecting their Buenos Aires offices, but Embarcadero publishes the fix and an accompanying support article. 2014-08-19: Core Security Technologies requests the fix from Embarcadero to update the advisory and verify it. 2014-08-19: Embarcadero replies sending Core Security Technologies a link to the fix. Due to the fact that the fix was released on August 18, 2014 Core Security Technologies schedules the advisory publication for August 20, 2014, leaving the fix analysis task for post-advisory release. 2014-08-20: Advisory CORE-2014-0004 published.

I tested this many times as well (see the above QC ticket), ODBC was slower loading. And there's also the configuration of the ODBC driver on each client that you must do sometimes. The main problem I have with the Native Client is that it's keyed to the version of SQL Server. We have multiple versions on our servers, and there's no on Native Client that can handle them all. The nice thing about ADO + OLEDB is that this is not an issue. When using the newest OLEDB driver from Microsoft and ADO, all of these issues are resolved. It's fast, one driver works on everything. But of course, it doesn't have all of FireDAC's new stuff. I don't know why this is such a big deal for Emb. Just implement this driver. SQL Server is everywhere, why wouldn't you want to implement the best solution?