Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 05/17/23 in all areas

  1. I'm still checking from time to time about Delphi jobs and I have an important message. If you are in leadership at a company that is looking for Delphi developers and you are having difficulty finding them. You need to change your hiring process!!! If your people answer the phone and don't have any idea that your company is hiring or don't know who to connect the caller with to find out if your company is hiring, you will not ever find Delphi developers. If whoever answers the phone sends possible applicants to an HR extension that goes directly to voicemail and no one ever returns the call, you'll never find Delphi developers. If your company is in the US and you hire an outside company to find you Delphi developers, but they can't speak a word of english you are not going to find Delphi developers in the US. If you treat applicants like cattle, by expecting them to just go to your website and fill out your twenty page application without question, you won't find any Delphi developers. If your stupidass application system underlines the word english as if it's not a word, when they whole system is using english you won't find any Delphi developers. Just a few pointers to help companies with their hiring.
  2. Brandon Staggs

    Convert line endings on paste?

    I've submitted this as a feature request: https://quality.embarcadero.com/browse/RSP-41714
  3. Sherlock

    Hiring process...

    Definitely! For example I would not enjoy working for some weapons manufacturer. And I have no love for accounting either... I love medical devices, so that's my home. No other job would interest me, no matter what the pay or work environment.
  4. Dave Nottage

    D11, Play billing Library 5.2.0

    It's supposed to be backward compatible. You should use the OnError event of InAppPurchase1 to find out what the failure is.
  5. David Schwartz

    Can anyone spot the errors?

    Consider that the ordinal value of any specific character is given by the position of the character in the ASCII table, which is why I posted a link to it. Seems the OP didn't even notice it. Instead, we ended up with a senseless debate about ordinal values of characters versus strings. smh. According to the ASCII table, the ordinal (decimal) value of the character '0' (zero) is given as: Ord('0') = 48. You can see this if you display the result of: Format( 'Ord(''0'') = %d', [Ord('0')] ); since Ord() returns an integer value, and this displays it as a decimal number. The ordinal value of the character '9' is: Ord('9') = 57. However, while the next Hex digit is 'A' (or 'a'), the character following '9' is Chr(58) which = ':' (colon). In practice, Hex digits are not case sensitive, so the hex value of 'a' is the same as the hex value of 'A', both of which correspond to the decimal value of 10 (ten). However, Ord('A') = 65 while Ord('a') = 97. Ord('9') is 57 while Ord('A') = 65. So the ordinal values of the 16 ASCII characters that are used to represent Hex digits is not a continuous array of 16 values from: it goes from Ord('0') = 48 to Ord('F') = 70. The range between those two ends is 22, not 16. And if you use lower-case 'a'..'f' then the difference is Ord('a') - Ord('A'), or the entire range defined as [48 .. 102], again far more than 16 elements. The ordinal value of a string is undefined. So Ord( '0000' ) is an error, neither zero nor 48. Never mind that these are actually BINARY representations (0 or 1), and to the compiler they're just 4-character strings. You have to parse the digits in each position of a Hex number the same way as you do decimal numbers, except you need to multiply each successive position by a power of 16 rather than 10. Simple arrays that serve as lookup tables work for decimal numbers only because the digits zero through nine are contiguous in the ASCII table, and you can simply subtract Ord('0') from the ordinal value of the number you're dealing with to get its actual decimal value. The range of hex characters is NOT contiguous with the ten decimal numbers, and in fact is different based on whether the given hex digit is in upper- or lower-case. So you cannot use simple lookup tables to do this thinking that a range of 16 characters is going to work in all cases. It will work for the ten decimal characters, but NONE of the hex characters. And certainly not for strings expressed as 4-character BINARY (0 + 1) versions of hex digits!
  6. Patrick PREMARTIN

    Looking for outsourcing FMX development

    Hi Did you checked TFrameStand project from @Andrea Magni https://github.com/andrea-magni/TFrameStand
  7. Rest assured that people and companies in Europe are fully aware of that topic. And even more: Due to some American laws even servers that are hosted in the EU but are owned by American companies or even companies owned by American companies may be questionable. In theory that means that cloud services from Amazon, Microsoft, Google etc. are a no go for European companies. The reality unfortunately is very different, as even governments, universities and schools use these services, because lobbying has so far prevented that the laws are being applied.
×