>Armin pointed out to me that I missed the AlwaysOnTop bit. I do see what you report in both 7.0 and 5.0. Seems to me that such dramatic change in functionality should be at least documented. (I like the way it is in 5.0, better, though.)
>
>You might consider for this and your other reports, writing an entry for the WishList that's maintained here. Please do use my code with the addition of an AlwaysOnTop = .T. to demonstrate exactly what you mean. Runnable code helps so much.
>
>Except you say you like the new behavior, so I guess you don't want it changed. Ah, well.
Nancy, thanks for you input.
I'd say it was a bug in 5.0. I mean, why wouldn't it be allowed to let the AlwaysOnTop rule on other Win-tasks as well ? So, it is additional functionality, but not opposed to VFP5 because in there it was buggy.
The latter I find true because there is
much more related to this, all difficult to explain, and merely a feeling. Anyway, the anomalies in 5 only start to occur when you a. create different Win-tasks from within the one VFP instance, and b. when you "switch-off" _SCREEN. In 5 you are totally out of control, and a lot of .Visible = .T.'s and .F.'s and more is needed to arrange all as you like. Runtime behaves differently from Development. You are really in trouble when another Win-app is started from VFP, like Notepad. This mixes up the, say, internal ZOrder of things, and in the end I wasn't able to get it 100 % for the Runtime.
For the Development there is just this other anomaly around again the starting of the other Win-app and after that the F10 function key not working anymore. This too has to do with _SCREEN sending to the back in some illegal manner, and only when bringing it to the top again and then making it invisble again, the F10 starts working.
All this doesn't apply to 7, and IMO because all the stupid (I think) illegal manipulation isn't needed anymore.
All is not that simple at all, because the buggy environment was just created by myself by accident, on having one of the Win-tasks created from VFP with the AlwaysOnTop = .T. in VFP5. I never saw it, because it didn't work. Now I have it set at .F., and now VFP5 doesn't cause the anomalies to happen anymore.
So, in the end it comes to not being allowed to have the other Win-task at AlwaysOnTop in VFP5, and in VFP7 you can do that without penalties.
That, in the mean time, the task is OnTop over the other Win-apps (like Word) suits me well (don't need that now, but you never now ...). HOWEVER :
This urges for some ZOrder manipulation (relatively to) upon the other Win-apps, right ? Well, I don't think it 'll work like that (read : isn't allowed). So the least think we'd want is control our "own" Win-tasks (all we created from the one VFP instance), and I didn't try anything on that. But I am sure this can be arranged again by making the tasks (forms) Visible in the certain sequence. So, all forms (tasks) with the AlwaysOnTop = .T. will have a ZOrder of the first form made visible at the bottom opposed to the second, and so on.
In the end, yes, I like it this way.
[update] As it turned out, VFP7 solves the next (in this area) as well :
When at the init of the app another Win-task is created, there is no means (I found) to make the original task's form active by means of codee. It needs a click or an alt-tab (arriving at the same form ... !). In VFP7 this is no problem anymore. Note that this has nothing to do with the AlwaysOnTop = .T.-accident. So, right now (all AlwaysOnTop's are .F.), VFP5 still can't deal with this.
Peter
