TServerSocket - TClientSocket Issue - Code from Delphi 7 from 2010

[aehimself 396]

3 minutes ago, mtjmohr said:

I have commented this out in the the "public" section and uncommented it when it first was declared.

 

But I cannot drop the "TServerSocket" onto the form, I am getting an error:

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

Edited January 3, 2021 by aehimself

[mtjmohr 4]

Now that I have commented out the "ServerSocket1" from all positions, I successfully "dropped the TServerSocket icon" into the form. The compiling process does work now, I will check into whether it runs on the target system.

[mtjmohr 4]

Aha!

 

It looks much better now! This is the screenshot from the live system. The declaration within the *.ini file still has to contain the proper ODBC and database declaration, but I guess this will be feasible.

[mtjmohr 4]

Oh, wow,

 

after adapting the '.ini file:

[Guest]

Congratulations !

[aehimself 396]

P.s.: you also can remove the line 294:

  ServerSocket1.Open;

.Open has no effect after

  ServerSocket1.Active := True;
in line 232.

[mtjmohr 4]

This is exactly (!) the way it should look!

 

Thank you so much, my dear helpers, all of you, here in this forum!

 

I must confess that today within 2 hours I have learnt and understood more than during a long period of time coding in different languages as I had never really made use of one which had this Form Creator in it - I was always hooked onto the bare code.

 

I cannot even express how thankful I am!

 

And still, I have two last questions:

 

This piece of software is running as a 32-bit release.

1. If I want to compile also a 64-bit version, is there a general tip for me as to what to look for regarding "compile parameters" or can I simply change the compiler directive to 64-bit?
2. I want to bring this "application" into a Windows service. Is there a standard procedure for handling this? Have you got some instructions where I might learn that from?

 

[aehimself 396]

Just now, mtjmohr said:

If I want to compile also a 64-bit version, is there a general tip for me as to what to look for regarding "compile parameters" or can I simply change the compiler directive to 64-bit?

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.

 

2 minutes ago, mtjmohr said:

I want to bring this "application" into a Windows service. Is there a standard procedure for handling this? Have you got some instructions where I might learn that from?

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.

[mtjmohr 4]

Thank you, I will give it a try and report about what I have found.

 

Also, thank you for the tip with the "ServerSocket1.Open;".

[FPiette 383]

1 hour ago, aehimself said:

You don't really have a choice than to create a new one and start copying your code.

There is a better choice, at least if the VCL application has to be preserved as well which is handy for debugging.

 

The way to design that is to move all the code to a new class without any GUI interaction. This class could be a TDataModule to have GUI design.

That class will interact with the GUI or the service thru methods, properties and events.

Anyway, this is how a good application is always designed! It is a good advice to always separated the user interface from the actual code doing something.

 

[mtjmohr 4]

Before I come back again to the Windows Service aspect, may I ask another question?

On the screenshot you can see that I receive the same error message (when saving or compiling) for "DCP_3des1" and - not displayed - "DCP_sha11". These two whatsoevers belong to "DCPcrypt" and are to be found as *.pas files in their respective directories.

How shall I handle this?

Issue here for me is that I do not find them in the Palette ...

 

Could you please give me another hint?

Edited January 3, 2021 by mtjmohr

[aehimself 396]

1 hour ago, FPiette said:

The way to design that is to move all the code to a new class without any GUI interaction. This class could be a TDataModule to have GUI design.

That class will interact with the GUI or the service thru methods, properties and events.

Anyway, this is how a good application is always designed! It is a good advice to always separated the user interface from the actual code doing something.

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.

[aehimself 396]

4 minutes ago, mtjmohr said:

Before I come back again to the Windows Service aspect, may I ask another question?

On the screenshot you can see that I receive the same error message (when saving or compiling) for "DCP_3des1" and - not displayed - "DCP_sha11". These two whatsoevers belong to "DCPcrypt" and are to be found as *.pas files in their respective directories.

How shall I handle this?

Issue here for me is that I do not find them in the Palette ...

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.

[mtjmohr 4]

Meanwhile, after some housekeeping in the form of putting only the needed files into a "development area", I have successfully managed to compile and build both x86 and x64 versions of the "HL7 SocketCollector" with their appropriate *.dll files for the x86 and x64 architecture.

 

See the first 2 screenshots for this success which I owe to you all.

 

