Simple Games - Research and Development

[jj2007]

using GetDc to fill the selected cells RECT with another color, then ReleaseDC in the left button message handler

GetDc might sometimes work, but it's not the official way. You must react to a WM_PAINT or to a WM_DRAWITEM message.

[zedd151]

...You must react to a WM_PAINT or to a WM_DRAWITEM message.

Nah, I'll skip all of that. There's 4 flags to to compare, plus other determining factors so the WM_PAINT would indeed be a little messy to tangle with. I'll stick to the static+bitmap approach...   
But thanks for the suggestion.

[jj2007]

Launch your program. Then take another window (Notepad, whatever) and move it over your window. Observe what happens. This is the problem with GetDC

[zedd151]

This is the problem with GetDC

Yes I know theres problems with that code.  So, Ill be skipping the whole WM_PAINT & company for this project, maybe in another project. WM_PAINT is handled internally using the static control+bitmap method, via STM_SETIMAGE.

[zedd151]

I just had a brrrrrrilliant(trill the r's here) idea.
Remember the way I outsourced some of the painting functions in the DrawBitmap procedure?  I wonder if I could do similar with drawing text that way... Well not exactly outsourcing but splitting up the code and use a procedure to do the heavy lifting. There, a loop with several flag compares would be much better than trashing up WM_PAINT and making hundreds of lines of code in the WM_PAINT message handler. Well maybe a couple dozen lines.  Sounds like another experimental project, when time permits.

[jj2007]

You refuse to accept how Windows works

[zedd151]

You refuse to accept how Windows works  

Yes! It must bend to my will.   
No not really of curse, I just stick with what works for me. And if by some happy accident it works for others as well, then it's a win-win. 

[NoCforMe]

Let me add my 2¢ here, and please keep in mind that we're just trying to be helpful:

Use the WM_PAINT handler to do all your painting and drawing where practical.

It'll save you a lot of grief in the long run. Sure, you can set up code with bunches of flags and stuff, but in the end you're going to get screwed when, as JJ pointed out, someone rudely moves another window over yours and voila! big blank spots.

(I almost put in that stupid line about how the speed of light isn't just a good idea--it's the law!, but of course it ain't no law that you have to put your painting and drawing in your paint routine. But it really is the way Windoze is designed to work. Better not to fight it, I've discovered ...)

Hint: global variables are your friend here.

[zedd151]

Thank you for your input, I'll take it into consideration.

[NoCforMe]

I think you'll find it worthwhile.

The other place to do drawing and painting would be in response to WM_DRAWITEM messages. In both cases you're letting Windows tell you when something needs painted; it knows better than we do, so let it do its job.

And of course to force something to paint itself you can use InvalidateRect().

[zedd151]

In my sudoku project, I have decided to dynamically resize the window so that the client area of the main window is just large enough to properly display the game and associated controls. This program originally had a menu set into the main window. However using GetClientRect apparently does not take the menu height into account. I could take a screenshot to see how many pixels high the menu is, but that is not desirable. So I just removed the menu until a solution is found. I know that the task bar is different for different OS's and I'm thinking that the menu heights may be different as well. I haven't cracked open windows 10 to find out. I don't keep it on my hard drive, just use it on an as-needed basis. So, does anyone know if the menu height is the same for 8, 10, 11 as in Windows 7? Not a game-stopper either way. If I need options there are always normal push buttons I can add for that. 

[NoCforMe]

Hint #2: SystemParametersInfo() is your friend.

[zedd151]

Okay, I have rewritten some portions of the code, and removed others. I have all the static controls in place, For both the cells and the candidates. The game doesn't look like much, but there is a ton of stuff done under the hood.
When the game opens, the display that you see are the candidates 1-9 in each cell as there is no game loaded just yet. I left it at this stage after verifying all the necessary controls are placed properly. Used numerous loops to insert the total 892 static controls  .
81 for the main 'cells', 81 for the candidate 'frames', 729 for the candidates, and 1 for the grid background. Bitmap loading was also done via a loop (only 51 bitmaps).

Will add more code incrementally, the next version will have all of the controls in it. But still no game loaded just yet.

Hint #2: SystemParametersInfo() is your friend.

I looked through that, the menu info there seems to be about popup menus not window menu.

[NoCforMe]

Wellll, I don't know about you, but I would use text instead of bitmaps to draw all that stuff. And instead of having so many different static controls, just divide your main sudoku cells into virtual compartments (what is it, 9 per cell?) by just computing where to put the text. I think that would be a whole lot simpler.

Of course, you've gone in a different direction, so maybe not so easy to change. But if you get frustrated with the current scheme you might want to reconsider text. After all, all you're putting in there is ... text.

[NoCforMe]

My bad. I should have said to look at GetSystemMetrics(), which gives the sizes of things.

Of course, even that may not work correctly, because themes.