problem with placing of toolbar

[Nifrabar]

Hi!
In my app I do use a formmanager which is described in the famous book 1001 things.
The book was originally released in vfp6 time.
Now we are years later, PC's are more fast and for that reason I presume that due to timing-matters it happens that sometimes when I have open many windows it is not always possible to close those by clicking the red X-button (WinXP)in righthand upper corner of the form. If that happens than I first have to click on the main VFP-form after which normal closing of the form is possible.
Every time when a form is closed there is (managed by the formmanager) a change of toolbar according the one which belongs to the active window. This causes for a very short while a 'jump' up and down of all windows.
It seems that is reason why normal closing of windows is not always possible.
I have a workaround for this problem by putting a dummy toolbar at start of application.
And here my question is:
Is there a way to place a dummy-toolbar which cannot be removed? Can I programmaticly decide were that toolbar is located?

TIO
-Bart

 

[Olaf Doschke]

I wonder if all your assumtions are true. Perhaps there are more serious reasons why a form does not close and only does so, after you activate the main window. Typically clicking on a fomr activates it, and that is also true, if you click on the closing X button.

That aside the solution to jumping display would be to freeze the screen while you're not ready. _screen.lockscreen is one option, but there's a better one in Windows API: LockWindowUpdate()

DECLARE INTEGER LockWindowUpdate IN user32 INTEGER hWndLock

* Lock
LockWindowUpdate(_Screen.hWnd)
* Change Toolbar
* .... your code
* Unlock
LockWindowUpdate(0)

Bye, Olaf.

 

[Nifrabar]

Hello OLaf,
Thanks for feedback.
As I stated: the behaviour was based upon assumptions.
I got the formmanager-code from the book 1001-things.
Code in that book (real treasure for usable code) is almost always working. The updates of the E-book gives some bug-fixes. As this book is many years old now I do assume (again assume) that there are less other bugs in it.
For now my workaround is with th edummy toolbar which I found can be coded quit easily with this.dock(0,0,0) and stayed in place with this.movable is .F. and this.enabled=.F.

"Typically clicking on a fomr activates it, and that is also true, if you click on the closing X button."

That's true but in this particular situation it happens that I can give focus to eg textbox on th eform but I can't control the X-button. It even does not show the graphic-behaviour if the mouse hoovers over the X-button.

Weird though?

-Bart

 

[Imaginecorp]

"Every time when a form is closed there is (managed by the formmanager) a change of toolbar according the one which belongs to the active window. This causes for a very short while a 'jump' up and down of all windows."

If the X-button on a form is not closing it, the form probably has "closable" set to .F. in code as the toolbar is closing the form.
“Jump” is because the toolbar is being rebuilt and redisplayed. (I am assuming)

 

[Imaginecorp]

as the toolbar is closing the form."

Toolbar = Form Manager

 

[Nifrabar]

Imaginecorp,

You are right that the jump is caused by hiding or releasing a toolbar and showing or instanciating a new one.

There is absolutely no code in the formmanager which disables the X-button.
I even can give focus to controls on the form but if I hoover over the X-button this also does not have any effect on that X-button.

So for now I leave this problem solved by using a dummy toolbar which is always there although I know it's not a real solution.

-Bart