If I set the window full screen using normal methods then using TCastleControlBase appears to reset the form to the size of the CastleControlBase.
I can see my form briefly go fullscreen before being reset using the recommended cross-platform method in the Wiki
ShowWindow(Handle, SW_SHOWFULLSCREEN)
Ref: https://wiki.freepascal.org/Application_full_screen_mode#Universal_way_to_use_full-screen
Checking on Linux (GTK 2 backend), I cannot reproduce the problem.
Attaching a trivial application. lazarus-test-fullscreen.zip (62.7 KB)
Tested with Lazarus 2.0.9 from SVN https://svn.freepascal.org/svn/lazarus/branches/fixes_2_0 , and FPC 3.2.0-beta from SVN https://svn.freepascal.org/svn/fpc/branches/fixes_3_2 , last SVN state on 2020-04-20 .
On what system do you reproduce this problem?
Also, can you check does it occur also with TOpenGLControl (part of Lazarus)? Our TCastleControlBase merely descends from TOpenGLControl.
Note that you can also use TCastleWindowBase. Then you have to design 100% of your UI using Castle Game Engine (no LCL components). But I know it has a reliable TCastleWindowBase.FullScreen property that can be toggled 
Under Win10 it goes Full Screen with border…
You can fix this in the trivial example with…
BorderStyle:= bsNone;
Some code tweaking allows for the expected results for switching between FS, Maximised + Normal display choices (yu have to set BorderStyle depending on the desired results).
However, when I try the same in a project with more of CGE in the uses statement there’s a clash with that line.
FYI the proper test project has this lot…
uses
Classes, SysUtils, Forms, Controls, Graphics, Dialogs,
LCLIntf, LCLType, ExtCtrls, Menus,
X3DNodes, X3DLoad,
{$ifndef VER3_0} OpenSSLSockets, {$endif}
CastleDownload, CastleParameters, CastleClassUtils, CastleImages,
CastleControl, CastleSceneCore, CastleVectors, CastleScene, CastleViewport,
CastleNotifications, CastleUIControls, CastleTransform, CastleLCLUtils,
CastleKeysMouse, CastleLog, CastleTimeUtils;
As for the issue that started this thread:
If I set the window full screen using normal methods then using TCastleControlBase appears to reset the form to the size of the CastleControlBase.
Testing on Windows 10 now, I also cannot reproduce this issue. So it works OK for me, on both Linux and Windows 10. Using recent Lazarus 2.0.9 and FPC 3.2.0-beta.
Note that the API to set fullscreen and border style is part of Lazarus LCL, in case of using Lazarus TForm. We don’t change here, that’s just how Lazarus LCL works.
If you would use our TCastleWindowBase, then you have simple TCastleWindowBase.FullScreen boolean, that can be toggled. And on Windows 10, fullscreen then works naturally (automatically obscuring Windows status bar, and hiding window border). That’s the “fullscreen” implementation that is controlled by CGE code 
As for clash: indeed we also define bsNone in CGE units. Just use Controls.bsNone (qualify it by unit name) to indicate LCL BorderStyle.
The Controls.bsNone qualifier doesn’t work - but can be ‘fixed’
Take the trivial example above and put my uses clause in there - it won’t compile no matter what you do - unless…
If you move the Controls uses clause either to the end of the interface uses statement or move it into implementation the trivial application works as expected.
While this works and will do for now I’m slightly bothered that it may affect something else when I turn all my test projects into a real application (I’m getting closer all the time to that goal).
ATM I want to use LCL for design so TCastleWindowBase.FullScreen is not an option. The 3D part of the application is a good way to visualise the data (cards in my case). I’d definitely attract the unwanted attention of a load of lawyers if I made a game with someone else’s content (they already market a game with that content)…
Ah, I see, within a method of LCL TForm we have a property Controls (from TWinControl class). This in turn obscures the Controls unit, making Controls.bsNone not possible inside a method.
You can avoid it by defining a constant outside of the method:
const
BorderNone = Controls.bsNone;
procedure TForm1.Button3Click(Sender: TObject);
begin
BorderStyle := BorderNone;
end;
It doesn’t look pretty, but it’s a simple fix (and doesn’t require rearranging uses clause, so it will not necessitate any other change).
I could rename bsNone (and consistently obsNone) in the CGE, but then I would need to keep the old name defined for some time anyway (to keep backward compatibility), only marked as “deprecated”. So it would not solve this issue immediately anyway (only it would allow me to remove bsNone after a few releases). Let me see whether others will be troubled by this issue, I’ll do it if I hear signal that it’s bothering anyone else
I’m perfectly happy with a work-around that don’t affect anyone else so I’ll give the suggested remedy a try in a bit (I really should eat something first… Too busy playing with CGE etc for food…)
A FAQ or something (an IAQ - Infrequentry Asked Questions?) with little odds and ends like this would prove a useful resource. I’m sure there are loads of little helpful hints like this one in other topics.
For example I’ve turned our posts on downloading and applying a texture image into one procedure that downloads an image, resizes it if needed, saves it to a cache and uses the cache to apply the texture - properly sized textures on demand… An Infrequently Asked Question in action…