Textfield pops up over controls on top when the mouse passes by. Control Zorder messed up...

Targets Windows
1

I thought I reported that before but apparently not. Today I have been working on a new project, and this is really annoying. I display controls that are laid over rectangles, to obtain the panel effect in modern API Windows 8 apps. They come over the screen from the left and should be opaque.

When the mouse passes over a textfield, it comes to front, obliterating the rectangle and any controls it contains over it.

Visibly, passing over the textfield messes up the controls z order.

Expected Result:
Textfield remains in the back

Actual Result:
Textfield pops up over whatever control is on top of it.

Workarounds:
None. Maybe some declares, but we should not have to go through this…

<https://xojo.com/issue/38290>

I searched the forum but did not find any mention of that particular issue. However, there was a post about HTMLViewer insisting the same way to stay on top. For once I am going to refer to VB which enables controls Z order changes during run. Maybe that would have enabled a workaround. Unfortunately, a search through both forums leads only to a broken link page :frowning:

Anybody would have some Windows declare to change controls Z Order dynamically ?

2

When the mouse passes over a textfield, it redraws. That’s a win32 thing, I believe. The only fix for it will be going to a .Net framework. For now, layering controls is bad ju-ju.

3

Is this the one: <https://xojo.com/issue/36238>

Is this not the same as the following topic?
https://forum.xojo.com/16818-text-field-showing-through-listbox

4

I know Win32 does not like much layering controls. But there is a very big difference between a ton of layers and two controls. Besides, it is not a question of flickering.

What is especially strange is that the textfield pops up, even if it is under a rectangle or a canvas. It seems abnormal that MouseEnter or MouseOver should fire when the TextField is not visible.

[quote=169812:@LangueR]Is this the one: <https://xojo.com/issue/36238>

Is this not the same as the following topic?
https://forum.xojo.com/16818-text-field-showing-through-listbox%5B/quote%5D

Thank you. I did indeed remember clearly the issue, but could not recall from when or where. The annoying thing is that the workaround of the canvas between the listbox and the textfield does not work for a rectangle.

Unfortunately, I had not filed a bug report back in October so the Xojo team probably did not notice. Now it is done. I just hope this gets attention now. It is not nice at all.

5

No there isn’t. Why would it matter if it were two layers or twenty? If it doesn’t work, it doesn’t work. Why would you think otherwise? I know it sucks. But it just doesn’t work.

It wouldn’t matter. There’s nothing they can do, other than going to a different framework.

6

As Tim said, don’t overlay controls. What we do in he IDE when we need this type of look is to surround the control with four canvases (top, bottom, left and right) each which draws its own segment of the control that is to appear behind the other one.

7

How can you be so sure this is the normal behavior of that control ? TextArea does not do it…

I understand. Fact is refactoring Mac UI can make it not quite so straightforward. I am now working on borderless modal windows that will be displayed as Modern UI Windows panes.

8

Would it serve for your case making it (the text field) visible ON/OFF?

9

As soon as it is visible it snatches focus when the mouse passes over it. I checked : the gotfocus event fired. This is plainly wrong and no matter how I look at it, it must be a blatant bug. VB never did such a thing, and a control that snatches focus like that would be famous by now. There is absolutely no mention of that on the Internet. When Tim Hare claims that this behavior is normal and it would be necessary to change framework, I am inclined to take it with a full pound of salt. It is preposterous.

Because a bug has existed for a while on a platform that is sometimes the lesser loved child does not make it right.

If I am not mistaken, TextField is a Windows TextBox class. It is mentioned nowhere in Msdn that a TextBox gets focus when the mouse passes over. After two decades using windows, I never saw that behavior before bumping into the nasty Xojo bug. https://msdn.microsoft.com/en-us/library/system.windows.controls.textbox(v=vs.110).aspx

I tried all sorts of workarounds, until I replaced the TextField by a non styled TextArea of the same size and everything got civilized. Nevertheless, this aggressive TextField thing is a disgrace. I really hope Xojo tames it before it bites someone else.

10

You didn’t say anything about focus. That is definitely a problem, albeit one that I haven’t seen before. I’ll try to replicate that functionality.

11

Just download the project I attached to the bug report. It is really not normal.

12

Focus is a red herring. It’s not stealing focus when the mouse passes over. It is, however, redrawing, which has been the case for a long time and every time it’s been discussed, Xojo has said there’s nothing they can do about it.

13

I doubt this is the normal behaviour of Windows. I’ve never seen it in another program.
Just in these pictures (I captured from my Firefox Google-Contacts and from KompoZer) when I move the mouse on top of the textfields they redraw (first case) or not (second case), but never go on top of the other rectangle.

