Leaderboard

New blog post: http://www.danieleteti.it/post/radstudio-11-3-alexandria-my-top-3

I dont know... it's necessary wait Embarcadero ticket... I never use "Dataset" events like this... always in DB by default! all biz-rules!!!

Have you tried this setting? It's just a shot in the dark.

Thank you so much! I am so sorry that I did not recently look at this forum! It works now! Unbelievable. P4D is even greater now! Regards, Jan

You cannot hook up DB controls to an unidirectional query but that should not stop you from inspecting and saving it. I am using FireDAC with ODBC driver from the first version (to connect to Informix database). The data is never corrupted. The only problem I am aware is when writing to database FireDAC ignores the database locale and uses the default Windows locale for non-unicode language to write data.

That is not needed. The else is implicit in the try..except block, if an exception is not trapped in the "on" clause, it's re-raised. The point here is if you have code that needs to be executed, like a transaction rollback, or a log message that needs to be generated, etc.

FDQuery.FetchOptions - Does changing Unidirectional to True have any effect? FDQuery.FormatOptions have a TON of settings, including map rules - which may solve encoding issues if the ODBC doesn't provide all the info that FireDAC wants. I.e. you can explicity specify the type of value that the db field should be translated to. From the Delphi Tools menu: FireDAC Explorer can help with experimenting with Format/Fetch options. FireDAC Monitor can also give good insight into the low level goings on when your application is running. Edit: I also wrote this a few years back: .

They've already gone back to them. On the recommendation of MS itself

Thanks for the info, tried both h2reg and h2viewer, both give me the following error: MS Help 2.x runtime files are not installed on this PC. I wish Delphi kept using the good old CHM or .hlp help file formats...

Polling on a timer. Nice. As I said. The worst possible solution to this problem.

Is there a public documentation how one has to implement "AppTethering" to be compatible? Otherwise, it's another vendor-lockin, and you're stuck with Delphi/C++ Builder for implementing both sides.

I recently did it to extend a Delphi application. The extension was written in C++ and is a regular console application. The Delphi "master" app launches it, sends it commands via stdin and gets result via stdout. It was super easy to test in isolation with a clients machinery because the console app can also be launched and used by a regular ... console window. Would definitely do so again. Not sure if it's a feasible solution if you need to rapidly exchange gargantuan amounts of data. For that, memory mapped files or sockets are probably a better approach.

What you are looking for is "Inter Process Communication" aka IPC. For more details you can look here I used Cromis for named pipes. There is built in encryption support in that library, if you may need such functionality.

It should works. Perhaps a temporary fail due to overloading the servers with new installs ? Could you try again ? If you still have the same error, check your license in license manager to see if it has the 11.3 support and perhaps the subscription.

Design-time code (property editors, component editors, IDE wizards, etc) are simply not allowed in runtime executables, period. So, your home-grown component needs to be implemented in a runtime-only package, and any code that relies on the DesignIDE package needs to be implemented in a designtime-only package that "requires" the runtime-only package. Your component should have no concept of design-time whatsoever (outside of things like the csDesigning flag in its ComponentState property, the CM_DESIGNHITTEST message, etc). If that is not the case, then the component is not architectured properly.

One might (foolishly) think that in the help article which explains using -LUDesignIde some mention could have been made of the consequence. Thanks.

There is no such thing as a "normal graphic character" in Unicode. What you are thinking of as a "character" is officially referred to as a "grapheme", which consists of 1 or more Unicode codepoints linked together to make up 1 human-readable glyph. Individual Unicode codepoints are encoded as 1 or 2 codeunits in UTF-16, which is what each 2-byte Char represent. When a codepoint is encoded into 2 UTF-16 codeunits, that is also known as a "surrogate pair". That emoji is 1 Unicode codepoint: U+1F64F (Folded Hands) Which is encoded as 2 codeunits in UTF-16: D83D DE4F That will only allow you to determine the value of the 1st Unicode codepoint in the grapheme. But then you need to look at and decode subsequent codepoints to determine if they "combine" in sequence with that 1st codepoint. That emoji takes up 8 bytes, consisting of 4 UTF-16 codeunits: D83D DE4F DB3C DFFB Which decode as 2 Unicode codepoints: U+1F64F (Folded Hands) U+1F3FB (Emoji Modifier Type-1-2) And it gets even more complicated especially for Emoji, because 1) modern Emoji support skin tones and genders, which are handled using 1+ modifier codepoints, and 2) multiple unrelated Emoji can be grouped together with codepoint U+200D to create even new Emoji. For example: U+1F469 (Woman) U+1F3FD (Emoji Modifier Type-4) U+200D (Zero Width Joiner) U+1F4BB (Personal Computer) Which is treated as 1 single Emoji of a light-skined woman sitting behind a PC. Or, how about: U+1F468 (Man) U+200D (ZWJ) U+1F469 (Woman) U+200D (ZWJ) U+1F467 (Girl) U+200D (ZWJ) U+1F466 (Boy) Which is treated as 1 single Emoji of a Family with a dad, mom, and 2 children. See https://eng.getwisdom.io/emoji-modifiers-and-sequence-combinations/ for more details. Delphi itself only concerns itself with the encoding/decoding of UTF-16 itself (especially when converting that data to other encodings, like ANSI, UTF-8, etc). Delphi does not care what the UTF-16 data represents. Graphemes are handled only by application code that needs to be do text processing, glyph rendering, etc. Things that are outside of Delphi's scope as a general programming language. Most of the time, you should just let the OS deal with them. Unless you are writing your own engines that need to be Grapheme-aware. By using a Unicode library that understands the rules of Graphemes, Emojis, etc. Delphi has no such library built-in, but there are several 3rd party Unicode libraries that do understand those things.

it's 4 bytes only and the modifier (to make it lighter) is also 4 bytes like 🧑🏿‍🦽 is D8 3E DD D1 = 🧑 D8 3C DF FF = skin tone modifier 20 0D = zero width joiner D8 3E DD BD =🦽 and how to find out that it's one emoji? I'm afraid you have to parse the codes and go after the rules defined in the RFC.