For x86 and x64, respectively, I have created an x86 and an x64 component directory each: "\_Components x86\..." and "\_Components x64\..." to keep things separate.

3 hours ago, aehimself said:

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.

"DCP_3des1" and "DCP_sha11" are needed in the code:

 

[...]

type
  TfrmMain = class(TForm)
    ADOConnection1: TADOConnection;
    ADOQuery1: TADOQuery;
    //ServerSocket1: TServerSocket;
    DCP_sha11: TDCP_sha1;
    DCP_3des1: TDCP_3des;
    Timer1: TTimer;

	[...]

 

Now 2 questions to this context:

1. As I have only the *.pas files which I can compile to *,dcu files, I might integrate them at runtime - but where and how?
2. In the DCPcrypt directory, there is one file called "DCPdelphi6.dproj", roughly 10 kB large, which when I open it by double-clicking apparently delivers the opportunity to compile it to a *.bpl library file which I then, possibly, could integrate - is this advisable and is something special to be taken into account for the file's "compilation" (cf. the last screenshot time-wise)?

In other words, I do not know how to proceed with this task.

 

Would you please be so kind as to advise me?

Edited January 3, 2021 by mtjmohr

[Guest]

20 minutes ago, mtjmohr said:

Right click on DCPdelphi6.bpl then Install.

if it did fail then paste the fail message and the source of the bpl here.

[mtjmohr 4]

Accidentally, I have read the "readme.txt" of the author and succeeded just a minute ago to successfully install it according to the info window.

 

I will try to handle the "icon dropping process" now.

[mtjmohr 4]

Dropping under x86 was possible, I compiled a new x86 version of the "HL7 Collector Socket" and uploaded it onto the live server expecting results.

 

However, it seems that I cannot do this installation for x64 or is there a way to have both together? See the screenshots, please.

 

Would it help if I renamed the "DCPdelphi6.dpk" to a different name? Or do I need to compile something, for example for both x86 and x64 architectures at the same time?

[Guest]

12 minutes ago, mtjmohr said:

I think that is wrong !

 

May be someone with better knowledge with DCPCrypt can help here, i never used it, amd you don't need to compile that package in 64bit, neither it does need an install, that for design time part only.

The question is does your source of DCPCrypt support 64bit, this https://github.com/Dunhamb4a/DcPCryptV2 looks like it does.

 

[aehimself 396]

3 minutes ago, Kas Ob. said:

I think that is wrong !

 

May be someone with better knowledge with DCPCrypt can help here, i never used it, amd you don't need to compile that package in 64bit, neither it does need an install, that for design time part only.

The question is does your source of DCPCrypt support 64bit, this https://github.com/Dunhamb4a/DcPCryptV2 looks like it does.

 

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.

[mtjmohr 4]

Trying to bring your 2 a bit separate points of advice together: What is the best strategy for me to continue? How would I compile the 32-bit and the 64-bit DCUs separately? Could you give me one example using a screenshot, please?

 

I used a different DCPcrypt version, the one which I had in my list of components, but I also have the one names by Kas Ob. to apply.

 

And I have an additional issue: I have a "Sender" program on the live system, still using the 2010 *.dll file which can send test ADT messages (see screenshot [2 messages: 1 test message + 1 real message meanwhile]). If I take my newly compiled version, this does not lead to anything in it, but it may be due to the old *.dll, I will test that right now with a new build of the "Sender" associated with the latest *.dll.

Edited January 3, 2021 by mtjmohr

[Guest]

4 minutes ago, mtjmohr said:

What is the best strategy for me to continue? How would I compile the 32-bit and the 64-bit DCUs separately? Could you give me one example using a screenshot, please?

This should not be a concern, as aehimself pointed DCPCrypt does support 64, then you can use the newer one make sure the path for both 32 and 64 points to the same library, also i would not be concerned about how you compile the dcu themselves, for you now let the compiler build them each time.

 

7 minutes ago, mtjmohr said:

And I have an additional issue: I have a "Sender" program on the live system, still using the 2010 *.dll file which can send test ADT messages (see screenshot [2 messages: 1 test message + 1 real message meanwhile]). If I take my newly compiled version, this does not lead to anything in it, but it may be due to the old *.dll, I will test that right now with a new build of the "Sender" associated with the latest *.dll.

