dormky

You don't seem to get that I understand how it works. But it working doesn't mean it couldn't be better (way better). There's a reason Delphi is a dead language (just look at the average age of developers here), and that's because the design choices made at both the language and framework levels have been replaced by better alternatives. This is way I assume I know how it could have been better designed, become I know and use better alternatives. Those alternatives aren't perfect either, but they are better. This also doesn't mean Delphi wasn't a good framework compared to the competition 20 years ago. But that was 20 years ago, and Delphi has not improved (I mean we're still writing imperative UI code for Christ's sake), meaning the design choices that were bad but not worse than the competition are now just bad.

Then please explain ? I delphi, I write to a variable that is then monitored to close the form. In Window, I call a function. Those two things are completely different.

That's one of my main gripes with VCL, reading the code is awful because it has basically 0 comments. Had they just put "// Setting this to a value other than mrNone triggers the closing of the modal form" I would have understood things immediately, because yes the first thing I did was open the VCL code of Close() and ModalResult. Good code would have either set this comment, or just have a comment pointing back to ShowModal, ie "// See usage in ShowModal", which is actually what most modern frameworks tend to do nowadays. I rather like it as it will solve your questioning in 90% of cases, with the rest needing actual documentation (which you can also put in comments).

I did learn and I'm already coding another feature ^^ I just like arguing with strangers on the internet. You often learn a lot of things indeed.

If someone else is building a house out of paper, that doesn't mean it's a good idea. However it makes sense to build the furniture out of paper too, so in way Delphi copying this behavior makes sense. However, they didn't copy it : > The procedure then calls the EndDialog function to set the dialog box's return value to either IDOK or IDCANCEL, depending on the message received, and to begin the process of closing the dialog box. So here, the Delphi equivalent would calling Close and giving it the value we want to return. The flag is completely internal to Windows and cannot be set by the developer manually AFAIK. So basically, Delphi's implementation is to let the dev set the flag, and regularly check for when the flag is set to trigger the closing of the form. Window's implementation is to have the dev explicitly call EndDialog with the value to be returned. Delphi's implementation is worse and actually doesn't have much in common with the Window one from the POV of the dev.

"Property triggers" such as Connected := True are only for properties that point to a function ; this isn't the case for ModalResult, which just read/writes FModalResult.

Saying "if you don't like it don't use it" is not a valid response to fair criticism of, in this case, the inconsistencies of design choices. In general such a response is indicative of a lack of an actual argument in favor.

Heavy disagree. A message/event driven environment should, you know, actually use events instead of mixing in state monitoring.

>Unless you have a clear understanding of ALL the hidden things that Delphi does, you should NOT DO ANY OF THEM! >"Hoping you're right" is not a reliable way of writing code. Sorry for not begin able to remember all of the documentation, and sorry that I can't afford to read all the codepaths for every call to the framework I make. No one on planet Earth understands all the hidden things that Delphi does, because AFAIK everyone on earth is human with a limited ability to conduct logical reasoning. >That Close call might not even be getting executed because the assignment to ModalResult calls a method that has side-effects. That's just plain wrong, unless you are not using TForm. ModalResult is a read/write property to a private variable, there's no function call. >It's best to avoid any kind of state-altering logic inside of event handlers How do I program anything then lmao. Also my code was simplified, there are guard conditions in the actual code.

Jesus Christ, that is awful design. It's amazing, everytime I encounter a situation where I ask myself "how am I meant to [thing] with this framework", the answer is always "we implemented it, just in the most non-sensical way possible lol".

That's what I ended up with yes

I have a TImage and a TDrawGrid. Calling BringToFront() on TImage does not put it above the drawgrid, what am I supposed to use ? UFormMain.dfm UFormMain.pas

I want a specific loading icon, not a pre-made windows one.

I want to make a loading overlay. I can't exactly go through the whole program doing this :')

