EDIT: also, as a workaround, can someone show the expected code when PairSplitter is inserted? I can then insert the necessary lines to get past this bug for my project, at least.
I am referring to the test project that you posted earlier. Open the lfm file (unit1.lfm) in an external editor. You'll see the PairSplitter properties like this:
object PairSplitter1: TPairSplitter
Left = 10
Height = 90
Top = 10
Width = 90
Position = 45
object TPairSplitterSide
Cursor = crArrow
Left = 0
Height = 90
Top = 0
Width = 45
end
object TPairSplitterSide
Cursor = crArrow
Left = 50
Height = 90
Top = 0
Width = 40
end
Note that the two TPairSplitterSide lines hightlighted above do not have variable names. Insert a unique variable name and a colon:
object PairSplitter1: TPairSplitter
Left = 10
Height = 90
Top = 10
Width = 90
Position = 45
object PairSplitterSide1: TPairSplitterSide
Cursor = crArrow
Left = 0
Height = 90
Top = 0
Width = 45
end
object PairSplitterSide2: TPairSplitterSide
Cursor = crArrow
Left = 50
Height = 90
Top = 0
Width = 40
end
Now you must also introduce the new variable names in the pas file. Open the pas file (unit1.pas) in an external editor, and add them below the PairSplitter1 declaration, but definitely above the "private" section so that the IDE can find them:
...
TForm1 = class(TForm)
PairSplitter1: TPairSplitter;
PairSplitterSide1: TPairSplitterSide;
PairSplitterSide2: TPairSplitterSide;
private
...
Now you should be able to use the form in the IDE.
Although you have no other choice to do so in this case, I would like to emphasize that it is not recommended to edit the lfm file in general because there is no protection against any errors that you may make, the IDE will simple refuse to open a defective lfm file... Therefore, always make a backup copy of the lfm file (or better: the entire project) before you edit it.