PeterBelow

The code will not work as intended. Streams store bytes, not characters, and the size of a character is 2 bytes in Unicode-enabled Delphi versions. To calculate the number of bytes to write you have to use strmSize := Length(s) * Sizeof(char); TStream.Read and TStream.Write are also somewhat deceptive and excellent traps for beginners . They use untyped parameters and those do not work as you obviously expect from your code snippets. The compiler passes the address of the variable s to the method, not its content. So your strm.Write statement writes strmsize bytes starting from the address of s, but since strings in Delphi are reference types that address only holds a pointer pointing at the actual content of the string. You have to use strm.Write(s[1], strmSize); to write the content of the string. Reading it back has to follow the same pattern, and you have to position the stream to the start first and make sure the string you read into has enough memory allocated. Assuming the stream contains only the one string you have written into it this would look like this. I use a local string variable here to make things clearer, globals just confuse things: procedure TForm1.btnStrmToStringClick(Sender: TObject); // load/read into a tedit control var LTarget: string; begin strm.Position := 0; SetLength(LTarget, strm.Size div sizeof(char)) strm.Read(LTarget[1], Length(LTarget)* sizeof(char)); eb2.Text := LTarget; end; Things get more complex if you want to store more than one string into the same stream. In such a case it is advisable to store the length of a string (as integer) before the string content, so you can read the length first to figure out how to size the target string and how many bytes to read into it. Delphi has useful helper classes like TStringReader and TStringWriter to make such stuff easier. And if you only have to handle text you can put it into a TStringlist and use the list's SaveToStream and LoadFromStream methods to avoid all the hassle completely.

The problem in this case was that integer is 32 bit but the load address of a 64 bit DLL is 64 bits when loaded from a 64 bit project.

This is Windows' character composition on locales that have accented characters. You are probably not using the correct key for the single quote; on a german or french keyboard the key label looks very much like the acute accent character, "´" instead of the apostrophe/single quote "'". Which locale are you using, and what type of keyboard?

Be careful here. A DLL contains a different instance of the memory manager (unless you use ShareMem) and all the RTL and VCL code than the host application. Better make sure the DLL interface for the host app is written using API or COM compatible data types in the parameters exclusively, otherwise you may run into any number of weird problems.

If you have the query or connection active in the designer make sure to deactivate it before trying to run the app from the IDE.

Have you added handlers for the menu items OnClick event to call the dialog's Execute method? The menu items do not do that automatically. However, if you use a TActionlist with the standard file actions (added from the context menu of the action list editor) you can tie the actions to the appropriate menu items and they come with their own integrated file dialogs; you do not need to add the dialogs to the form manually.

Why do you expect this to work? Your program still does not have a messager loop!

There is a EStackoverflow exception type defined in System.Sysutils but it has been deprecated for several Delphi versions. A stack overflow cannot be trapped reliably via try except and recovering from it is practically impossible. What you can do, however, is to increase the stack size used by the program (in the linker part of the program options). Of course that is a band aid that does not protect from future failures due to an even more pathological set of input data. You can look into rewriting the algorithm to avoid recursion. Intead of relying on local variables to hold intermediate results (i.e. store them on the stack) you store this data into a record and manage a stack of these records yourself. This gives you much more control over the memory used, as well as removing the hard limit imposed by the default stack size.

Change that to Var clOrange: TColor;

For a GUI program this code is not designed correctly. A GUI program has to have a message loop and has to do any painting of the UI when Windows tells it to paint its window, by handling the WM_PAINT message in the window proc. You cannot leave that to DefWindowProc in this case, since it knows nothing about the bitmap you want to show. Anyway, this is not the way you write GUI programs in Delphi. Just create a VCL program skeleton via the File -> New menu, drop a TImage on the form the IDE creates for you, load the bitmap into its Picture property, set the Align property of the image to alclient, save the project, build and run it. Done. The whole purpose of using an environment offering a rich GUI class library like Delphi's VCL is to shield you from all the messy details of the Windows API.

Have you enabled Help Insight in the IDE options and are the source files in question on the IDE browsing path?

