xsharp.eu

I have never used VO or its development environment.
I have converted a large VO application to X# and most of it is running fine. But I am having problems with a few little things not quite working.

I have a problem with some graphics in an X# program ported from VO. The program draws small diagrams on a form, the shape of a spectacle frame, and if the frame changes, it wants to erase the old diagram and draw the new one, but instead it draws over the one that is already there, so the erase is not working.

The code it uses to do the erasing is this:

SELF:oOwner:RePaintBoundingBox(boundingbox{SELF:oPoint, SELF:oDim})

Now oOwner is the containing form inherited from VO.DataWindow so that RePaintBoundingBox is a method from the VOGui class. The variables oPoint and oDim define the area on the form to be cleared. They contain sensible values and are also used to by the drawing routines to draw the diagram and work correctly there.

Now I have limited documentation on the VOGui methods but re-painting does not sound to me like something that would clear an area. It sounds much more like a method to restore an area to its original graphics after it had been occluded by another window or similar.

Is this the way to clear an area on a form?

Thanks,
John

Hi John,

This is the code of the method in the SDK:
so, indeed, what it does is to invalidate the area and then it's up to the painting code to do the rest. If it's a good way doing it or not depends on how the whole thing is implemented... Does this feature work well in the VO version of the app? If it does, can you create a small sample with just one datawindow that uses the same code and does the painting and post it to have a look? Maybe there's some issue in the X# version of the GUI classes causing the different behavior, but having a repro sample would greatly help spotting it.

Hi Chris,

Thanks again for your prompt reply.

The area on the form where the diagram is drawn is empty (form background) initially, but when I draw the first diagram it is, of course, no longer just background, so I guess the question is, when the repaint happens, does it repaint the initial contents, or the contents as it last was, with the drawing. It certainly looks as if it is doing the latter.

I will see if I can cook up an example.

We had also different problems with redrawing of the background on datawindows in VO, mostly the other way round that redrawing of the background erased parts of the controls/drawings. A data window consists of 3 overlayed windows: The datawindow, the formframe and the surface. And depending on slight changes in the order of the windows messages there may happen something unwanted.

The following parts influence the behavior:
- Is a background brush set for the window?
- Is the program running with the XP Themes enabled?

There should be another method of datawindow that can be tested instead of RepaintBoundingBox:
RePaint()

Arne

The invalidaterect marks only the region as to be repainted and does not repaint the background immediately. If this has worked in the past, then probably, because of some other effects, for example double calls of the image.
One possibility could be to draw a white rectable.
Or to delay the new drawing.
Or to call Exec (1/*ExecWhileEvent*/) of the App object
Probably the best way to resolve it is to paint a
Or to use an image control as "container" for the image.

Arne

Hi All,

Thanks for everyone's feedback.

Since I started this off, I feel I should report the resolution I discovered. That erase routine was doing the right thing, but was erasing a part of the window different from where the drawing was being created. The class handling the drawings expects a user to provide:

- Where you want the drawing done, by specifying an origin
- Where the plot area is, for erasing

There was no check that these two things were consistent, so the RePaintBoundingBox was clearing a window area back to its original state but the drawing was being done elsewhere. The class constructor was modified to check this and throw a message when things look fishy. This identified similar problems in other parts of the code that were then fixed. Sometimes the drawing was partly erased, leaving "ghosts" of drawings past.

Cheers,
John