I am not sure if i get the problem exactly, are you talking about 32 and 64 or unicode and ansi stuff, because each of these might has its own problems which might take long time to track then fix.

 

So as an advice drop 64 for now and make sure you can generate/build fully working binaries, only after that you can go after 64bit.

[mtjmohr 4]

I have successfully compiled the fore-mentioned "Sender" with the latest source code. It works perfectly fine sending test messages to the "old" but not to the "new" "HL7 Collector Socket" 😞 as you can see from the screenshot.

 

In other words: I cannot establish a connection between the sender and the new "HL7 Collector Socket" which means that this program does still have problem handling the port opening and closing or the acceptance of messages, either way is a problem.

Edited January 3, 2021 by mtjmohr

[mtjmohr 4]

6 minutes ago, Kas Ob. said:

20 minutes ago, mtjmohr said:

And I have an additional issue: I have a "Sender" program on the live system, still using the 2010 *.dll file which can send test ADT messages (see screenshot [2 messages: 1 test message + 1 real message meanwhile]). If I take my newly compiled version, this does not lead to anything in it, but it may be due to the old *.dll, I will test that right now with a new build of the "Sender" associated with the latest *.dll.

I am not sure if i get the problem exactly, are you talking about 32 and 64 or unicode and ansi stuff, because each of these might has its own problems which might take long time to track then fix.

 

Yes, totally right, only once the 32-bit stuff runs flawlessly I will get back to the 64-bit and Windows service stuff.

 

The last screenshot shows the 32-bit application apparently not getting any messages (the sender shows sent messages but they refer to the successful sending them to the old program and, therefore, have no meaning here.

 

Regarding Ansi and Unicode and strings and that matter: I have been using the source code from 2010 (then using D7 and D2007 but the main development was D7-based). I have received the attention to this string conversion and Ansi aspect due to changes from D7 to D2007 and then on but I have not essentially changed anything in the code so far.

 

I am aware, though, that this might constitute a problem on the one hand, but as the original *.exe and *.dll from 2010 still run under the shown compiled source code I wonder if this is really that essential. Or am I wrong here? Alternatively, I could compile the old code under RAD Studio 10.3.3 AND RAD Studio Delphi 2007 AND Delphi 7 (now where I have learnt what to mind out for due to your help) and then see which version actually runs. Sure and fair enough. But, and this is not a small but: My original intention was to set up my entire virtual appliance (WAMP and LAMP in this context as well as the HL7 software) in a 64-bit mode. A bit for sportive but mostly for rational reasons. For example, I have organized the data saving process for the PHP classes so efficiently that using a MySQL 64-bit Linux daemon, for example, really benefits and profits the saving process of up to hundreds of variables at a time. Well, and so I thought I might bring my tools in a 64-bit fashion as well. Hence the migration from D7 to RAD Studio 10.3.3 (possibly not observing and thus overlooking any string, AnsiString, and UnicodeString issues).

 

Okay. Clear. The primary goal is to get the 32-bit software running and then care for the rest.

 

Step 1: Recompile the original source code under Delphi 7 and RAD Studio Delphi 2007.

[Guest]

7 minutes ago, mtjmohr said:

Step 1: Recompile the original source code under Delphi 7 and RAD Studio Delphi 2007.

I still easily lost with you mentioning many versions, so lets simplify things

1) Make sure that you have working EXE ( can be the same form production)

2) Make sure you can compile on old version or new, the point is to have working EXE from the source, 

3) Move them part by part, one by one on 32bit to one IDE it might be 2010 but i suggest any newer, meanwhile make sure each part still playing nice and right with others.

4) if case of failure, then you have to track the failing points (due to Ansi/Unicode or whatsoever) step by step because you have a working EXE that you can debug, so no guess work, and no wasting time shooting in the dark, this step can be very hard or very easy, it depends on the code and your experience with debugging or logging, all in all you will benefit the most from step, yet will waste most the time here.

5) when you managed to get them all working on newer IDE that support 64bit, and you are 100% sure they are right and ready for production, only then make the switch to 64 bit, how ? by repeating the steps 1-4 

 

I hope this make sense, and good luck.

[aehimself 396]

1 hour ago, mtjmohr said:

In other words: I cannot establish a connection between the sender and the new "HL7 Collector Socket" which means that this program does still have problem handling the port opening and closing or the acceptance of messages, either way is a problem.

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?