I have a Windows desktop ‘Booking’ application, now laboriously updated to API2. It has a complex ‘recordviewer’. The recordviewer, embeded in a window, opens as in the first image. When I click a button or simply minimise and maximise the window, it displays as in the lower image the same as as it displayed in API1. I have struggled on many occasions to get the second ‘full’ border at first render of the viewer.
If I compare the pixels, they are identical except that the second image has a full border as I had all the days from Real Basic.
1 Like
I see the same behavior here on Windows 10. Here it’s a TextArea within a Container, within a Container, within a TabPanel, within a Container, within a Container on a standard Window. 
BTW: The Border also changes constantly while switching between Maximized and non-Maxiized Window States…
Stupid question, but this is an API → API2 converted project, so who knows:
Did you set the Border property to True ?
Yes and yes 
BTW: Why would it go on and off if this setting has not been set to True? 
This is an API! to API2 converted project. I assume it is now API2 because it no longer gives ‘depreciated’ warnings. Nothing stated: “Welcome to API2”. It is much faster. ‘Has Border’ is clicked to On in the inspector. ‘self.FieldFieldValue.hasborder = true’ is in the initialisation method, although my reading suggests this is not functioning at runtime at present.
I just commented out the lines containing the below and it made no difference.
'self.FieldFieldValue.hasborder = true
'self.FieldFieldValue.enabled = true
I tried yet another experiment. I clicked HasBorder on the ‘inspector’ to ‘off’. I added the line in code:
self.FieldFieldValue.hasborder = true
The identical behaviour occurs.
Hi Rick
That is what should happen. It is not what is actually happening. At runtime, the border is narrow, but later increases to that shown in your right image.
1 Like
That screenshot shows 2 DesktopTextArea. Left hasBorder off, right hasBorder on, running.
Windows 11, Xojo 2024r2.1
You just can’t change the border on/off at runtime.
We don’t want that either, @Rick_Araujo. Our “problem” is that the text area appears to be displayed randomly sometimes with and sometimes without a border. It changes its appearance during runtime without any code on our part triggering it.
1 Like
Random behavior is one of the worst illness a computer language could acquire. It kills it.
No one can trust an x when sometimes x=1+1 ends as 3 randomly. Imagine turning an autopilot on in an airplane to go to the restroom and… 1+1=3!
1 Like
What happens with a brand new project (DesktopWindow with DesktopTextArea only) ?
Take a look at this sample project.
This will allow you to enable/disable the textfield border at runtime using the Windows API. If, however, the border is being drawn by the Xojo framework then this won’t solve your issue.
Similar problem: DesktopTextField boxes draw correctly under Windows 10, but strong bottom line and other lines faint under Windows 11.
My solution: a control class with a borderless TextField inside a Rectangle in a container. Giving the original TextField names to the containers, the only coding change is: mytextbox.text =“words” becomes mytextbox.textfield1.text =“words”
I am fortunate that it is much more important that my program calculates correctly than that it is displayed perfectly.
The current Xojo caches some states of things to make it faster, notably, IIRC, string.length=0 caches true/false without going deeper into OS calls for example, maybe some other on/off or values? I’m afraid that bypassing Xojo State Machines MAY end with collateral effects. Random behaviors maybe even getting Xojo confuse with/resetting, their own cached values. 
Excellent. It is not something that I have done incorrectly. I’ll create my own bordered field as a class as I have done already for type-ahead fields and other such things like edible tables (editable listboxes). I guess it is something random with the current version of Xojo that will probably evaporate in time. Thank you all for your thinking. I’m 73 and getting a bit slower at this.
73 is the new 50 
2 Likes