Consider : program ProjectThreadProc; {$APPTYPE CONSOLE} {$R *.res} uses System.Classes, Winapi.Windows; type TMyRecord = class data: Integer; class procedure Queue(const AThread: TThread; AMethod: TThreadMethod); end; class procedure TMyRecord.Queue(const AThread: TThread; AMethod: TThreadMethod); begin OutputDebugString(PChar('In TMyRecord.Queue')) end; begin TThread.Queue(nil, procedure begin OutputDebugString(PChar('Hello !')) end); TMyRecord.Queue(nil, procedure begin OutputDebugString(PChar('Hello !')) end); end. This will give you, under 10.3 : [dcc32 Error] ProjectThreadProc.dpr(25): E2010 Incompatible types: 'TThreadMethod' and 'Procedure' Notice that the line for TThread has no problems, and this compiles if you comment the call to TMyRecord.Queue. Problem is, on the face of it those two functions have the exact same signature : So why does TMyRecord.Queue not compile ? I'm baffled. The end goal here is to pass an anonymous function to a thread, to be executed there.

Here I was sitting and wondering how the hell it was compiling TThread when it should be TThreadProcedure for it too... Before noticing the overload beneath the function Delphi navigated to. God bless Delphi's function navigation, somehow worse at it than Christopher Colomb. Good job noticing this !

query := TMyQuery.Create(nil); query.Connection := conn; query.SQL.Text := 'SELECT * FROM data'; query.Execute(); Every time I do something like this, a new connection to the MySQL server is established. How can I make it use the already-opened 'conn' connection ? Thanks 🙂

const TT = $FFFF; TTARRAY = [$FFFF]; The second line gets "E1012 Constant expression violates subrange bounds", but it's functionally the same as the first one. Is the compiler just dumb or do I need to write this in another syntax ? The actual use case is an array of const TColor. Thanks 🙂

Alright, got it. Still cannot work with TColor but it's better then nothing, example : // The highlight colors here are defined twice so the compiler doesn't complain. YELLOW: TColor = $00BBFF; BLUE: TColor = $F0CF89; HIGHLIGHT_COLORS: array[0..1] of TColor = ($00BBFF, $F0CF89); Thanks !

I'm using MyDAC components and some of the data is encrypted via use of a TMyEncryptor with a password, see https://docs.devart.com/mydac/devart.dac.tcrencryptor.password.htm But they don't say what the algorithm used to generate the password is. Does anyone here know that ?

Okay, so according to my understanding CBC xors the plain data with the previous block (encrypted) before applying encryption. And here instead, the plain data is encrypted directly and then xor'd with the last block. In this case, if I were to truncate my data to 8-bytes blocks, then encrypt the bytes that were removed by themselves with an IV of all 0 I could then xor the result with the last block myself, thus landing on the same result as MyDAC ? Since the last few bytes would be xor'd with the zeroed IV they wouldn't be changed before encryption, just like MyDAC is doing here.

Ah. Well isn't that great. This is why I hate proprietary code ; now this project is effectively locked in with MyDAC and has no way of ever getting out of it short of a manual migration of data on demand. Good job from Devart, they win... Although I will still endeavor to do everything I can to move the company away from them. It's personal now 😛 Thank you for your help.