14

There may be something that makes a textfield redraw when the mouse moves over. That should not be too much of an issue, even if unusual.

The get focus thing is much more of a problem at the heart of the popup mess. Just put a debuglog in the GotFocus event of the textfield ; it fires when the mouse passes over. Even when the textfield is under another control. This is resolutely abnormal.

I wonder if Xojo really cannot do anything, or won’t do anything. If there is indeed a bug in the Win32 control they are using, would that be Edit (most probable), why not use another control that does not exhibit the bug, such as RichEdit ? That is what I did replacing TextFields with a non styled TextArea of the same size.

I am not even sure the redraw is indeed native. There is no mention of such a “feature” throughout Msdn, or the Internet. Actually I found some posts asking how to do that on SO.

What would happen if this kind of “by design” dysfunction was to happen under OS X ? I can only imagine the outrage. It is not fair.

15

Ha!

Guess what happens when I use an antiquated Real Basic 5.2 to do the same program ?

  • No textfield popping up
  • No Getfocus when the mouse passes over

What exact word should I use ? Give me a B, give me an S… Boiling Susan ?

Not only this is fixable, but it is an horrid regression that should have never happened !

16

Back then, a TextField and TextArea were the same Win32 control. They haven’t been for quite a while. If you want the same behavior as those older versions, you could just setup a single line TextArea- which I think you already mentioned. That’s what running in the old version is doing.

Now they’re different controls, what you’re seeing is likely a consequence of the TextField having mouse-over effects when run under newer Windows theme engines in a non-compositing window. Enabling Window compositing might be the way to ‘fix’ what Windows is doing to that control in your scenario, but it does break several things- including any projects that draw outside Paint events- so it’s something we have to work through carefully.

17

[quote=170153:@Travis Hill]Back then, a TextField and TextArea were the same Win32 control. They haven’t been for quite a while. If you want the same behavior as those older versions, you could just setup a single line TextArea- which I think you already mentioned. That’s what running in the old version is doing.

Now they’re different controls, what you’re seeing is likely a consequence of the TextField having mouse-over effects when run under newer Windows theme engines in a non-compositing window. Enabling Window compositing might be the way to ‘fix’ what Windows is doing to that control in your scenario, but it does break several things- including any projects that draw outside Paint events- so it’s something we have to work through carefully.[/quote]

You are right, looking closer at the older project there is some bevel on the frame of the field showing it is a TextArea.

I understand better from your explanation. I think we have two conflicting issues here : the legitimate concern for Xojo that turning on window compositing may break now deprecated for quite a while drawing outside of paint, versus concern from users expecting a control to remain at the zorder he fixed upon design. When I place a control at the back, I do not expect it to spring like a kangaroo and traverse all controls in front to punch the user.

So to preserve bad programming creates a very nasty bug for users who simply try to use Xojo by the book.

OK. Let us pity for those who keep very bad habits from a time long past, and nevertheless see what can be done for innocent Xojo users who should be able to expect controls to stay where they belong.

The single line, non styled TextArea works. It does not give the ellipse on the right margin if text overflow or the cue text, though. If this is the only solution for the moment, it would only seem fair to mention in the LR that TextFields must not be placed under other controls, otherwise use a TextArea.

I never wrote to a canvas or window graphics object outside of pain with Xojo anyway, and can’t even recall doing that in RB. I should not be punished because bad boys do otherwise. How do I turn on window compositing in my program ? I quickly looked in Msdn ; it seems to be mainly for graphics. I found no mention of it for a window. I also tried to turn on GDI+ but the textfield still behaves like a jack in the box. Is there a declare ?

If no declare, where do I find the information in MSDN ?

Thank you Travis.

18

If it is not possible to turn on Window compositing in Xojo, how can I change a control order at runtime, the way VB does it ?

Is there a declare possible/available ? Since VB has that in the language, I could not find any declare there. But it shows it is possible.

Since Xojo permits only setting the control order in the layering of the window at design time, my idea is to check the design order of the TextField in it’s open event, retain that value, and if it changes due to a mouse over, set it back in gotfocus.

19

Wouldn’t the solution be to cause the other controls to redraw? After all, layering in win32 is merely the effect of the order in which the controls are drawn, is it not? Z order is something imposed on controls by the drawing system, it isn’t anything inherent in the control itself.

20

Um, no. That is only because the textfield is the first control in tab order, so it gets focus when the window opens, not when the mouse passes over. Move the textfield to the end of the tab order and you will see that it does not get focus.