PeterBelow

Excellent analysis! Would you please log a bug report for this problem on quality.embarcadero.com?

Instead of a listbox, use the VCL TScrollbox as container for the frames.

This is the kind of problem the IDE's repository was created for. You do not need a wizard for this, just create a template project to serve as the starting point for new projects, and add it to the repository. It is then available in the repository dialog (File -> New -> Others), pick it, immediately do a file -> save project as and start to work on it. For teams of several developers a shared repository can be created on a network path. If that is not flexible enough for your purpose I would not create a IDE wizard for this task but a stand-alone program you can tie into the Tools menu as an external helper program. This way the tool is not specific to a particular RAD Studio version, you do not run the risk of destabilizing the IDE due to errors in using the (poorly documented) OpenTools API, and it is easier to maintain. The tool would simply ask for a new folder for the project to create and then create the required files to start with there.

This is, in my opinion, a programmer error, not a problem with the framework. You are using data that does does not fit the declaration of the database table. In such an occasion I would expect the framework to throw an error, since bad input should definitely not be swept under the carpet but brought to the user's attention. So, if the value you use for PARAM comes from an edit control filled by the user, the MaxLength property of that control needs to be set to the length of the database field the input is destined to be used with, so bad length input is simply not possible. If that is impractical you have add your own checks for the input before it is used, and produce a sensibel error message, e.g. "A machine ID cannot be longer than 32 characters.". Just my 2 Euro-cents...

I think doing a File -> Save all also saves the list of open modules. The dsk file is basically only legacy, the relevant data is also saved to registry keys. You do have the autosave option for the project desktop enabled in the Tools--> Options dialog, I assume?

Dmitry gave you a possible solution for the specific problem you posted (TDataset descendents). I think this is generally a case for the facade pattern: you extract the functionality the method needs to access to an interface type (or a wrapper base class) and make your divergent descendents implement this interface or provide a factory method for a suitable derived wrapper class instance. The method parameter is then typed as the interface or wrapper base class type.

Usually by copying a unit file via Windows Explorer instead of using the IDE's Save As menu. If you then just open the copy in the IDE it is not part of the project, that is still holding the original file you copied. It goes downhill from there, believe me. Have done it and have the scars to prove it ...

When that happens to me the project is typically in a state that would not compile, with errors in a unit other than the one I am currently working on. If your project builds, however, I would suspect that you have duplicate files around, so the IDE works on files different from those the build process uses.

No, you are just setting and looking at the wrong search path. You need the one under Delphi compiler, not the one under Resource compiler!

Have not seen this myself, but my application are not nearly this large (largest was a bit over 10 MBytes). Check the project debug configuration, linker settings. If you now include debug information with the EXE, remove that checkmark. The IDE debugger uses the debug info from the DCUs, not the one in the EXE, so it just makes the file much larger, without any benefit. A smaller EXE may reduce the chance of running into this problem. Just a guess...

The project configurations form a hierarchy, simple select the top node ("all configurations - all platforms" probably, I have a german language version of RAD Studio) in the project options dialog, compiler options, dropdown list on the top of the right hand pane.

From your description the data you get back are not characters, so do not use an array of char, use an array of byte. In fact you should be able to use something like this: type TTagResult = packed record DFSID: byte; case boolean of false: (UIDasBytes: array [0..7] of byte); true: (UID: Uint64); end; TagBuffer = packed array [0..15] of TTagResult; type the DSFIDAndUID parameter of the Inventory function as var DSFIDAndUID : TTagBuffer and you should be able to just pass a variable of type TTagBuffer and get the result back in a digested format.

Why are you rebuilding 3rd-party dcus as part of your build process? IMO only the (prebuild) DCUs should be on the IDE library path, the source code folders should only be on the IDE search path and not on the project's search path.

A clear case of premature optimization, IMO 😉

Well, you have been given some examples, but my question is: WHY do you want to know this? The whole point of polymorphism is that in the base class you do not need to know whether a descendant has overriden the method or not. In fact the base class does not even know whether there are descendents of it, and neither should it care. If you think you need to know whether a method has been overridden in descendents something is wrong with your class design, IMO.

If you run the relevant external compiler from a command prompt without any parameters it should give you a list of the available switched and what they do.

If you just opened the old project in 10.1 Berlin the project options will not be set correctly as far as debug information is concerned. In older versions the "debug information" setting in the compiler options was a simple boolean yes/no value. Later it morphed into a value with three possible values and the migration of the old project files does not take that into account. So check the compiler setting in the project options for the debug build.

If you let the OS handle the drag your code is out of the picture until the drag ends, the OS uses an internal message loop to process mouse messages. The only way to hook into that would be a thread-specific message hook (see SetWindowsHookEx in the API docs). You may be better served to use the VCL drag support or handle the mouse yourself. Set the DoubleBuffered property of the paintbox to true, that should reduce the flicker.

It's a VCL issue. I noted another yesterday: if you type text into a property (like caption) that is longer than what fits into the visible width of the OI column the text does not scroll while you type to keep the caret in view.

The docs you quoted state that the version is encoded in the *hexadecimal* value returned. You look at the decimal value. Decimal 11264 is hexadecimal 0x2c00 ($2C00 in Delphi notation). So the version is 2.12.0.0

Perhaps these old routines can help you. They are Windows-only, though. {! <summary> Remove all key messages from the calling thread's message queue.</summary> } procedure EmptyKeyQueue; var Msg: TMsg; begin while PeekMessage(Msg, 0, WM_KEYFIRST, WM_KEYLAST, PM_REMOVE or PM_NOYIELD) do ; end; {! <summary> Remove all mouse messages from the calling thread's message queue.</summary> } procedure EmptyMouseQueue; var Msg: TMsg; begin while PeekMessage(Msg, 0, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE or PM_NOYIELD) do ; end; {! <summary> Remove all key and mouse messages from the calling thread's message queue.</summary> } procedure DiscardPendingInput; begin EmptyMouseQueue; EmptyKeyQueue; end;

What Delphi version are you using? In older versions the Application object was actually the one owning the taskbar button, all other forms used the (zero-size) window maintained by the Application object as API-level owner, and Window does not show taskbar buttons for owned windows.

It makes automatic memory management via garbage collection easier to implement and more efficient as far as I know.

There is one loophole in your design: if a form is destroyed it will not automatically set the form variable the designer created for it to nil. I can only stress what has been posted in some of the other replies: do not use the form variables for forms that are not autocreated! Delete the variable declaration directly after the form unit has been created by the designer. Use local variables for modal forms (or a class method to create, use, and destroy them). For modeless forms you can always find existing instances by looking at the Screen.Forms array, or have the main form (which presumably creates such a form on an as needed basis) keep the reference in a private field. The automatic form variables encourage some bad programming practices (like accessing controls on another form directly) and become worse than useless if you have to have more than one instance of a given form class open at the same time.