Well, I though I had gotten it to work by using CTR, but I only get the same output up to 8 characters. You say that they are using CBC, but I can't get that to work using either LockBox3 or C#'s BouncyCastle. I have had contact with the MyDAC support and they refuse to cooperate (they did not mention any specifics of how they are handling encryption and keep referring me to the incomplete documentation). Do you know if any implementation of Blowfish that do not require to be padded to 8 bytes ? Even BouncyCastle, which to my understanding is C#'s main open-sourced cryptography library does not provide such a thing : using System; using System.Text; using Org.BouncyCastle.Crypto; using Org.BouncyCastle.Crypto.Engines; using Org.BouncyCastle.Crypto.Parameters; using Org.BouncyCastle.Security; using System.Security.Cryptography; namespace blowfish_test { internal class Program { const string PASSWORD = "pass"; const string DATA = "ABCDEFGHI"; static void Main(string[] args) { byte[] sha1Hash = SHA1.Create().ComputeHash(Encoding.Unicode.GetBytes(PASSWORD)); byte[] md5Hash = MD5.Create().ComputeHash(Encoding.Unicode.GetBytes(PASSWORD)); byte[] key = new byte[20 + 12]; Array.Copy(sha1Hash, 0, key, 0, 20); Array.Copy(md5Hash, 0, key, 20, 12); var cipher = CipherUtilities.GetCipher("Blowfish/CBC/NoPadding"); //cipher.Init(true, new ParametersWithIV(new KeyParameter(key), new byte[8])); cipher.Init(true, new KeyParameter(key)); byte[] encryptedData = cipher.DoFinal(Encoding.UTF8.GetBytes(DATA)); // Display the result Console.WriteLine("Encrypted Data: " + BitConverter.ToString(encryptedData).Replace("-", "")); Console.ReadLine(); } } } This fails, but if you remove the 'I' to have 8 characters you do get the same output as MyDAC. Same output when using 8 characters, but completely different when there's 9. So I guess the encryption part is correct, but the transition between blocks is implemented differently, and while I can check on what BouncyCastle is doing I can't do the same for MyDAC 😕

I'm definitely using it wrong, but them having no docs and considering base64 to be an encryption algorithm doesn't help lol Edit : encrypting 'ABCDEFGH' lands on the same result with both MyDAC and LockBox3, with the caveat that LockBox3 has another 8 bytes of data. This is probably due to padding, but at least I'm sure the actually encryption is correct, yey ! Just need to figure out the padding. I had to set cfNoNounce in TCBC in order to get an empty IV because I haven't found a way of setting it myself otherwise.

Yeah I know doing encryption like this is BAD (we've had multiple cases of the program not releasing a string is encrypted and using it as-is...), I'm not the one who made this... I'm the one stuck dealing with it 🙂 Jesus Christ, the bug with SetKey !! No wonder the output changes all the time... For future reference, my updated testing code with the corrections needed for it to output the same thing with Password and SetKey : var conn: TMyConnection; table1, table2: TMyTable; keyBytes, PassBytes, sha1, md5: TBytes; query: TMyQuery; begin PassBytes := BytesOf(@WideString('pass')[1], Length('pass') * SizeOf(WideChar)); SetLength(keyBytes, 36); sha1 := THashSHA1.GetHashBytes(TBytesStream.Create(PassBytes)); // Memory leak lol md5 := THashMD5.GetHashBytes(TBytesStream.Create(PassBytes)); Move(sha1[0], keyBytes[0], 20); Move(md5[0], keyBytes[20], 16); // --- // table2.Encryption.Encryptor.SetKey(keyBytes, 0, 32); // 0 to get the correct function Many thanks Kas !! I've been trying to use LockBox3 to create the same result, unfortunately I can't quite get it. 'A' is the same value no matter the encoding but I get 41 as output instead of E2. I need to check deeper into the (undocumented) code of LockBox3 to see what I'm doing wrong (hopefully it isn't MyDAC doing something wrong...) Codec := TSimpleCodec.Create(); Codec.StreamCipher := TBase64Converter.Create(); Codec.BlockCipher := TBlowFish.Create(); Codec.ChainMode := TCBC.Create(); SetLength(LBKeyBytes, 34); Move(keyBytes[0], LBKeyBytes[1], 32); LBKeyBytes[0] := 32; // Length of the key LBKeyBytes[33] := 0; // Does the key contain the sotres Codec.InitFromStream(TBytesStream.Create(LBKeyBytes)); Codec.EncryptString('A', outputText, TEncoding.UTF8); // outputText in base64, translated to hex => 41 Edit : Dear god, 41 = 'A' to begin with... This is not encrypting anything !!