This happens when I maximize and then restore the test dialog:
(http://arqui3d.com/videobug.gif)
My hardware is:
Core 2 Duo E6300
Intel mainboard
2GB DDR2 RAM, 533MHz
nVidia GeForce 7300 GS with 256MB onboard and 256MB stolen from the system memory ("turbocache"), PCI Express. It's set at 1280x1024, via DVI-D.
And I use XP Pro SP2.
I've tried turning off all hardware acceleration in the video card settings, but still the same problem.
Thanks for that pic, that has been reported before but I can't see it on my system.
I'll modify the update algorithm to see if it helps.
The display algorithm of the new beta 5 release is different now.
Please have a look and let me know if this is better now or not.
Beta 5a Standard Edition, Vista.
This problem is not fixed on my system. It looks unchanged.
shit.
Same thing here. Uninstalled Beta 4, installed Beta 5a (By the way, I could not find Beta 5b), and still getting this:
(http://arqui3d.com/videobug2.gif)
Not only that, but now, when I maximize the test dialog, the buttons get a kinda odd "shadow":
(http://arqui3d.com/videobug3.gif)
But it's easy to kill this problem. Just switch to another app and come back to Stackz!.
I created a special version to check out a new potential solution to the issue.
Whoever has the described update problem on his system, please check out this version:
StzD07rc2+RedrawTest.zip (http://www.stackz.com/latest0705/StzD07rc2+RedrawTest.zip)
there is a test switch in the Options (Options -> Stackz Options, Tab "General Options") called "force full redraw of shaped arrow buttons". Does it help at all?
Nice try. You are very close:
After opening the program, the *first* time either "test" or "learn" is opened, it is fixed!
After that, it is exactly as before.
(I don't know if this is related, but since it is a dictionary version, my unlock key won't work for it.)
Quote from: querido on August 30, 2007, 02:01:10 AM
After opening the program, the *first* time either "test" or "learn" is opened, it is fixed!
After that, it is exactly as before.
According to your initial description I would have expected it to be always OK until the first maximize/minimize... please explain when the problem appears, what do you do? And does the checkbox "force full redraw of shaped arrow buttons" change anything?
These numbered items describe what I see, exactly.
At the end of this post are suggestions. Something there might stimulate an idea.
1. Click Stackz icon. "Evaluation period over" screen pops up. "Click "x" to continue". Click "x". Stackz comes up with no file open. (Under Options, the new option to redraw the buttons is remembered- it is checked.)
2. Click File. Choose a lesson file from the dropdown list. Lesson file opens.
3. Right click any lesson or box. Choose "Test" (or "Learn" or "Match").
4. Dialogue opens. Buttons are drawn correctly. (Edit: *THIS* is the exact point where your new switch makes a difference.)
5. If I resize the dialogue by dragging a border, everything in the dialogue, except the blue Windows titlebar, flashes very rapidly as they are redrawn, as long as I am dragging the border. (This flashing does not bother me at all, and I am not reporting it as a bug.) When I stop dragging the border, everything is drawn correctly. When I let go of the border, everything is still good.
6. Up to here, it looks fixed, with two exceptions:
(a). If the window of any other application is opened over the buttons, or is dragged over the buttons, the button background areas are not redrawn as the other window is removed, and are left messy or blank, as before.
(b). If I move the mouse pointer onto a button and then hold it still, until the popup tooltip appears, and then move the mouse pointer away, a white blank space is left where the tooltip was.
7. Close the dialogue.
8. Reopen the "Test" (or "Learn" or "Match") dialogue.
9. The button backgrounds are wrong. They are blank.
10. If I resize the dialogue by dragging a border, everything is again exactly as in steps 5 and 6.
I would be willing to make a video of this, if you could suggest free software that can do that. But I think it is unnecessary: I worked very hard to make the above points clear. It behaves exactly this way, every time.
[Begin my helpful guesswork:]
Please forgive me, but as I did before, I must speculate. I hope something I say will help you:
I see that the dialogue is "always on top" with respect to the main Stackz window. The main Stackz window never covers it, and so the dialogue does not have to be redrawn if the Stackz main window is moved.
But the dialogue is *not* "always on top" with respect to other applications.
**Maybe the button backgrounds are wrongly assuming that it is, and thus, don't know they need to redraw themselves.**
**Maybe your dialogue window knows that it is not on top, but it is *not telling* the button backgrounds, or they are not getting the message.** It is certainly not redrawing the button backgrounds as the other window is removed! The buttons are being redrawn, but not the button backgrounds! Your new switch in this bugfix version, to force the redrawing, also does not know that the other window passed over! Does this help? It MUST.
Because I am not an expert, I don't know what is responsible for (a) knowing that another window has passed over your dialogue window, and (b) ordering the redrawing of your dialogue window after these other windows pass over, and (c) performing the redrawing. Whether it is your dialogue window, your main window, or the Windows operating system. But I can tell you this for sure: every part of your dialogue window is getting this message, and being redrawn, except the button backgrounds.
I wrote some simple Windows programs, but it was decades ago, and advanced tools had not been developed, that I knew of. I didn't have "visual" tools. I wrote the program sections with a text editor, and couldn't see what it looked like until it was compiled and running. I had to ensure, myself, that the message-passing and inheritance issues that I have tried to describe, and which I can't remember very well, happened correctly. Do you still do this yourself, or is it automated? I wonder if your software development tools are entirely "visual", isolating you from these underlying issues, which I am sure are still happening behind the scenes. If so, you could have a bug in your tools, or in your graphics resources. Perhaps some "properties", or "ownership", switch on these buttons backgrounds is wrong.
[End my helpful guesswork.]
Stackz is the best flashcard program in the world.
Good luck.
Thanks for your detailed report!
By chance I ran into the problem myself you are describing: Some applications alter the color scheme of Windows Vista to "Windows Vista Basis" (german term, this is a color scheme without the glass effect) on my system, and in this mode I experience the button background refresh problem as well. Assuming that it's the same behavior, I could analyze the problem in detail.
These four things don't seem to go together:
1) The non-standard custom draw arrow button with transparent edges,
2) which is on top of a customized (shaded) background by the graphical library I'm using,
3) in a certain non-aero color scheme mode on windows vista,
4) all by trying to avoid unneeded redrawing to avoid flickering.
So after many attempts to fix it, I put up with abandoning the flickerfree resizing... Now I'm pretty confident that it will work in a robust way, but with slightly more flickering when resizing the learn/test/match dialogs because the buttons are redrawn in any case now.
Please check RC3 to see if it is really working.
I see blank white button backgrounds, always. Nothing else.
I tried different Windows color schemes, and different Stackz GUI themes.
To make them the same color as the surrounding panel would be perfect, but if you intend them to be white, it wouldn't bother me at all. A new user might not notice anything odd.
Blank!?! ??? How can that be...
I can't make it the "same color" because of the gradient of some styles - The background needs to be redrawn by the graphic library before the button gets drawn...
OK, I'll think about it more!
After I reported the above, the behavior changed:
When the dialogue pops up, the button backgrounds are transparent. By moving the dialogue around, then closing and reopening it, I now see that whatever is behind it, is showing through, including text, etc., when the dialogue pops up.
After that, they aren't transparent, but show the following behaviors:
1. If I drag the dialogue around by the titlebar, the backgrounds don't change, they move with the rest of the window.
2. if I drag a border, the backgrounds "smear" (become messy).
3. If I click the maximize button, the maximized dialogue has its button backgrounds drawn correctly.
And then it changed back. I don't know why:
Now it is a few minutes after I posted the above correction, and again it is popping up plain white. With the following behaviors:
1. If I maximize, they are drawn correctly.
2. With the dialogue maximized, if I open then close another window over the buttons, the backgrounds turn white.
3. With the dialogue at regular size, if I drag the titlebar or a border, the backgrounds remain white and don't smear.
My testing this for you is not working.
Don't you have a friend with Vista Home Basic who can look at this?
Please try RC4, I tried yet another approach there.
I'm a little nervous to report this, not wanting to be in error, but it appears to be
fixed!
fixed!
fixed!
On my system.
Congratulations!
Well Done!
Thanks for the feedback! Good to hear! ;D
The brute force approach that I used may cause a bit more of flickering, but smooth resizing is less critical than correct display.
Thanks for your fast reply and your reliable cooperation!