TTMSFNCResponsiveManager: Class not found when using TImage and switching states

This is simliar to this other topic and the workaround there works at runtime, but not at design time:

  • Create a new FMX project, and in the default form drop a TImage and a TTMSFNCResponsiveManager (by default it sets its Control property to the main form)
  • Save this state (Right click at the TTMSFNCResponsiveManager -> Save To New State)
  • Resize the default form and save as another state
  • On the Object Inspector, with the TTMSFNCResponsiveManager selected try to switch the ActiveState property

IDE shows 'Type "TFixedBitmapitem" not found.' On a side note this also happens with class TGradientPoint on one of our projects.


Please click Optimize in designtime right-click context menu to avoid adding all properties in the responsive manager. The technique used is storing all properties in JSON in the responsive manager, and apparently, TFixedBitmapItem & TGradientPoint are classes that are not registered at designtime and therefore the responsive manager is not able to pick them up. Optimization will have to be done each time you change a state, eventually, you can optimize one time, once the application is finished designing. We'll investigate if we can workaround the issue.

Well, the optimize technique worked for our project with TGradientPoint, states can be switched without errors al design time and there is (apparently) no need for manually registering the classes at runtime, but for the blank project with a single TImage control with no image assigned the IDE shows this now when switching states:
Access violation at address 673F0337 in module 'rtl280.bpl'. Read of address 00000065.
I'm attaching the stack trace shown by the IDE.
traceback.txt (5.3 KB)

Edit: The problem with TGradientPoint is back. I checked the optimized FMX file and I see no references to this class, so the problem should be elsewhere.

Once you get an exception, the access violation follows and is hard to get rid of unless you restart the IDE. Either way, we have implemented a fix that will ignore exceptions of unregistered class types at designtime. Next version will have this included.

Ok. Thanks.