I have ListView which items are completely drawn using my code. Of course I use data provided by NMLVCUSTOMDRAW primarily RECTs. There are two rects p->nmcd.rc and p->rcText, first one carries valid information and the other one is always 0. This issue is that nmcd.rc does not contain valid rect on Windows XP I get 0,1,0,2 or something like that.
As that did not work I tried using ListView_GetItemIndexRect which fails on Win XP, while it works on Win 7/10.
Looking at the ListView_GetItemIndexRect's msdn page I can see that apparently it works only on Vista+. While at the same time some other ListView functions that are listed as Vista+ work fine on Windows XP.
Windows XP is rare among my program's users, but still I'd like it to function perfectly. Drawing complete list view on my own would fix the problem for sure, but that is a dead end.
Check out the first comment on this page:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb774778%28v=vs.85%29.aspx
Handling subitem pre-paint messages on Windows XP (perhaps all
pre-Vista systems?) the handler receives incorrect top and bottom
values in NMLVCUSTOMDRAW::nmcd.rc, sometimes they are zero, sometimes
are not updated since previous handler call (so basically the idea is
that they are left uninitialized by comctl32 caller). In order to get
correct subitem position the handler has to explicitly obtain
rectangle using a separate message/call:
RECT Position; ListView.GetSubItemRect((INT) pHeader->nmcd.dwItemSpec,
pHeader->iSubItem, LVIR_BOUNDS, &Position);
Related
I found a bug yesterday in one of my Windows applications, which is built in a high level framework, which in the end, calls Windows APIs like CreateWindow, and ShowWindow, in order to display its user interface.
One one machine so far, and only one, which happened to be a customer machine, I observed the following behaviour:
For only one window in my entire application, when I first call ShowWindow(Handle,SW_SHOW ) for this window, the size which it previously had received by SetWindowPos is overridden.
Reading the MSDN Win32 API documentation, on ShowWindow(Handle,SW_SHOW) I can not see any reference it it moving the window bounds. I can work around this surprising result by having my window-show routine get the bounds before it calls the Win32 ShowWindow routine.
My question is, has anyone ever seen behaviour like this? I think it must be one of the following:
An obscure bug in Windows 7 Service Pack 1 that does not reproduce on all systems, and only reproduces perhaps for a particular version of a particular video card driver. (This affected system has dual AMD/ATI FireGL video cards)
An obscure problem caused by a side effect of some other software running on the system, which may be hooking window handles, installing trampolined code hooks somewhere (perhaps even inside my own process, thanks to some DLL or something that I am not aware of).
Something my 4 million line application is doing to me, through some weird code somewhere I have not yet identified.
I am hitting an application compatibility shim within the Win32 API layer.
If anyone who has worked in C++, C, or Delphi, or any other language, has ever seen anything like this and can think of a reason why ShowWindow would have this amazing and unexpected side effect, of moving the bounds of the window, back to a certain original position, in my case, x=175, y=175, width=320, height=240, which appears to be have been the window bounds right after the initial CreateWindow call, I'd like to know what it is.
Here is a sequence of events:
Application starts up, and creates a few top level windows parented to the desktop.
The first window created is the main application window and the second is a tool window, both have full window grabber bars and are conventional top level Win32 windows, Forms which are sizeable, draggable, and parented to the desktop.
The second window's position is loaded from disk, and the form is shown.
During the form show process, its bounds are set so that the window is at some x and y top/left position, and some height/width is given.
If I query the Win32 window handle immediately before I call ShowWindow, its bounds are where I expect.
If I query the Win32 window handle immediately after I call ShowWindow, its bounds have been reset.
According to MSDN help SW_SHOW means Activates the window and displays it in its current size and position.
This is indeed what occurs on over 100 client PCs I have observed. Only on a single customer-owned Windows 7 PC is this behaviour different.
This affected system has dual AMD/ATI FireGL video cards
I ain't sure about FireGL, but for consumers videocards, made upon the same chip lineage, video-drivers exactly have add-on to reposition windows as they think is easier for operator.
it is called HydraVision Package for Catalyst Software Suite
I know Tkinter can be an exercise in frustration at times, but I am stumped on the "correct" sequence of calls to a Tkinter/ttk Toplevel widget/window that will:
Display the window in the center of the screen WITHOUT drawing it off-center and THEN moving it.
Size the window properly.
Make the window toplevel to the parent form, but not system modal (that is, not toplevel to ALL apps/windows on the system).
Optionally create a taskbar button on Windows.
This is the current code that I have so far, with some unrelated bits removed for simplicity's sake:
def __init_ui__(self):
#// Basic setup.
self.wm_overrideredirect(False)
self.wm_resizable(False, False)
self.configure(relief=FLAT, borderwidth=4)
#// <Some extraneous widget-creation here>
#// Done!
self.update()
self.withdraw()
self.update_idletasks()
self.grid()
self.transient(self._parent)
self.grab_set()
self.form.initial_focus() #// sets initial focus before the window is displayed
center(self) #// https://stackoverflow.com/a/10018670
self.deiconify()
self._parent._parent.wait_window(self) #// Reaches back to the root Tk() obj.
# ENDIF
# END __init_ui__
This form inherits from a custom class I created that wraps a bunch of widget-creation calls, and the class inherits down from object. A second inheritance comes from ttk.Toplevel, to give it access to the various self.wm_* calls and other Tkinter goodies.
That said, I am certain some of my function calls are unneeded. But this particular call order seems to mostly work well on Windows 7. Under X11-over-ssh (using Xming for the X server in Windows), however, things get a bit weirder. In that case, if I move self.update() to be after self.withdraw(), then the window is centered correctly w/o redraw on Windows 7, but on X11, it is drawn and properly centered whilst hidden, but has ZERO geometry (only the compressed window border/decorations are shown). It's as-if grid propagation didn't fire or such.
But where self.update() is right now, it properly sizes and centers the window on both windows and X11 - but you can see the window getting created off-center THEN moved to center on both.
If I use self.wm_attributes("-toolwindow", 1) on Windows, then the windows gets centered without me seeing it, but -toolwindow only works on Windows system. It's an invalid command to both X11 and Aqua.
I'd like to avoid calls to tk::windowingsystem all the time to determine what my window manager is and having to apply different hacks for Windows and X11. And I can't test Mac/Aqua (don't own one, not going to buy), so I'll just have to hope the end look is somewhat functional on that platform.
Additionally, if I click away to another window/app under both Windows and remote X11, clicking back on the main form via the taskbar button only displays the main form -- the child Toplevel window only pops back up when you click anywhere inside the main form. Fixed: (kinda) -- I forgot that adding an argument to self._transient() kinda fixed that by specifying the parent. Earlier tonight, I didn't pass the parent argument in, thus the focusing wasn't right.
So is there some kind of tried-and-true magik recipe or invocation to the Priests of Ancient Mu to get a Tkinter/ttk Toplevel window to size, center, and properly get focus if it's not the root window? Using minimal X11, Motif-look, btw.
And no, I am not using PyGTK, PyQT, wxPython, or some other toolkit. It's standard Tkinter/ttk or bust, since that's what I've spent the last few weeks learning and writing wrapper functions for. The autocomplete combobox I worked up is a cute little contraption. Still slightly buggy, but that's a topic for another SO question...
PS, The Tkinter cookbook on Effbot is down. Looks like a server crash. Did anyone happen to mirror that site by chance?
Solved! Had to tweak the order of the calls a little bit:
#// Done!
self.withdraw()
self.grid()
self.transient(self._parent)
self.grab_set()
self.form.initial_focus()
center(self)
self.deiconify()
self._parent._parent.wait_window(self)
But the real fix was in the center() function I lifted from this answer, by changing the calls to winfo_width()/winfo_height() to winfo_reqwidth()/winfo_reqheight() and adding a call to update() as the first call in center(). Now I get my dialog windows to pop up in the center without seeing them move, focus is applied correctly, and it works on both Windows and remote X11. Maybe one day, I'll find out how well it works on Mac OS X/Aqua.
I wanna ask if someone can provide me a c++ code in which I can hide/show the pointer of the mouse when pressing a specific key..
I found several codes written for only TURBO C++, none of which can be compiled and run using dev c++ or even visual c++..
I tried running the codes I found in Dev C++ but I only get lots of errors and incompatibilities..
I also found several articles that says I can use the function ShowCursor but it just wouldn't work..
In fact hiding the cursor can turn out to be quite a task, depending on what you want to achive. If you're programming a GUI-application using the WinAPI it is pretty easy.
Just calling ShowCursor(false); once might turn out not to work in some cases though, since the ShowCursor function only "sets an internal display counter". The cursor is displayed until this counter is smaller than 0 (see msdn on it). You could try something like this:
while(ShowCursor(false)>=0);
to ensure the counter gets below 0.
This will however only hide the cursor inside your applications window, if you're using newer Windows versions like Windows 7. Hiding the cursor all over the system could turn out to be a lot more difficult.
If you are programming a console application ShowCursor won't show any effect as far as I've tested it. Using the following code:
while(ShowCursor(false)>=0);
std::cout<<ShowCursor(false)<<std::endl;
std::cout<<ShowCursor(true)<<std::endl;
we can see, that the counter definitely is below 0, but still the cursor is displayed. I haven't come up with a solution to this so far.
If you look at the documentation for the SetCursor function, setting the cursor to a NULL handle (e.g SetCursor(NULL)) will remove the cursor from the screen.
I have a strange issue I've been unable to diagnose and am hoping someone can at least point me in the right direction. I have a C++ MFC application that collects data from various sources and displays it on the screen. After a random interval (typically around 5-10 minutes), however, the display gets "corrupted" in a way I've never seen or have been able to track down as shown in the image below (left is normal, right is corrupt):
The basic symptoms are:
Up/down arrow images turn into "5"s and "6"s.
Opening a combo box list results in just the item text displayed (list border and scroll bar is not shown).
Background colours on some controls don't update or display correctly.
Z-order is broken and the app controls "leak" through other windows placed on top.
Pressing Print-Screen with the app in focus no longer captures the window to the clipboard.
Closing and reopening the window does nothing.
Restarting the application gets things back to normal.
Things I've tried to eliminate as a possible cause include:
Operating System & Computer: The same issue is present on a variety of systems from Windows 7-64 bit to Windows Xp-32 bit.
Multi-threading: I added a mutex to prevent the display updates from occurring at the same time but it had no effect (as expected).
Memory Corruption: This has been my assumption all along but there are no signs of memory corruption at all. The base display code has been used for years with no similar issue as well as the base networking message library.
Specific Code: I have narrowed down the issue to one specific dialog among a variety of others that show no issue. They all use the same base code which would seem to indicate the issue lies in the specific display code for the dialog. Exactly how or why the issue occurs has eluded me so far.
Any ideas on what the cause might be or how to narrow it down would be great.
Update 1:
Doing some more timing/repeatable tests and it looks like leaving this one dialog running for a short while causes the issue. The amount time is consistently between 300-400 seconds before the issue shows up.
It sounds like your application could be leaking GDI objects. To check if that is the case, open your task manager and enable the GDI Objects column. Observe the number for your process and see if it's increasing continuously.
If that is actually the case, you should read Detect and Plug GDI Leaks in Your Code with Two Powerful Tools for Windows XP. That MSDN article also offers a tool named GDILeaks.exe that should help you identify your GDI Leaks.
In the case where these symptoms surface within a short time, it should be something that is drawn repeatedly that isn't freeing GDI resources properly. Possibly in (or called within) the windows procedure (OnPaint for example).
If I'm not mistaken Windows' GUI uses a ttf(?) font for those little icons, and it looks like the font gets destroyed somehow (DeleteObject being called with font's handle?)
I am writing a virtual desktop application which utilises the DeferWindowPos API functions. The current method I am using is moving the windows off the screen if they're not on the current virtual desktop. However I know wish to also hide the windows that are off-screen so they do not appear on the task bar. I have attempted this by also passing SWP_SHOWWINDOW/SWP_HIDEWINDOW to the DeferWindowPos() calls. I have read a few sites regarding this and one of them suggested that if SWP_SHOWWINDOW/SWP_HIDEWINDOW are passed, then the window will only show or hide, and no reposition. Can anyone confirm this, or am I doing something wrong?
In addition to the rtfm, DeferWindowPos is eventually going to call SetWindowPos. SetWindowPos always validates its parameters by passing them to the WindowProc via WM_WINDOWPOSCHANGING so, unless you are also hooking every windows WindowProc as part of your virtual desktop manager, moving them off screen is going to fail for any windows where the devs are doing something "clever" or unusual - like clamping to the edge of the workspace.
You need to read the documentation, which clearly states
If any of the windows in the multiple-window- position structure have the SWP_HIDEWINDOW or SWP_SHOWWINDOW flag set, none of the windows are repositioned.
I, too, noticed this statement in the documentation:
If any of the windows in the multiple-window- position structure have the SWP_HIDEWINDOW or SWP_SHOWWINDOW flag set, none of the windows are repositioned.
...after I'd already rewritten some code to use DWP, so I thought I'd try running it. It worked just fine even though I'd used either SWP_SHOWWINDOW or SWP_HIDEWINDOW for every single call to DWP.
This was on Windows 7 64-bit, so YMMV.