1
votes

as the title states, I am encountering some weird GUI stuff using DELPHI XE6 for IOS. In my login box - I have a TRectangle, that has two TRoundRects anchored on each side. I guess this is my lazy way to create a button/container that has rounded edges instead of being completely square. If you look at the picture below:

enter image description here

you can see the outline of each RoundRect. The fill is SUPPOSED to be white, and initially is. Whenever I open a form - then close that form to come back to this one - the RoundRects.Fill both go to ':=null'. If you can see, I have another TRectangle + RoundRects for another container that is sitting right above it. ( Both rectangles have the same parent, which is a Tlayout). The blue container's round rects don't go null. Not sure where to begin debugging because of the inconsistent behavior between the two containers. Any guidance or direction on how to go about fixing this would be much appreciated!

Also, KEY NOTE I suppose: Whenever the roundRects go null, If put focus on any control ( TEdit, button, etc. ) then the roundRects correct themselves and go back white.

1
Why do you have one TRectangle and two TRoundRectagnles for each "button" in the firs place? Why don't you simply use one TRoundRectangle for your "button" instead.SilverWarior

1 Answers

3
votes

Are you sure that they are being set to null (have you checked the value?) or is the effect simply failing to render?

If you're sure that the value is being changed to null, this is actually very simple to debug:

  • Run the program and set a breakpoint at a known-good place (where the value is what it should be)
  • Use ALT-F5 to evaluate the value of the fill. It should show the address in memory. Copy this address.
  • In the debugger's Breakpoints panel, click the dropdown arrow on the Add Breakpoint button, and add a Data Breakpoint
  • Set the address to the address you copied from the Alt-F5 evaluator.
  • You now have a breakpoint that will break when this value changes in memory, rather than at a specific line of code. This will lead you to the code you need to be looking at, either at the point where it breaks or down the call stack from it.