Messages

[Congratulations!]

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!

[After I reported the above, the behavior changed:]

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?

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.

Yes, that's it.
It is very carefully worded. I appreciate that.

Summary: I've switched to Stackz Classic mode.

It is now 30AUG07, and I am still using Stackz. Because it is so flexible, I've been able to move the piles around, and change the way I worked with it in various ways, and the way I subdivide the cards, etc. It has been well-behaved, and has worked for me.

I came to the forum today to look for a post I thought I had seen, written by the program author, I think, which was a very clearly worded explanation of the reasoning behind his Stackz Classic promotion system. I can't find that post. I wanted to tell him, and anybody reading this, about my thoughts on that subject.
In the beginning, I learned about the Leitner system, and it seemed smart to me. And it is, in fact. But having immersed myself in some websites of some of the other flashcard programs, I was excessively engrossed in this system, and the scheduling algorithm issue, etc. So, at first, I dismissed the Stackz Classic mode. But I want to tell you that as a result of that clear explanation by the author, and as a result of my own experience with this program, I was very slowly converted to preferring the Stackz Classic mode. I'm also surprised by this: I have very gradually realized that I don't need more than five boxes for any of the subsets of cards that I keep. This is my opinion: if one card needs reviewing tomorrow, and another card need not be seen for a month or more, then these cards *should* be kept in different logical categories (different lesson files). I *want* them to be separated, not floating around together somewhere in a system having an unlimited number of boxes. When I first started using Stackz, I worked on setting up a complicated system that, in effect, concatenated lessons into a string 5*X boxes long. But now, I have it set up to operate just as it was designed, and it is just right for me.

Stackz preserves a convincing "feel" of real, physical, flashcards, while automating all of the recordkeeping. Those other systems seem to hold your cards out in the aether somewhere, and feel very distant to me. I zealously hoard my hanzi, every one of them. And I want to see and "touch" and test on any pile of them I feel like, at any time. I also enjoy violating the "system", zipping through the cards I already know that I know, as a break from the harder ones. I understand and accept the principle of progressively spaced testing, but I am a free man, after all.

[new switch]

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.

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.)

I agree with everything that Arqui3D just posted.

Here is *exactly* what it is doing now:
I can see the colorbar is being updated immediately now. OK.
I can see the slider is moving with the updated colorbar. OK.
BUT:
1. that next color down is still being uncrosshatched in the stacks
2. the status bar is counting these newly uncrosshatched cards, as before.

3. If I now click on, and begin to move, the slider, the above errors get *CORRECTED*!  Then everything is right.

Beta 5a Standard Edition, Vista.
This problem is not fixed on my system. It looks unchanged.

I think I made a mistake.
When you said "fixed in the next release", did you mean Beta 5a?
In Beta 5a, on my system, it is not fixed.

Great! Good work!
I think you can count another bug I reported "very minor coloring error", on 01 June, as fixed by this.

I sent you an email with screenshots.

This bug happens every time. (I close without saving to preserve the conditions).

CONDITIONS
Beta 4 Standard Edition, Vista.
Promotion System: either
ColorMode: Repeat Advisor (schedule 1,2,3,4,5)
Sorted stacks: doesn't matter
One .szm file open with one lesson. 147 cards. Every box has some cards.
Box 5 contains:
1 card, test state 5 days (due).
1 card, test state 4 days.
18 cards, test state 3 days.
12 cards, test state 2 days.

ACTIONS TAKEN
Highlight box 5:
Status bar says "32 selected, 32 included". OK.
Move right-hand slider to the right side of the "0 days reserve" color band:
Only cards of 0 days reserve color are left uncrosshatched. OK.
(If the left-hand slider is placed now at the left side of this colorband, the same errors below occur.)
Status bar says "32 selected, 1 included". OK.
Test box 5. Mark one card learned. Test dialogue closes. OK.

ERRORS
Right *here*, something needs to be updated, because the following situation is confusing:
1. Status bar now says "32 selected, 1 included".
2. Box 5 shows one card uncrosshatched. (The one card with test state 4 days, which should still be excluded.)
3. Other boxes now show two colors uncrosshatched: the "0 days remaining" color, and the "1 day remaining", slightly different color.
4. If I click on, and begin to move, the *left-hand* slider on the colorbar, here is what happens: while the *right-hand* slider does not move, the color-bands are updated under it, so that both the "0 day reserve" and the "1 day reserve" color bands are now to its *left*. 

(The previous day, I was testing on a .szm file with longer intervals, and therefore smaller color differences. After I finished testing, and the Test dialogue closed, I saw the status bar and the coloring telling me that more cards were due. I started testing again, and noticed that the cards were not due.)

Beta 4, Standard Edition, Vista.
Options...File...LearnDialogue

"Maximum Local Stack Elements" always returns to "10" after the lesson file is closed and reopened.

Local Stack Test Size: doesn't matter
Skill: doesn't matter.