I thought it was supposed to be when the system is busy, but that's not what I'm seeing.
I have an application which (*almost) always shows the blue spinning wheel when the cursor is over the GUI. But everything seems to function correctly (the GUI is responsive, and other threads seem to be progressing just fine) and looking at CPU use, nothing seems obviously stalled.
So what is the actually state of affairs that triggers the displau of the spinning blue circle?
And does anybody have any suggestions as to how I can find out where the problem is in my code?
the "almost" is because confusingly, just now when I was looking to see if visual studio's cpu profiling could give me any clues and changing settings I ran it and didn't get the blue circle... but then ran it again with no changes and the blue circle was back.
The spinning circle is the busy cursor. Applications can set or unset it for whatever reason they want. In fact, the busy cursor indicates simply that some work is in progress, it doesn't necessarily mean that the application has frozen (although frozen apps do show a busy cursor, too).
This is how you set it:
SetCursor(hHourglass);
DoBusyThing();
SetCursor(hRegular);
See this answer for more information:
https://stackoverflow.com/a/3178525/492336
By the way, the spinning circle in Win7 is actually the hourglass cursor from WinXP and older versions. It's exactly the same cursor, they just changed how it looks.
Related
I started a new job a few weeks ago.
In my previous job, I was working with 2 screens. I know have 3 screens here (what an upgrade!)
I have always been bothered by a small bug, and since today I don't have a lot of code to do, I decided to finally try to solve this problem. The layout I want to achieve is pretty simple (see screenshots below): One file on the left screen, and another one on the right.
What happens is the following:
When I enter debug mode, the layout stays the same except one thing... the separation between two files (which is usually right between the two screens). Annoying for breakpoints and stuff, so I resize it, debug, and...
When I leave debug mode and go back to debug, the layout go back to what it was... except the separation which moved as well!
And last but not least, if I close Visual Studio and open it again, my two file views are now expanded on both screens, separated horizontally (<- this one is new, I had never seen that before).
Every time I go to debug mode, or go back to design, I would resize it to fit my two screens. And then it would shift again at the next debug. After some time it shifts with a smaller amount of pixels. Then, it just stops shifting, as if it learned that it shouldn't change. Until at some point, it goes back to normal and forces me to resize again.
I tried to use add-ons such as Perspectives or Layout O Rama , but they didn't keep any information about the two Code windows. No matter how I was saving them (let's say, one would be 20% of the left screen, and the other would expand on 2 screens), it would ANYWAY go back to the strange, shifted layout.
I also tried Visual Studio Productivity Power Tool and it's terrible. If I dock a code tab as a Window on my second screen, and dock for example the Find Results on it, it would be separated or reorganized every time I switch to Debug/Design
Has anyone experienced that yet? Am I the only one feeling that my Visual Studio is a pet who will learn how to do his own layout as time goes?
Thank you!
Also, as an image is always better than a description, here are a few screenshots:
Here, the normal, regular layout, with the red line being where my screens stop. Perfect, al dente layout allowing me to use the best of my two screens
Here, the one happening every time I go to debug. Notice how ONLY the code windows shifted (the bottom part with error list on the left and find results on the right didn't change at all )
And this is the one I get when I restart my IDE, forcing me to recreate my layout all the time
Thanks a lot!
I am trying to implement frame independent movement in SFML, but am having trouble getting it to work. When I had this problem earlier with SDL, I found somewhere that Windows pauses the main thread of an application whenever it is moved (by dragging the title-bar). The problem comes because when the window is being dragged, the clock updates but the movement is not drawn until I let go of the window. When I move the window, the window is no longer being drawn to, but the time is still increasing. Thus, when I let go of the window, the units immediately jump to where they would be if the window had not been dragged.
I tried thinking of a solution, and since Windows only pauses the main thread, I considered just running the entire game in a separate thread, and launching it in main() but that does not appear to work as the same result occurs. I also thought about the extremely low FPS's I get as a result, but I would have no way of being able to differentiate between someone dragging the window and if their game is just naturally running slowly... There has to be a way to either prevent windows from pausing the main thread, or doing something that prevents this issue, but I haven't found any sort of solution on the internet...
Here is a link to a zip file which demonstrates the problem. Both Demo0 and Demo1 are the same, except Demo1 uses a second thread to run the program, yet the same effect occurs. Just run both and watch as the delta value is output to command line. Then drag the window and move it to some other part of the screen. When you let go, you should see a very large delta value and the circle should jump ahead depending on how long you had the window suspended. The source code is all there (in the "src" folder), so I hope people can understand the exact problem: http://www.sendspace.com/file/4er8f4
I see two solutions to the problem:
You can try to see if the sf::Events LostFocus or Resized picks up a window drag, and if they do, simply pause the clock on the game. More information can be found here: http://www.sfml-dev.org/tutorials/2.0/window-events.php
However, if that doesn't work, I would simply add an upper-cap on your delta. Meaning, if the game goes above a certain threshold of delta (1/60 or 1/30), you set delta to a lower value. In your situation though, this cap could probably be really big, like 1/15.
if(delta > 1/15.0f)
delta = 1/15.0f;
Chances are you don't expect your game to be playable at 15fps anyways, and if the user drags the window while moving, the worst you'll have to deal with is a 15fps delta on resume.
I develop audio plugins, which are run inside their hosts and work realtime. Each plugin has its own window with controls, which often contains some kind of analysis pane, a pretty big rectangle that gets repeatedly painted (e.g. 20-50x per second). This is all working well.
The trouble comes when the user adjusts a parameter - the plugin uses WM_MOUSEMOVE to track mouse movements and on each change calls ::InvalidateRect to make the relevant portion of the window be redrawn. If you move quickly enough, the window really gets quickly repainted, however there seems no time for the host and other windows to be redrawn and these usually perform some kind of analysis feedback too, so it is really not ideal.
No my questions:
1) Assuming the host and other window are using ::InvalidateRect too, why mine is prioritized?
2) How to make ::InvalidateRect not prioritized, meaning the window needs to be invalidated, but it may be later, the rest of the system must get time for their redrawing too.
Thanks in advance!
We have a fairly complex GUI, so when certain windows are resized their Redraw() is set to false till the operation is completed. The problem with this is that if the OS "Show window content while dragging" setting is checked, when decreasing the window's size the windows behind it are not repainted. This means I have to force the repaint myself so the remains of the resized window are deleted. I have no problem getting the dimensions of the region that was uncovered. What I'm looking for is best way to cause all windows within that region to repaint their part.
Not being much of a GUI programmer, I can traverse the uncovered region and list the windows in it. Then, I can ask each one of them to repaint its part. But I'm quite certain there has to be a better way to do this...
It is worth mentioning the app is written in PowerBuilder. This means I can call whatever Win32 function I'd like, but have limited control over the GUI behavior and the message handling. If there's a better way to prevent the window's content resize from being visible, or there's a way to make a non-redrawn window clean after itself, I'd love to hear it (just have the limitations above in mind).
I'm curious what version of PowerBuilder you are working in? I do resizing all the time and never run into issues like you are describing.
Maybe you can lay out some more detail on why you need to set your redraws to false within the PowerBuilder environment.
Hope I can help.
I'm creating a ToolTip window and adding tools to it using the flags
TTF_IDISHWND | TTF_SUBCLASS. (c++, win32)
I have a manifest file such that my program uses the new WindowsXP themes
(comctrl32 version 6).
When I hover over a registered tool, the tip appears.
Good.
When I click the mouse, the tip disappears.
Ok.
However, moving away from the tool and back
again does not make the tip re-appear. I need to hover over a different tool
and then come back to my tool to get the tip to come back.
When I remove my manifest file (to use the older non-XP comctrl32), the
problem goes away.
After doing some experimentation, I discovered the following differences
between ToolTips in Comctl32 version 5 (old) and Comctl32 version 6 (new):
New TTF_TRANSPARENT ToolTips (when used In-Place) actually return
HTCLIENT from WM_NCITTEST if a mouse button is down, thus getting
WM_LBUTTONDOWN and stealing focus for a moment before vanishing. This causes
the application's border to flash.
Old TTF_TRANSPARENT ToolTips always return HTTRANSPARENT from WM_NCHITTEST,
and thus never get WM_LBUTTONDOWN themselves and never steal focus. (This seems to be just aesthetic, but may impact the next point...)
New ToolTips seem not to get WM_TIMER events after a mouse-click, and
only resume getting (a bunch of) timer events after being de-activated and
re-activated. Thus, they do not re-display their tip window after a mouse
click and release.
Old ToolTips get a WM_TIMER message as soon as the mouse is moved again
after click/release, so they are ready to re-display their tip.
Thus, as a comctl32 workaround, I had to:
subclass the TOOLTIPS_CLASS window and always return HTTRANSPARENT from
WM_NCHITTEST if the tool asked for transparency.
avoid using TTF_SUBCLASS and rather process the mouse messages myself so
I could de-activate/re-activate upon receiving WM_xBUTTONUP.
I assume that the change in internal behavior was to accommodate the new "clickable" features in ToolTips like hyperlinks, but the hover behavior appears to be thus broken.
Does anyone know of a better solution than my subclass workaround? Am I missing some other point?
You're not the only one who has hit compatablity issues with tooltips between these DLLS.
I too have had nothing but trouble with the new tooltips in the themable common controls. We have already been monkeying with mouse messages and active/deactivating the tips before adding the manifest and theming our application - so it sounds like what your doing isn't too crazy.
We're still living with problems with TTN_NEEDTEXT messages being send constantly as the mouse moves (not just when hovering), positioning problems with large tips (maybe not something new), and odd unicode messages being sent instead of the ANSI versions (which I plan to post as a question at some point).
I don't know, but this sounds like a really "hard" problem (in the sense that all real-world) problems are really hard. I bet the underlying problem is something to do with the setting of the focus. Windows that manually do that are evil and generally suffer from all manner of bugs.