rdonnay wrote:I need to see your FORM_BOX command.
I think the issue may be the TEXTOBJ clause.
This may not be actually creating a proper pointer to the object, which would cause the buttons to be children of the dialog drawingArea rather than the FORM_BOX.
To insure that this is correct you can use the DC_ArrayView() function. It will show you the children of oText1Static.
Do this:
DCREAD GUI EVAL {||DC_ArrayView( oText1Static )}
This should show you the child list. You should see a lot of DC_XbpPushButtonXP() objects.
Looks like "CustomStatic" does not repaint in every situation where repainting is needed.
It should be easy to determine if it is the source of the problem.
Just comment out the SUBCLASS clause.
Roger, we've decided to comment out the "CustomStatic" Subclass command first. It's working for us at the moment.
I've tried to create a sample project for you, but a simple one does not have the 'disappearing' behavior. Which led me to believe that our app's way of handling windows/dialogue can also be the cause.
Until I can replicate this in a sample project, I think we'll just use without the owner drawing of the static and use a recessedbox instead