aehimself

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.

Ehm... In a good version, nothing will happen. In a bad version an AV upon closing the application. Either create it with (nil), or don't free it.

Yep, socket is not on the form therefore not created automatically. Delete the public declaration and drop one on your form. Edit: on newer Delphi editions TServerSocket and TClientSocket are not available on the palette by default. Do make them appear, go to Component -> Install Package, click on "Add..." and browse for $(BDS)\bin\dclsocketsXXX.bpl. Depending on your Delphi version, the XXX changes. On 10.4.1, my full path is C:\Program Files (x86)\Embarcadero\Studio\21.0\bin\dclsockets270.bpl After this, you can drop one on your form in Design time. Edit-Edit: If you are wondering, I think this is what happened. As I mentioned, designtime components are not available by default on newer Delphi editions. You started the source in Delphi, it warned you about a component which can not be found and you clicked on Remove. Now, the program would not compile as all ServerSocket1 references are invalid. Then, you manually declared it. The issue is, if it's not on the DFM it's not being created automatically for you.

Is the TServerSocket component placed on the form design time? Because it is in the declaration 3 times, 2 times commented out, finally placed in the "public" section: TfrmMain = class(TForm) ADOConnection1: TADOConnection; ADOQuery1: TADOQuery; //ServerSocket1: TServerSocket; // one occurrence private { Private declarations } //ServerSocket1: TServerSocket; // one occurrence public { Public declarations } ServerSocket1: TServerSocket; // final occurrence DCP_sha11: TDCP_sha1; DCP_3des1: TDCP_3des; end; I suspect it's not created automatically. Delete the component from the form, doublecheck that the public declaration is removed (if no, remove it manually) and put an other component on the form.

That line is a declaration, which is not executing under any circumstances. An AV can not occur there. The exception is thrown in SetPort: procedure TAbstractSocket.SetPort(Value: Integer); begin if FPort <> Value then begin if not (csLoading in ComponentState) and FActive then raise ESocketError.CreateRes(@sCantChangeWhileActive); FPort := Value; end; end; I start to wonder... is 0x40 low enough to be a nullpointer exception? Can you post your FormCreate code?

What methods is the DLL exporting - more importantly what type of parameters are being exchanged between the DLL and the EXE? If you are using PChars, doublecheck the allocation: instead of GetMem(pc, Length(inString)) you have to use GetMem(pc, Length(inString) * SizeOf(Char)) because of the Unicode difference @Angus Robertson mentioned. I can confirm that TClientSocket / TServerSocket works fine even in Delphi 10.3, with String or raw (binary) transfer as well - one of my applications were using those before I switched to ICS.

I faced this today and the fix is fairly simple. I recompiled VCL.Buttons.pas and now all font styling is working as expected. DIY: 1, Open up vcl.buttons.pas, after line 1715 insert: LCanvas.Font := Canvas.Font; 2, Go to C:\Program Files (x86)\...\lib\win32\debug, release, win64\debug, release and delete vcl.buttons.dcu 3, Fire up Delphi, create a new VCL application and drop a button on the form. Add Win64 platform, then build the empty application in Win32/Win64 Release/Debug. 4, Go to %USERPROFILE%\Documents\Embarcadero\Studio\Projects and copy the vcl.buttons.dcu from Win32/Win64 Release/Debug to your Delphi installations "lib" folder. Keep in mind that this is a modification of the local installation's VCL so it is machine dependent. You have to do this on every developer machine / build server you have. I have the modified source and the built DCUs but I don't know if I'm allowed to attach those here; so to keep it safe and simple, just follow these steps. Let's hope that this will get patched in the lifetime of 10.4.1. I doubt I can convince my boss to upgrade everything one more time.

@Daniel Did you try the built-in Windows 10 "Print to PDF" printer? Just a guess from the wild, have no idea if it supports FGL and Google was not so much of a help.

@emailx45

Which operating system are we talking about? 2 seconds sounds like the default DNS client timeout. Sometime around Windows 8 (needs clarification, I'm not sure), the following lines appeared in the Windows hosts file: # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost You can try to uncomment these and give an other try. It's possible that your DNS settings needs to be checked / updated.

But Frost is right about global variables. I would change this to... use them ONLY if you can not solve your issue without them. Edit: wtf spelling...?!

Strongly disagree. 10.4.1 is a lot more useable on our large project at work than any previous version was. Sure, it's far away from perfect, but it does not mean it's a "black hole". Tbh I was already shocked that inline variables will be added to the language. Was it community requested? Majority of the coders are staying away from it as far as I heard.

Off: That is some nicely commented code!

Doesn't this equal to a localized ANSI codepage...? In this case a solution would be to 1, Convert the underlying DB to UTF-8-16 and forget about encodings for a while 2, Change the access components to one which allows you to tell the RDBMS in what codepage string literals should be converted to before sending it to you - if Interbase supports this. Zeos has this and so does FireDac (as far as I see from Google). 3, Override the String field's OnGetText event and manually covert the byte array to a Unicode string on-the-fly 4, Feels a bit hacky but you also can go through all tables, read all string fields as a byte array, convert them to Unicode and put them back like that

Seems to be offtopic.

Good for a school project; I don't see any other purpose for applications which - mostly - do things what a built-in Windows command does. If a user doesn't know how to invoke them from the command line they most probably don't need / shouldn't use. Even I already used this in one of my applications I completely forgot about this. Yes, for finding your own software on a network segment UDP broadcasting is the way to go. I might be completely wrong on this one, but afaik broadcasts can not be relayed to an other subnet, though. Never tried it and didn't work with broadcasts since, so take this with a grain of salt.

For "general discovery" you will need a ping / port scanner. I wrote a fairly simple one a couple of years ago with DNS lookups: However, if you are looking for a specific program, you only need to display hosts where you find your application listening.

So the company just allowed 20H2 on our developer machines. Unfortunately the toolbar icon still does not work but the key combination does. I could try a reinstall of Delphi but I really don't feel the motivation to do so.

I fell in love with A4Tech products since I bought my first, which was a A4Tech 4D+ dual scroll PS/2 mouse way back in high school. With only a small amount of exceptions, ergonomically they suited me the best. Although I didn't have a desktop PC for 15+ years now, when my mouse died I felt lucky that the XL-750BK was still available. At work I also changed my keyboard with the G800V I had laying around at home. They are also marked as "gaming" products but no fancy RGB, only keys which can be macroed and higher resolution / data transfer rates. If I'll have to change again, I'll look into A4Tech first for sure.

Can anyone confirm that this only happens on Windows 2004? Yesterday after installing the MS Windows patches offered by the company my "View unit" button stopped working, while it was fine before. Same Delphi version (10.4.1) on a different machine, receiving updates from MS directly (therefore, instead of 2004 it's 20H2) it's all fine.

I'm using VS Code and git bash for the tasks VS Code can not handle. Diff view is one of the best I've seen, merge conflicts are easy to solve. Just install a time line addon and you are ready to go.