aehimself

I already started to experiment with the TReader component, unfortunately OnCreateComponent will only let me to use a different constructor other than the default. If the component is not created in the handler it will be created anyway. This thing is still a mess to me though... how do I specify WHERE the new components will be created...? As it needs a stream I need to get it from the executable - I guess it will be stored as a resource...? I'm only at the beginning. I'll find the answers soon enough. This is actually a really neat idea. As the TReader method will create the components anyway I suppose the memory usage will be close to equal anyway. As a huge bonus, I know how to create a new form instance 🙂 An other good idea. Tags are - unfortunately though - already in use in said project 😞 I'll dig into the TReader a little bit so I'll have a basic understanding of how it works / what it does. It never hurts to know something, you never know when you'll need such a thing. Thank you all for your answers!

I like to compile my components and let Delphi use the existing DCUs in my projects. Having my sources on SSD this not just saves time but prolongs the life of the data store as well. I recently started to experiment with a component suite which was written as a blob, runtime and design time in one, therefore I can not build 64 bit DCUs. I never really thought of creating my own component packages and therefore I have 0 experience with this. Are there any tips, tricks or resources that can help me achieving my goal? At the moment I can't even tell how to distinguish what is considered runtime and what is designtime 🙂

Let's say I have aeSuperDuperUtilities.pas and I compile it to all platforms, all configs. Then I set my library / debug DCU path to the relevant output folders, browsing path to the source. If I make a change in said unit, I recompile it again with all platforms / configs. At the moment I cannot imagine a way how any of the compiled DCUs would get out of sync. Then again, most probably I never worked on as many, as complex projects as you did. Can you please give me a theoretical scenario / direct me to an article so I can learn more about this?

* sigh * Yes. That was EXACTLY the meaning of it.

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.