CodeLite IDE

This is a small issue, but I would like to fix it.

I have a wxDialog box that I have initialized to being 310x260 pixels, as shown in the screen shot below.
Time after time, I've done the following:

1. Click the Generate Code button;

2. Select Build, Rebuild Workspace;

3. Select Build, Run,

4. Bring up the wxDialog. And it looks like the tall, skinny window in the picture below:
I can fuss around with it to make it look more like the preview picture, and it stays that way the rest of the execution (because of Windows Persistency). But it would just be better if I didn't have to.

What am I doing wrong?

I'm using CodeLite v12.0.0.
Windows 10, 64 bit
MinGW

Thanks!
Colleen

You need a wxPanel. I think.

marcelinx, thanks for replying.

Can you please give me more information? Why does the wxFrame need to be a wxPanel? I have two other wxFrames in this program and they behave perfectly. What would be different about having a wxPanel vs. a wxFrame?

I did try adding a wxPanel to the wxFrame. I moved the text box into the wxPanel, but it wouldn't allow wxBoxSizers or wxStaticTextFields in the wxPanel. But the wxFrame still displayed incorrectly, too wide.

I've struggled with this problem for a couple of weeks now. I've cleaned the workspace, re-generated code, and rebuilt the workspace. I've studied the code in wxcrafter.cpp, and verified the code there for the wxFrames that WORK matches the wxFrame that doesn't work. I've gone over my own code with a fine-tooth comb. I've verified that the style settings for the too-wide wxFrame are identical to the settings for the wxFrames that work. I've verified that every control's wxExpand sizer flag is OFF.

I even deleted the existing code for this one wxFrame and REBUILT it, and the page STILL opens WAY too big in one direction. Except now, instead of being tall and skinny, the first time the wxFrame is displayed, it's WAY too WIDE, and spans across both of my two-monitor computer setup.

I just don't know where else to look!

Here is wxcrafter.cpp: And here is the code for the Eq_Digital_Count_Base_Class:

Hi,

Can you please give me more information? Why does the wxFrame need to be a wxPanel?

See this wx FAQ

I had a quick look at the code you attached and can't see any glaringly obvious cause. But that's not surprising when there's so much irrelevant stuff in the files. I suggest that you create a minimal compilable project that demonstrates the problem. That's for two reasons:

• 1) It allows other people to test the code, make changes and see the results.
  2) While you are making it minimal, test as you remove each piece of code; you may suddenly find the problem has disappeared, in which case...

Regards,

David

DavidGH, thanks for replying, and thanks for the link. I read what it said in https://wiki.wxwidgets.org/WxFAQ#Why_do ... it_size.3F

I'm still not clear on the difference(s) between a wxFrame and a wxDialog. I read the answers under "What's the difference between a wxFrame and a wxDialog?" on the same page as the link you gave me. As I read it, the difference is just in how the wxFrame or wxDialog is USED: a wxDialog is acts as a pop-up modal window that won't release control until the user closes it, whereas a wxFrame can be that via the wxSTAY_ON_TOP flag, or not.

So the difference between the two boils down to behavior that could be modified by setting a couple of flags. Good to know.

Anyway, your link helped solve my problem. I created a new wxDialog to replace the malfunctioning wxFrame. The contents of the wxDialog are identical to the malfunctioning wxFrame. But the wxDialog displays correctly, at the size I specified. Again, good to know.

Thank you!!!!!

Colleen

While a program can have multiple wxFrames, the standard paradigm is a single frame with any other top-level windows being wxDialogs. Those are frequently modal, but can instead be modeless e.g. for a palette of tools.

I'm glad it's fixed. However I'm confused about the whole topic:

I created a new wxDialog to replace the malfunctioning wxFrame.

It's not obvious why a wxFrame would malfunction and a replacement wxDialog not, but wasn't the initial post was about a wxDialog, not a frame?

Hi, David,

Thanks for asking.

Several weeks have gone by and I've been dealing with other parts of this section of my code. This is the last known problem with this section of the program. It's now time to figure it out once and for all, or let it stand as a known bug. Because I have to move on to a new part of the code.

The name of the wxDialog is Digital_Count.

Desired behavior: When Digital_Count opens, it is correctly sized for its contents. It contains two wxStaticText controls, a wxTextCtrl control, and two wxButtons. It's small.

Actual behavior: The first time Digital_Count is displayed after compilation, is maximized both vertically and horizontally. If I resize it manually, it stays that size for every later execution.

Initialization:
Digital_Count's wxDialog Size parameter is -1,-1.

Its wxDialog Minimum Size parameter is -1,-1.

Windows Persistency is enabled.

The styles I set for Digital_Count are as follows:

wxCAPTION
wxRESIZE_BORDER
wxMAXIMIZE_BOX
wxMINIMIZE_BOX
wxCLOSE_BOX

I now have four wxDialogs in this program:

Digital_Count
Linear
Polynomial
Thermocouple

All have the exact same parameters set as the ones I described above.

Of the four, two "start life" nicely sized for their contents. They're perfect. They are Linear and Thermocouple.

Polynomial starts life maximized vertically, but not horizontally.

And of course Digital_Count starts life maximized both vertically and horizontally. Curiously, it's the smallest wxDialog of the four. And by "smallest," I mean it contains the fewest controls.

I had tried rewriting Digital_Count as a wxFrame, but my project engineer did not like how it looked. So I switched back to a wxDialog.

Suggestions? Ideas? What should I look for? Could there be a "maximize on startup" flag somewhere?

Colleen

The things I can think of that would definitely make a sizer-using wxDialog (or frame) too big are:

• 1) Setting a large explicit size to the dialog (obviously).
  2) Setting a large explicit size to one of the dialog's controls.
  3) Adding controls/child-sizers to a sizer with the wxEXPAND flag and/or a non-zero Proportion.

Not so definite, but possible:

• 4) Giving a control an implicit size e.g. certain text-containing controls containing "a very very very...... long sentence" may decide its best-size is greater than a similar control containing "foo".

The code you posted is several weeks stale. I suggest you examine the current code and see if any of the above things occur. If not, your next step is to create a minimal compilable project that demonstrates the issue i.e. just that dialog, containing the minimal number of child controls to make it fail.

Just by doing, you have a very good chance of spotting the cause yourself (if so, perhaps you could post the solution for future users). If not, post the zipped project here (or link to a pastebin containing it); doing that greatly improves the chance of someone spending time reproducing/explaining the problem.