#466 Hex editor: Search window has width permanently fixed

[poison_us]

The search window is permanently stretched far beyond acceptable width. Bug occurred after I searched the following hex string (known to be in the file opened in hex editor):

4A0200400E2B1A000000000079006D006D0066005F0042000500BFEF071300010000003A63C039EC9BE440FCA8379135A2E440010000003B000000160000006D0000001B000000000000005D0000003B0000003B0000002700000001000000FFFE7072696F7269747920312D3636612D77617465722D7469702031FFFE61646D696EFFFE61646D696E

Trying to resize by dragging from the sides failed (though I was able to resize vertically without a problem), using the right-click menu to resize failed, and I was unable to find any option to resize in the program's menu (apologies if it exists and I overlooked it).

Running Code::Blocks 16.01 on Windows 7 Pro 64-bit.

[Teodor Petrov]

Doesn't happen on linux, so I cannot do much. Some windows user/dev would have to look at it.

[bluehazzard]

can not reproduce this neither on windwos 7 x64 last trunk build and with [r10973]

can you give detailed steps?
like Open File with hex editor -> press search button ecc ?

[poison_us]

Unable to reproduce it myself on my home PC. Not sure if it has something to do with the OS but home PC runs Win10 Pro x64.

To the best of my memory:
1. Opened ~22.8MB file with hex editor
2. Set Cols:→multiple of→2
3. Pressed search button
4. Searched the long sequence above
5. Moved the cursor around the area where the sequence was located, mainly to ensure I was looking at the correct row in the database file. No editing done, just moving. Goto may have been used at this point, not sure if it was before or after the sequence search I wanted to search using offsets.
6. At some point, opened the search dialog as in #3 above, to see the width permanently stretched. Tried resizing both with the diagonal resize and the horizontal resize on all sides. Could expand the horizontal, but not reduce.

Possibly important:
I later discovered the radio buttons in the "Start from" and "Direction" no longer deselect the previous selection. I'm able to select other options, and it performs the search accordingly, but the UI doesn't seem to update with the removal of previous selections.

Additionally, a few searches may have been performed between C::B's previous launch and the search causing the window to bug. They would've been mainly for short strings (~27 characters) and short hex sequences (8 to 16 bytes), well within the width limits of the window. I know this is vague and probably unhelpful, but my memory of (at the time) trivial events is very poor and I figure the more info the better.

[Teodor Petrov]

I think the bug depends only on the length of the strings you seach for, because the contents of the combobox causes the dialog to stretch. If you find the steps that reproduce the bug 100% - don't hesitate to report them and we'll try to fix it.

[bluehazzard]

i tried again. I cant reproduce your bug, because the textctrl scrolls automatically.

But i found a other bug: If i close the search view with a to long text there apears a scroll bar at the bottom like in your image, but here at my build it covers the bottom controls and so you can't change them. Also i can not change the height?
rev [r10977]

[Teodor Petrov]

bluehazzard:
I disabled the change of height because I don't think it is needed.
Can you show a screenshot?
If you see the scrollbar then you've probably reproduced the bug.

[bluehazzard]

i still can resize the window in all direction, but it is really bugy

see screenshots

[bluehazzard]

and after making it smaler

[EDIT:] OK, now i get how the bug works... I thought you mean you could not make the window it self smaller...

[Teodor Petrov]

The problem is that when filled with elements that are too long the choice control tells the sizers to make the window fit the long control. This means that the window is too long and doesn't fit on the screen thus a horizontal scroll is needed. I'm not sure how this could be fixed.

Probably fill the control on an idle event...Someone using windows must experiment a bit...

[bluehazzard]

would it be a solution to simply use a normal dialog with sizers? I am not familiar with the function of the wxScrolledDialog

[Teodor Petrov]

I don't think it will solve the problem. The problem is in the wxChoice control most probably...

[bluehazzard]

i have tried to fix this, but i am not really a wxWidgets guru. I can't find a function to minimize the size of the Sizer, or better the TextCtrl wxChoice size...

I personally also don't understand why a scrolled dialogue is used here... You can scroll trough the text field with the cursor keys... So i decided to replace the dialogue with a non scrolled dialogue. It is only a workaround, because i think this is a key problem of the ScrolledDialog control itself? But the bug is critical enough to make a temporary fix at least.
I have redrawed the dialog...

[Edit:] it is a choice ctrl not a text ctrl

[Teodor Petrov]

This patch is bigger than the minimal change required for wxScrollingDialog to wxDialog swap. Can you make it smaller. In theory the bug should happen with normal dialogs, too. If I understand why it happens, by reading past discussions about it on the wx list/forums.

[bluehazzard]

This patch is bigger than the minimal change required for wxScrollingDialog to wxDialog swa

true, my first attempt to modify only slightly the code was not successful. I tried again and now i was able to change only the project files and the header file. The other changes (cpp file) were introduced by wxSmith on loading the file with Codeblocks. I didn't removed them because they should pop up every time you open them with wxSmith?

My first attempt was also addressing the expanding of the sizer, because i don't like the behaviour at the moment (the stretching of the "Start from" and "Direction" check boxes). In this patch i didn't modified anything.

In theory the bug should happen with normal dialogues, too. If I understand why it happens, by reading past discussions about it on the wx list/forums.

No it doesn't, it works quite like expected. I think the problem is that if you make the window smaller the wxScrolledDialog detects that the expanded wxCoiche has not enough place in the actual window and adds the scroll bars. It does not try to reduce the size of the wxChoice. Isn't wxScrolledDialog a custom window of codeblocks?

[Teodor Petrov]

The idea is to add scrolling when using cb on small screens.

This scrolling stuff is really old. Don't know where the original author has taken it or if it was implemented from scratch.

Which version of C::B do you use to edit wxSmith files? I've made wxsmith more predictable in recent commits, so it is generally good idea to use one of those.

[bluehazzard]

I use the latest trunk.

The idea is to add scrolling when using cb on small screens.

good idea for large windows like the options, but for small windows like the search dialogue?

does this problem not exists under linux?

[Teodor Petrov]

Nope there it works just fine. Otherwise I would have tried to fix it.

[bluehazzard]

i tried it with a debug build of wx31 and i got this error message:

(wxWidgets-3.1.0\src\common\wincmn.cpp:1055)

wxCHECK_RET( (minW == wxDefaultCoord || maxW == wxDefaultCoord || minW <= maxW) &&
(minH == wxDefaultCoord || maxH == wxDefaultCoord || minH <= maxH),
wxT("min width/height must be less than max width/height!") );

is this a hint what is going on?
The bug is also present in wx31

You were talking about a wx mailing list discussion, can you point me to it?

[Teodor Petrov]

Do you have a backtrace for this assert?
About the discussion - no it was random search about wxchoice and sizing problems.