Jump to content
  • Advertisement
Sign in to follow this  

Bug in Win32 gui shell code?

This topic is 4396 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is it true that putting standard windows controls like edit boxes and labels into non-dialog box windows is not recommended? I'm getting bugs like edit boxes losing the ability to receive input by users and labels not being drawn properly when I create these controls inside child windows and run the program in release mode outside the debugger. I think I read this in one of the MSDN articles, but I'm not sure, that you're only supposed to put controls into dialog boxes. I'll post some pictures. http://i14.photobucket.com/albums/a350/luisjoseromero/Releasemodeinsidedebugger.jpg http://i14.photobucket.com/albums/a350/luisjoseromero/Releasemodeoutsidedebugger.jpg One is from Release mode inside the debugger and another in Release mode OUTSIDE the debugger. The one that is run outside the debugger is the one that's causing trouble. This has caused me a great deal of embarassment when I've shown the program at work as people are unable to input data into the edit boxes. Oh, and what's worse, It behaves differently on every machine. How can I guarantee that controls in regular child windows won't go berzerk like this?

Share this post


Link to post
Share on other sites
Advertisement
Journey,

I've never heard of the problem you're describing, but as for only putting controls on dialogs, that's not true. Most applications are made entirely of controls, ie. office, excel, visual studio, etc...

In fact, .NET doesnt even differentiate between dialogs and forms, beyond whether its modal or not, and its just a wrapper which responds to the same windows events as the Win32 API or MFC.

I'd recommend looking closer at the misbehaviors you're seeing and trying to diagnose it. What framework are you using? In either event, putting controls on the "windows" shouldn't cause problems.

Cheers and good luck!

Share this post


Link to post
Share on other sites
You need to look at your event handling, this normally happens when a control is recieving an event, not responding to it and NOT passing it on.

theTroll

Share this post


Link to post
Share on other sites
I just heard a guy say that you can't just position controls willy nilly inside non dialog windows. He said something about aligning the controls according to font sizes and such. As for diagnosing the problem, I've gotten to the point where there's some sort of "magical" alignment of controls that runs fine and text is not obscured and edit boxes receive input normally. But the moment I run it on a different computer the bug shows up again! It's a real shame since I can't debug the program on that particular computer.

Share this post


Link to post
Share on other sites
well, the worst part is that when the bug shows up I even stop receiving input messages on the affected edit boxes. I even tracked it with Spy++

Share this post


Link to post
Share on other sites
Quote:
Original post by Journey
I just heard a guy say that you can't just position controls willy nilly inside non dialog windows. He said something about aligning the controls according to font sizes and such.

Bovine Dungus.

You have two options. If you can share your code, we can look for errors you might be missing. Alternatively, you can go over the MSDN documentation for each control you are using with a fine comb and ensure that you are following the recommended practices in terms of construction and event handling to a tee. However, some of the documentation is wrong! This is where you cross-check MSDN against The Code Project, because of the MS-centricity of that site and because it's hardcore Win32 enough that WTL was originally released there and the only available documentation was cobbled by its members.

Share this post


Link to post
Share on other sites
I highly recommend posting code. Pictures are not like a thousand words in this case ;-) It's like taking a picture of your car that doesnt' work and sending it to a mechanic to have it fixed.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!