Hello,
I have a PopupContainerEdit, and during debugging I've noticed that the QueryDisplayText event is raised hundred times without even touching the form where the control sits.
Is it a bug, or if not, what if someone had to do a more serious operaton to calculate the displaytext? Then it could hit the performance for nothing I think.
Thank you,
Zoltan
Bug Report
B196390
Visible to All Users
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hi László,
This event is raised when an editor is repainted to get the display text from value. If you simply set the breakpoint inside it, it will constantly stop there for sure, because it tries to repaint it when the form with the control appears, but is interrupted by the Visual Studio debugger. So, it tries again and again. When it works without being interrupted by a breakpoint, this event is raised only when it needed to repaint the text in the control.
Thanks,
Ted
Hello Ted,
thank you for the answer, but unfortunately if it were such simple of course I wouldn't mind it.
I didn't mean debugging with breakpoints, but with placing a Debug.WriteLine in the eventhandler.
I attached a sample project to demonstrate a behaviour. There is a LayoutControl on the form, which contains a PopupContainerEdit, which is even not visible because of grouping. As you can see (or at least on my computer) the event is raised exactly 12 times on form opening, before anyone could notice that there is a PopupContainerEdit. After, when I select the particular tabpage, and play with the mouse arrow above it, it's visible that the event is raised streamly…
Thanks,
Zoltan
Hi László,
Yes, this behavior is also reproduced on my side. However, this is the process of initialization when the editor's ViewInfo is initialized, and a lot of parameters are calculated. I don't think that there are unnecessary calls to this event. After the editor is initialized, this event is only raised only when required. As for the repainting when you move the mouse cursor over the editor, after you move the mouse, the editor is repainted, so it requires a display text and thus raises this event. So, it seems to me that all works fine.
Thanks,
Ted
Hi Ted,
could you tell me why it is necessary to redraw the editor on mouse action, in the case when there are no eventhandlers attached to mouse over or other mouse move related events?
Thanks,
Zoltan
Hi László,
It needs to redraw the editor when the mouse moves over it, because the system draws a mouse pointer. If it does not redraw the editor every time the mouse moves, the editor will simply be erased by the mouse cursor. This is the way all of Windows works. Hence, when the editor draws itself, it should get the display text, and eventually call this event.
Thanks,
Ted