Uwe Raabe

Alternative: Left := - (Width - ClientWidth) div 2;

WindowState := TWindowState.wsMaximized; var L := Left; WindowState := TWindowState.wsNormal; Left := L;

Oops!

I know what is happening: In MMX settings under Delphi Editor there is a setting Auto toggle Object Inspector and Code Explorer reacting on F12. Try to disable that.

Can you give detailed steps? This is what I tried (I refused to fiddle around with my standard layout): Create a new layout with MMX floating (usually I use it in a docked layout) Make that layout standard Switch between Form and Source design: MMX stays open floating Close MMX window Switch between Form and Source design: MMX stays closed Reload the layout: MMX appears floating Close MMX window and save the layout Make MMX visible again Repeat the tests above: Works as expected with MMX staying closed after reloading the layout MMX visibility and position is stored with the layout, so just closing MMX will only hold as long as the layout is not changed. This is standard behavior for all IDE windows. Side note: I know, I'm biased, but I would not even think of closing MMX anytime, because I use it all over the place. It gives me way better overview of the current unit and allows for faster navigation. Even while designing I have MMX fully visible or at least in a flyout tab. Renaming components with MMX is so much better than doing so in the Object Inspector, as it also renames all references in the code.

I have another approach: type TSplitter = class(Vcl.ExtCtrls.TSplitter) private FInMoveSplitter: Boolean; FSibling: TSplitter; protected procedure WndProc(var Message: TMessage); override; public procedure MoveSplitter(var aMsg: TMessage); property Sibling: TSplitter read FSibling write FSibling; end; procedure TSplitter.MoveSplitter(var aMsg: TMessage); begin FInMoveSplitter := True; try Perform(aMsg.Msg, aMsg.WParam, aMsg.LParam); finally FInMoveSplitter := False; end; end; procedure TSplitter.WndProc(var Message: TMessage); begin if (Message.Msg >= WM_MOUSEFIRST) and (Message.Msg <= WM_MOUSELAST) and not FInMoveSplitter and (Sibling <> nil) then Sibling.MoveSplitter(Message); inherited WndProc(Message); end; Linking is a two liner: Splitter2.Sibling := Splitter3; Splitter3.Sibling := Splitter2;

Well, I cannot reproduce on my system (Windows 10, Delphi 11.1). I can try a fix, but I cannot verify if it is working.

Thanks for reporting. Looks a bit like VCL style related.

It shows the return type of the selected property or function, void in case of a procedure, empty if nothing like that is selected. I have no CnPack installed here.

There must be more than only these two steps. Changing something in a unit and closing it without saving happens several times in an hour without showing any problem - not only on my system I guess.

Are you trying to say, you are using interfaces only to avoid being responsible for destroying your object instances?

Yes, the variable where the date is going to be stored.

Let me guess. Your code looks something like this: if TryStrToDate(Edit1, theDate) then But it should be if TryStrToDate(Edit1.Text, theDate) then

Well, I cannot speak for C++-Builder, but in Delphi there is type UTF8String and you can just assign to and from string: var S: string; u8: UTF8String; begin S := 'Hello World'; u8 := S; u8 := 'Hello World'; S := u8; end;

What variable type are you going to store the UTF-8?

Check if you have more than one declaration of MyAttributeOne.

IMHO, using caFree seems not the best approach for the ShowModal case. With caFree a message CM_RELEASE is placed inside the message queue of the form, which will lead to Free when this message is processed later. This is OK when calling Show for the form. I suggest to keep the default caHide Action in the FormClose and add a FDetailForm.Free in the finally block.

When the MainForm is closed the application is terminated. That implies that all forms created with Application as owner will be destroyed, but not closed (so OnDestroy is called, but not OnClose). The order depends on the components order inside Application. Any form created without an Owner will just vanish.

No, that is not possible.

If it is a regression, it dates back to Delphi 7 (cannot test for Delphi 6). Given that conditional expressions were introduced in Delphi 6 I wonder if that has ever worked.

The current implementation of one overload of TTestDataProvider.GetProvider looks like this: class function TestDataProviderManager.GetProvider(const AClass: TTestDataProviderClass) : ITestDataProvider; var key : string; begin result := nil; if (FList.ContainsValue(AClass)) then begin for key in flist.keys do begin if (flist[key] = AClass) then begin result := TTestDataProviderClass(flist[key]).Create; break; end; end; end; end; Is there any reason why that cannot be written as: class function TestDataProviderManager.GetProvider(const AClass: TTestDataProviderClass) : ITestDataProvider; begin result := AClass.Create; end; With that one could avoid registering the provider. The reasoning for my question is, that I have a base provider class and several derived classes to overcome the lack of ability to parametrize a data provider instance. All these derived classes are local to one test unit and I would like all of them to have the same class name. Unfortunately the registration requires me to give distinct names for them and you know - naming is hard. Just declaring the derived class and use that in a TestCaseProvider attribute would simplify this a lot. Concrete: TTestDataFilesProvider provides a list of files, but requires the path and search pattern as parameters. Now I derive individual classes (with fixed values) immediately before they are used.

Perhaps you are just expecting something the method isn't intended for. ExecuteAll doesn't execute all scripts in the SQLScripts collection. It only executes the first one (the main script), while the others are meant as subscripts to be called by name from the main script or other subscripts. This is an example from the docs: with FDScript1.SQLScripts do begin Clear; with Add do begin Name := 'root'; SQL.Add('@first'); // explicitly call 'first' script SQL.Add('@second'); // explicitly call 'second' script end; with Add do begin Name := 'first'; SQL.Add('create table t1 (...);'); SQL.Add('create table t2 (...);'); end; with Add do begin Name := 'second'; SQL.Add('create procedure p1 (...);'); SQL.Add('create procedure p2 (...);'); end; end; FDScript1.ValidateAll; FDScript1.ExecuteAll; That said, TFDScript is not a container for scripts to be executed in sequence by calling ExecuteAll. That has to be done by your own code.

What graphic class is image? You can retrieve that from imgPerson.Picture.Graphic.Classname

In that case changing that field value inside the program seems a pretty rare case. The shown queries give the impression that some dummy fields are returned with no relation to the data in the database. As there are better ways to create such fields in the program it makes the query the wrong place for it.

Exactly! The approach used in the query is just the wrong one.