PeterBelow

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.

What is build into the VCL is the drag and dock support also used by the RAD Studio IDE, the "snap to border" functionality is something different. If none of these two features match your need you have to build you own, which you seem to have done now. Do you know you can use inheritance with forms as well? Build a base form class with the functionality you need, add it to any new project you need this functionality in and then create new forms in the designer by using File -> New -> Others, and pick the base class from the "inheritable items" section. Just changing the ancestor class from TFrom to your base class in the editor does not work directly, since forms have associated DFM files. You would also need to edit the DFM file as text and change the first "object" to "inherited" for this to work.

Via TStringHelper you have to first convert the string into an array of char, modify that, and then convert the array into a new string. var LChars: TArray<char>; LStr: string; begin LStr := StringOfChar('A', 20); LChars := LStr.ToCharArray; LChars[Low(LChars)+1] := LChars[Low(LChars)+1].ToLower; LStr := String.Create(LChars);

The default for the linker options of a debug configuration is to include debug information into the produced EXE. That massively increases the size of the EXE, and, if you are using the IDE debugger (for a 32 bit project), is also completely useless, since the IDE debugger gets the debug info from the DCUs, not the EXE.

You have to modify the design-time package that registers the property editor and rebuild it. Or just disable the package if you do not use any of the controls from it.