aehimself

I did not really make components up until this point - maybe that's why I never faced an issue you are talking about. But if I'm not contributing to a component the practice of "download / update -> rebuild DCUs -> ??? -> profit" always worked for me. It seems being the end user has it's benefits sometimes 🙂

This is exactly what I meant, yes, thank you 🙂

@Anders Melander I don't yet have a real-world project which is using this. I only wanted to be able to generate the 64bit DCUs so when a project will use this component, it won't compile the component from source again. I guess I'll have to move all RegisterComponent calls to the design time package, am I on the right track? I guess it belongs there.

So back to the original topic I went ahead and created the two packages based on the article @dummzeuch shared. I coped everything from the original package to this, changed the platform to Win64 and moved the parts what caused the compilation to fail to the design time package (Only design time editors and registration procedures). It worked 🙂 I was finally able to build 64 bit DCUs but then I realized that my design time package contains only ~4-5 of the 20 components. A quick search showed that there are still at least 40 files with RegisterComponents call in my new runtime package, but it still compiles... is this normal? 🙂

* Sigh *

Hello, A while ago I started to patch up the dumb TDBGrid component shipped with Delphi. Added some things, fixed some things and now I face an issue where the bottom-right square where the two scrollbars meet flickers white for a moment in some occasions (using a dark theme). I think I know where the bug is but to be honest at this point I'm thinking on abandoning my creation and using something else what someone made, who knows more about this stuff I do. I am willing to spend the same amount of money on a program I earn from it but I use DBGrid in a free tool... so my budget is kinda... tight 🙂 Worst case scenario I'll patch on my ocean of patches until a new one arises. I'm just curious if anyone is using a decent component (or suite) which I can experiment with? I already tried KControls and JVCL. Thanks!

If it would be implemented... I definitely would 😜

Today I switched my search engine and found SMComponents. I have to do some extensive testing to see what I have to add or fine tune but holy sh*t this DB grid looks promising! I'll play around with it for a while and then try to build 64 bit packages out of it.

@Dany Marmur as far as I can see @EgonHugeist already started the development of the Zeos-based memory table. The latest snapshot already has the TZMemTable component - now it's time to start to play with it! Edit: Seems to be working as it should: procedure TForm1.FormCreate(Sender: TObject); begin ZMemTable1.FieldDefs.Add('MyField', ftWideString); ZMemTable1.Open; Try ShowMessage(ZMemTable1.RecordCount.ToString); ZMemTable1.Append; ZMemTable1.FieldByName('MyField').AsString := 'Hello world!'; ZMemTable1.Post; ShowMessage(ZMemTable1.RecordCount.ToString + sLineBreak + ZMemTable1.FieldByName('MyField').AsString); Finally ZMemTable1.Close; End; end; At the moment it throws a nullpointer AV if it's destroyed while it's open but I'll send a pull request with a fix in a minute.

There are 2 things you have to keep in mind: 1, IV, as @Kas Ob. pointed out. You must find out what IV your PHP encryption is using (if any). Afaik, DCPCrypt will use the part of the key as an IV, if not given any but I might be wrong here. 2, Character encoding. Delphi 7 is ANSI, and a web interface is usually UTF-8. So you take an UTF-8 string, encrypt and Base64 it. If you unbase64 and decrypt it you still have to do an encoding conversion, otherwise the result will be not a valid string for Delphi. What I advise at first: check the raw text and the encrypted binary (before Base64-ing it) with a hex viewer. Then, check the received binary (after unbase64ing it) and the uncompressed "text" with a hex viewer; that can already give you a hint. I personally abandoned the EncryptString / DecriptString a long time ago. I'm converting strings to TBytes (Array Of Byte) and performing the encryption on the binary data. Edit: I was wrong about using the key as IV. It just generates one for itself: procedure TDCP_blockcipher64.Init(const Key; Size: longword; InitVector: pointer); begin inherited Init(Key,Size,InitVector); InitKey(Key,Size); if InitVector= nil then begin FillChar(IV,8,{$IFDEF DCP1COMPAT}$FF{$ELSE}0{$ENDIF}); EncryptECB(IV,IV); Reset; end else begin Move(InitVector^,IV,8); Reset; end; end;

Hello, I know that madshi has it's own support forum, I'm mainly looking for personal experiences. We have a large Delphi application with MadExcept purchased and integrated already. When I put the line "StartLeakChecking;" in this project, random nullpointer access violations start to happen... for example at TSpeedButtom.Glyph.Assign, because TSpeedButton.Glyph is nil. Errors do not appear without StartLeakChecking, with ReportMemoryLeaksOnShutdown := True or when debugging via DeLeaker. I am also aware that the main purpose of MadCollection is not to detect memory leaks, it's just something added as an extra. So my question is... should I stop trying and just accept that this function is flawed? Do you guys have personal experience with MadCollection's memory leak detection in large projects? Has anyone seen these random AVs too? Thanks!

