BlackBox Framework Center

The Restore procedure of a view is called twice when a view is first opened.
I consider that a bug.
It should be called only once.
I have not tracked through the code to see where that is happening.
It is probably in Views.RestoreFrame.
Comments?
-Doug

I think, that it can be considered as a bug if we will study the reasons a bit. Maybe this is needed for some reason, for calculation if view sizes or something like that.

With text views the same problem about scrolling, TextView updating four!!! times for each scroll event of mouse. If I am making any text wrapper, updates multiplying.

I found the accurate consideration of such cases very important. So we can start with your issue.

From the docu of module Views:

No assumptions are allowed of when Restore is called, how often, in which order, etc. Restore should simply draw everything within the given rectangle, it must not assume that something is still on screen from the last time it was called.

So, be careful with speculations and also look at the given clipping rectangle l, t, r, b.

- Josef

So, be careful with speculations and also look at the given clipping rectangle l, t, r, b.

- Josef

"Speculation" is perhaps not the right word.
o I always ignore the l, t, r, b values.
o It is very annoying when trying to debug code that the restore procedure is called twice on open.

I really feel that is a bad implementation which should be removed from the framework.

-Doug

I recently attached a Sequencers.Notifier to a Window, so my code could cleanup when the Window was closed.

Its Notify method was also called twice when the Window was closed.

Another, similar, inconvenience.

Restore twice on Open results from:

HostWindows.OpenDoc
(1) creates a child window, which is restored, and
(2) the child window is updated, which also means that it is restored.

By commenting w.Update in HostWindows.CreateDoc (the restore in the first step)
you can avoid restoring twice on open.
HOWEVER, there are strange things then in some views, in particular
the scrollbars are not set up correctly.
So the first Update has side effects that are important.

Making any changes in the opening of documents goes very deep into
the framework and is probably wrong in some unexpected sense.
I would strongly recommend not to touch this code until we have a much
better understanding of how it works.

- Josef

Josef,
I agree.
But the issue still stands.
-Doug

I don't see any chance to fix this behavior.
The behavior may be a surprise and/or an inconvenience but, strictly speaking, it is not a bug.

I would close/suspend this issue.
For me it is annoying to keep unsolvable issues open for a long time.
It is also strange to have an open issue for target version 1.7 when we
are approaching the release of 1.7.

- Josef

Josef Templ wrote:I don't see any chance to fix this behavior.
The behavior may be a surprise and/or an inconvenience but, strictly speaking, it is not a bug.

I would close/suspend this issue.
For me it is annoying to keep unsolvable issues open for a long time.
It is also strange to have an open issue for target version 1.7 when we
are approaching the release of 1.7.

- Josef

Josef,
I am actively working on this issue so please don't close/suspend it.
Its tough to debug.
I can put in two traps and record the trap output.
What I see is the first call of Restore happens on OpenDoc.
The second call happens when "someone" asks for a "Paint".
I have yet to determine what modules is doing that.

PROCEDURE HostWindows.PaintWin
HostWindows.DocWinHandler

-Doug

This "call twice" is extremely annoying to me. I do lots of view programming.
When the Restore is called it may need extensive code execution to draw the image and hence
execution is twice as long as it should be.

I definitely call that a bug.

-Doug