FPiette

You should contact support or sales at Embarcadero.

After reading you messages, I think that the software has been hacked by someone inside the company, or by someone hired by an employee. That employee wanted to get access to the password protected resource and hacked the software (or asked some one to hack it). Search who benefit from the hack and you'll find the culprit. It is very difficult to prevent software hacking. Hack can be detected by signing the executable with strong cryptography and having an external tool to check the signature. The signature can be checked by the executable itself, but then the hacker can bypass this code. If an external tool check the signature, then the hacker has to hack that tool as well. Having the tool running from another computer, thru a network share would help. The hacker need to hack that other computer.

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.

You opened the form using a Delphi instance that has the socketserver component not installed. Delphi told you that and proposed to remove it or to cancel. You accepted to remove it and moved the declaration. You should have cancelled, closed the form, installed the component and the reopen the form. Now to fix that, you have to remove the declaration from the source and then install the component in the IDE. Go to Component -> Install Package, click on "Add..." and browse for $(BDS)\bin\dclsocketsXXX.bpl. Depending on your Delphi version, the XXX changes. Once installed, you can now drop a ServerSocket on the form. Unfortunately, any value set in the object inspector are now default. You have lost the values. Having it on the form, it will be created automatically.

Is it enough to open and close the port 3000 to get the AV? Of need the data transfer also occur? This is an error code or the address of the access violation? Is the AV a read or a write? Did you run the code under the debugger? If not, do it! The debugger will show you the stack trace which is frequently very interesting to help debugging. If I take your code and rebuild the application (I have the latest Delphi: 10.4.1), do I need something to run it and reproduce the error? Will the error jusy bump to my face immediately?

It looks fairly simple to me: create a form with the UI you need for that area. Then when the user ask for that area, just show the form as a popup located where the selected row is.

The code line read a byte from memory. When the array index if out of range, memory outside of the array is read. As declared, the array "bytes" is stored by the compiler at the same address as the variable aSet which is an argument which is passed by address (untyped const). The net effect is that accessing the array is accessing the bytes of the variable passed as argument directly. In the code you show, the code intentionally read variable bytes. Given the name of the function (GetSetCardinality), that argument is probably a set (set of something). Reading outside of the array bounds will probably have no adverse effect. It depends on what the read values are used for. Accessing the byte right after the last item array will just return an apparently random value which is in memory at that place. Depending where the original variable passed as argument, that memory may be unreadable. Very unlikely unreadable: it would be the last variable in a virtual memory page and the next page not being allocated. We can assume that the alen argument give the size of the passed variable and the code (not shown) accessing the array make sure to not go beyond that length. So there will be no access violation.

And set "use debug .dcu" to true.

That is not my experience at all. I have a lot of projects with 10.4.1 including some large on (hundreds of thousands lines of code). I have no problem at all. Probably my coding style is in Embarcadero testing mainstream. I never rush to brand new features neither.

You may have hidden some exception (Empty except block in a try/except). You may have a thread still running. You may have an issue in a finalization section of any unit. And many others. Did you tried running under the debugger?

Let me reformulate: You create a popup window as a TForm and show it non modal (that is just call Show). Then the popup window get's the focus. Now you want to main (parent) window keep the focus? The focus in Windows terminology is the window receiving keyboard input from the user. As there is only one keyboard, there could be only one window getting the focus. BUT a TForm can get hand on every key press using KeyPreview property. Nothing prevent you from sending the keystroke to the parent window for handling. You can decide if the keystroke will be handed by the popup window or not by nullifing the key code. All this is particularly convoluted. Not sure it is interesting. I don't know since you didn't explained what you want to do: you talked about a solution, not a problem.

This will probably not work since you send FGL commands to the printer. This bypass the normal work of printer handling under Window. Another printer, including a virtual printer would work if you send standard commands (GDI) to the printer which is done by Delphi when you use printer's canvas to print something.

That doesn't answer my question! The question is: How do you connect to the printer? Replacing the physical device by a virtual one producing PDF depends on how the physical device is connected. You won't find any virtual device out of the box implementing the specific language of that printer. I won't explain all the possibilities. You have to explain how you connect the printer and by the way how you print a label (Show the code!). Then if I have s solution for the way you use the printer, I will explain it.

You need two projects for your solution: one for the DLL and one for the EXE. Did you read my previous answer? Is there something you don't understand in it? As @David Heffernan and @Kas Ob. said, you need to learn more to understand what a DLL is, how to write one and how to write an application using that DLL. Kas Ob. pointed you to some tutorials and I'm sure Marco Cantù book explain the concepts.

How do you connect to the printer? Reading the documentation, there are several ways to connect to the printer and send commands.

That is not very clear. Are you sure it is the compiler which generate the Access Violation? I guess it is your program that generate it when running. Please show the EXACT error message. If it is at run time, please run your program and/or DLL under the debugger to know exactly where the error occurs (the debugger will popup when the Access Violation happens). I have no idea how your code is built (I don't have the book you refer). But frequently, using a DLL involves call LoadLibrary to load the DLL and the GetProcAddress to get the pointer to the functions within the DLL. At each step you should check for error because an error could lead to a future access violation. A DLL may also be statically linked or automatically delay loaded.

Why not start from this example to convert your component to string and the store the string in the INI file?

Excel is a really huge product. Moving an app from Excell to a Delphi program maybe easy or very complex up to the point to a complete Excel rewrite. But if you just do some very basic calculation and display, then a StringGrid and Delphi code may work. This depends completely on the needs.

I gave the correct code, a single line, before any of your (complex and partially wrong) answers. I answered everything the OP asked. Sorry but the rest is noise in this context. Have a good night. Here is it already 8h AM.

Sorry but YOU made it complex. You are completely wrong about complete boolean evaluation. It makes NO DIFFERENCE at all on the result of a conditional expression. When complete evaluation is off, the compiler generate code which do not execute more parts of the expression when the result is already known. This result in faster code at runtime. It makes a difference in code execution when the boolean expression include function call which has side effect. Function may not be called and then side effect not done. Aplyed to conditional compilation, this has no effect since only constant are involved and the expression is resolved at compile time. I'm not even sure that the compiler look at the option when compiling an expression for conditional compilation.

We don't even know what it is supposed to do. First of all layout your code correctly so that the structure is apparent.

When making an image larger than his original resolution (enlargement) always gives a bad result. One way to mitigate this is to use bilinear interpolation but don't expect marvelous results. Making an image smaller than his original may be better but will also make it a little bit less nice. Suppressing pixel is the faster but worse solution. You need to merge several pixels into one and apply a weight on the existing pixel depending if it is far or near the new pixel position.

That is wrong. You used IFDEF instead of IF. The correct version is: {$IF not(defined(Hello)) and not(defined(Bellow)) and not(defined(Yellow))} ShowMessage('{$IFNDEF...'); {$ENDIF} {]IFDEF XXXX} if the same as {$IF Defined(XXX)} The first form DO NOT ACCEPT boolean expression. The second accept boolean expressions inside which you have the pseudo-function Defined() and you can use Delphi boolean operators.

{$IF NOT(Defined(XXX) or DEFINED(YYY))}

I have no idea. Could you write a simple, small, minimal program which reproduce the issue?