I am using 10.4 and I used the built-in; and also made my own DB grid inherited from the built-in one. All works like a charm. Does your Delphi say it doesn't know what TDBGrid is or cannot find the Vcl.DBGrids unit? Anyway, doublecheck the library locations / just start with a fresh registry (bds -r temp) to see if the issue is with the installation or your settings.

Tbh, in majority of the cases removing the HKCU Embarcadero registry tree and the general Delphi folders (C:\ProgramData\Embarcadero, %USERPROFILE%\Documents\Embarcadero) is sufficient for a clean start. You just have to be careful if you have multiple Delphi installations. I myself is going to have to do this at work soon as most of my toolbar buttons stopped functioning after a Windows update...

I guess every country has it's own major job portal, the only "general" thing I can think of is LinkedIn. I am aware it is being facebooked by people posting irrelevant things but it's still mainly a business and job platform. Although we probably don't have as many users as the site above, but you also can try here: Job Opportunities / Coder for Hire - Delphi-PRAXiS [en]

Congratulations! Now you can re-think, restructure and modernize your code if you wish (what I strongly advise if you'd like to run it as a service, btw). Since you are already using DCPCrypt, you can use TDCP_MD5 for this purpose. Question is what you want to achieve? Self-diagnosis? I don't know about ASPack, but UPX is NOT an obfuscator. It's a compressor. An executable you compress with it can be uncompressed to it's original form in a fraction of a second (to be precise - that is exactly what a packed .EXE does) That is something what you have to know. Proper licensing is really complex and a never ending cat-and-mouse game. On the other hand, you'll earn your daily bread.

So the layout is somewhat like this: Since I got lost somewhere, I'll start from the beginning. Do you have a FUNCTIONAL issue with the application now (meaning, not the warnings in the source but something not working / not working properly)? If yes, where? A bit off-topic: is there any particular reason why the packet verification resides in a DLL? If no other application is using it I feel like it only adds unnecessary complexity and points of failure (see one of my first replies about allocations).

Let's take one step at a time. String conversions (AnsiString vs. String) will only matter in data transfer / storage but as far as I understand, you can not even connect with your application. Is that right? I'm a bit confused. You said that TCP port 3000 is listening by your Python script...? Shouldn't your application be listening there (that's what TServerSocket does; it listens and accepts client connections)? Can you share some basic layout of your application? What is running where, what should connect where, etc.

Start your program. Click on Start, type cmd, press enter. In the appearing window, type netstat -ano | find /i ":3000" press enter. Anything shows up? We are still talking about the standard VCL application, right?

I personally use DCPCrypt and it indeed works on 64 bit applications. I compile the 64 bit DCUs, the 32 bit DCUs and install with a 32-bit debug flavor. For IDE instalation though, you MUST select 32 bit, as the IDE is 32 bit only and therefore you cannot install a 64 bit component.

You have to install the DCP components to Delphi so they show up on the palette and can be used on forms. If you have the .pas files, you can use them, but only runtime.

This is exactly how I am designing my service applications lately. I was talking about the current situation, where OP already has code on the form itself, not very comfortable with Delphi as a language and does not want to refactor - only to get it to work. Without a huge refactor you can not push the existing code to it's own class - you have to have your own message pump and a worker thread to run that message pump as a minimum (ClientSocket and ServerSocket both needs messages to operate). Yes, it is the elegant solution - write your code once, run it everywhere. This is the quick and dirty solution, which can be done without much proficiency.

Normally, changing the target platform is enough, but be careful to compile your DLL as 64 bit too! A 64 bit application cannot use a 32 bit DLL. That is unfortunately a different type of application. Now you created a "Windows VCL Application" and what you need it a "Windows service": You don't really have a choice than to create a new one and start copying your code. You also can try to "import" this form in the service application, and create an instance of it... it MIGHT work. But be aware, debugging a service application is usually a lot harder. You might want to implement proper logging for that.

P.s.: you also can remove the line 294: ServerSocket1.Open; .Open has no effect after ServerSocket1.Active := True; in line 232.

Remove ServerSocket1 from ALL sections before dropping one on your form.

Make sure your form is visible in the IDE (you are not viewing the source). Press Ctrl-Alt-P, start typing "ServerSocket" and then press Enter.