PeterBelow

Yes, you have to make sure the dcus for debug and release are deposited in different folders and modify the debug dcus path in your project accordingly. I have no experience in building projects using run-time packages, but I suspect that you will have to build release and debug packages with different names to avoid conflicts. In fact I would recommend debugging without building with packages, if feasable. Makes life much easier...

Well, I tried your example in D12 ( Win32 target) and the evaluator rejected the expression outright: Edit: Tried same project in D11.3, same result. I suggest you delete the dproj file carried over from D10 and open the dpr in D11.3 to recreate the dproj.

Actually I would not expect that. The breakpoint is placed before the call statement to the IndexText funtion (check the assembly view) so the value of idx is unknown at that point; you have to step over the call to the function to make the result available. If it worked in D10 I would consider it a bug there unless you have tooltip expression evaluation active, in which case the debugger may execute the call to get the result for the tooltip.

TField.IsNull is the way to check if a database field is NULL. Do not rely on this conditions beeing mapped to a specific value.

Since several Windows versions an application running in background (= not having the input focus) cannot simply push itself into the foreground anymore because it thinks itself soo much more important than what the user may currently be working with. Instead it flashes its taskbar button to inform the user that it requires its attention. Does that not happen in your scenario?

The code shown is too incomplete to make sense, but in general a generic class is just a blueprint, it has no actual class representation and thus no RTTI in itself. You have to work with a specific derived type to get RTTI. That unfortunately makes it hard to impossible to do some things in the generic class itself.

It is never a good idea to block message processing in the main thread when a complex control is doing something that may depend on certain messages. The browser has an OnNavigateComplete event, use that to detect when the browser has hopefully reached a "save" state. When stopping the navigation, do not destroy the help form, hide it and only destroy it after the OnNavigationComplete event has fired. In fact I would not destroy it at all since it may get reused again. Anyway, your UI design is rather user-unfriendly in my opinion. I would not like it at all if I cannot read all of the help text just because the mouse pointer moved off the trigger control by accident. And if you only want to show a small help text explaining what the button is for a complex heavy weight browser is certainly not the most effective (and fastest!) way to do that. VCL controls have the Hint property for this purpose, and if you need decorated text (e.g. simple HTML) there are replacements for the THintwindow class used by default that can display text with formatting, like HTML, RTF, or probably also markdown.

As has been said in other replies much depends on the specifics of the case at hand. But the first alternative has one big advantage when debugging: you can set a breakpoint on the line with the assignment and directly inspect the value of Foo there.

In Delphi an alignment directive only affects the unit it is in, from the location of the directive to the end of the unit. If I understand the workings of C/C++ compilers re headers correctly (which I may not) a directive in a header also affects all other headers included after the one with the directive, so enforcing alignment in a frequently used header may have unintended effects in customer projects.

Isn't there a comment in the unit that names the type library the unit was created from? A in-process COM server is implemented in a DLL, but that DLL is not explicitely imported by the application using the COM server, so you will not find it listed in the EXE's import section. Since the error message states that the server is not found the DLL may actually not be present on your development machine. Do you have access to a PC where the program you are working on is still running? You should be able to find the DLL there.

There is no point to all of this effort in my opinion, just use methods of the TEncoding "class" directly. If you insist on writing your own wrappers do not declare your own enumeration for the encodings, just let your methods take a parameter of type TEncoding, to which you can then pass TEncoding.UTF8 or one of the other predefined encodings TEncoding offers.

Does a TCombobox, with the Items list filled with the available files, not fit your need?

In all newer Delphi versions ( I think this was implemented after Delphi 7) all forms use the Application.Mainform (the first form created in the application's autocreate list) as the window owner on the API level. If that owner window is minimized Windows automatically hides all the owned forms and it also makes sure the owned forms always are displayed above the owner form in the Z order. You can change this behaviour for your secondary forms by overriding the CreateParams method. procedure TFormX.CreateParams( Var params: TCreateParams ); begin inherited CreateParams( params ); // The following disconnects the form from the main form in Z order params.WndParent := GetDesktopwindow; // The following gives the form its own taskbar button params.ExStyle := params.ExStyle or WS_EX_APPWINDOW; end; The side effect is that the main form can now display on top of the secondary form and hide it. For popup forms that can be a problem. This modification also effectively disables the PopupParent of a form, since that is used in the inherited CreateParams to set the WndParent.

Is this project of your's a IDE add-on (wizard or such)? If it is implemented in a design-time package you can use the Open Tools API to open a file instead of leaving the task to Explorer.

If you double-click on a file in Windows Explorer that is the active application, so if you have more than one Delphi instance running none of them is active and which one is handed the file probably depends on which one the BDSLauncher app registered as "server" for .pas files finds first. You have no control over that, so do not open the file by double-click, drag it to the IDE instance you want to use to open it.

Looks like the Finalbuilder version uses a different manifest or an ancient style falling back to an old version of the common dialogs DLL. I have no idea how that could influence Ctrl-A behaviour in edit controls, though; that is handled by the native Windows control, unless you have an action or such that traps the key...

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.