PeterBelow

Your code snippet is too incomplete to say for sure but are you ever freeing the SrcWorkbook and ExcelWorkSheet instances you get there? I don't remember whether these are interface types or class wrappers, you have to check the source of the Excel2010 to see what they are. If the two variables are defined in a local scope and are interface types they would be released automatically but not if they are objects...

Have you tried to explicitly commit or rollback the first transaction before you free the object?

Setting the stream.size to 0 usually is the equivalent of Clear but that depends on the implementation of the actual TStream descendent you are using. Btw.: TeamB was a group of users offering support to other users on the old Borland newsgroups. As recognition they received goodies like free product licences, a bit like the current Embarcadero MVP program, and we had dedicated support partners at Borland. All that slowly died off after Codegear took over, unfortunately.

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).