If you have an active ssubscription just create a support case (https://supportforms.embarcadero.com/ if memory serves).

Depending on your project this can get complex and even expensive if you used a lot of 3rd-party libraries. You can find a good overview here. If you google for "migrating delphi projects" the first hits (for me) list a number of youtube videos that may be useful. There is also a fairly recent book on the topic available: "Delphi Legacy Projects: Strategies and Survival Guide" from William H Meyer. Do not try to open the old project file directly, first delete all files with extensions other than dpr, pas, inc, rc, res from the project directory (after making a backup, of course) and then open the project's dpr file in the 10.3 IDE. That creates a new project (dproj) file. Open the project options dialog and adjust any pathes in the compiler page as required. Make sure to enable all hints and warnings and then try to build the project. The hints and warnings you get even if the build is successful (which is unlikely) will give you an inkling about the magnitude of the task you are facing. The main pain points are: Ansi to Unicode conversions. 3rd-party components used (i hope you have source code for all of them). Even if D 10 Versions exist for the old components (which you have to buy if commercial) there are likely to be a lot more compatibility issues with them compared to Delphi RTL or VCL code. Database access if you used the BDE (which is dead, buried and cremated for good measure). Assuming sizeof(pointer) = sizeof(integer) (especially if you want to go 64 bit) or sizeof(char) = sizeof(byte) when misusing strings as storage for binary data. Good luck

Are you sure the database BLOB stores the image in the format TBitmap can handle? The code would fail if it is a JPG or GIF or PNG...

D11.3 uses some additional linker option by default to enable the address space layout randomization (ASLR) feature. Try to disable that and see if it fixes the issue.

Try the form in the attached archive. To use it add the form unit to the uses clause of your form and add a call like procedure TForm2.Button1Click(Sender: TObject); begin TTransparentMsgForm.ShowMessage( 'This is a test message.', 30, self); end; Examples.zip

System.Classes.TBufferedFileStream

Start by reading the docs for the AllocConsole API function.

If the units generated by the SOAP importer declare the interface types without a GUID just try to add one (Ctrl-Shift-G if I remember correctly, with caret on a new line after the one with the interface keyword).

Do the two interfaces have the same GUID in the two units? If so you are probably sunk since the Delphi SOAP framework cannot distinguish between them. In this case you would have to build two separate modules (e.g. DLLs with the same exported interface, not packages!) then used by the service.

See the list of error codes here. 204 is an invalid pointer operation, which may be caused by corrupted memory (stack overwrite, writing beyond the bounds of a heap-based memory block, etc.). Open the project in the IDE, place a breakpoint on the first code line after the "begin" of the DPR file, run under the debugger until you hit this breakpoint. If the error pops up before you reach the breakpoint it is triggered by code executed from a unit initialization section. In this case build with debug dcus and place a breakpoint on the first line of the initialization section of system.sysutils. After you reach such a breakpoint you can use the "go to address" function of the debugger. This hides in the context menu of the disassembly view (View -> Debug windows -> CPU Windows). Make sure you have "debug information" selected in the active project configuration. When you type in the address do not forget to start with a "$" sign to flag the typed text as a hex value.

It is usually due to non-Windows linebreaks in the file (only #10 or only #13 instead of #13#10 pair).

Certainly. You can mix direct output to the printer canvas with rendering via EM_FORMATRANGE. By the way: do you know Code News Fast? It is an excellent source for Delphi code examples and it even has all the content of the long defunct Delphi newsgroups on hand. This old post may be a good starting point. By the way: the change in behaviour of your printing code from XE to Delphi 11 may be due to the fact that D11 uses a different version of the richedit common control (4.x) than XE did (2.x). There are suptle differences between these control versions.

If your text fits into one page it may simply indicate that all text has been printed....

First thing to do is to get rid of the with statement. That just confuses things. Be explicit, use Printer.Canvas.Handle instead of just Handle. And do you ever start a new page? I do not see a Printer.NewPage in your loop. If I look at the C example code here nextchar <= fmtRange.chrg.cpMin is possible and should be handled as an error.