Emulator

getting the same problem.

on mac this behave differently. the text filed is working as intended but when i search for a value i'm getting a warning dialog "you must enter a valid decimal, hexadecimal or octal number"

i use the previous value method to get over it. however, i can't manage to make any code i find to work no matter what i do. it seems the code manager is totally broken no codes are running even the ones i get from the net.

i use Dolphin : 3.0-600 downloaded from http://dolphin-emulator.com/
Running on Os: MacOSX 10.7.3 and windows 7
i note that mac version was much stable than my win7 version

I narrowed it down to the revision that merges the branch "wxw3-update". Prior to revision d15740daf124 the cheat window still behaves correctly. In every revision past the gameini database update at revision 54801d93c4bf, things are messed up and broken.

I hope somebody will look into this.

Chiming in with a "Broken for me, too!" As far as the official archives from the main site are concerned, 509 is the last public build that seems to have the correct behavior.

The behavior in the newer versions APPEARS to be that all values are interpreted as, perhaps, "0".
For instance, I get similar numerical search results from r509 if I type 0 into the value box and keep hitting "next scan" -- I start at ~7.8 million results for 16bit values and I lose a hundred or so hits every time I hit next scan.

Perhaps the only bug in latest versions is a faulty text element read, and the failure return code is 0 and being mistaken as the user value.

I've never done any GUI programming before, but I'll see if I can't track down the bug.

I've never used wxWidgets before, and unfortunately it seems the file for this dialog box has not changed since June 2011, http://code.google.com/p/dolphin-emu/source/list?path=/Source/Core/DolphinWX/Src/CheatsWindow.cpp&r=ced315f677e6deae4d371ae581be79d37b8881be

Unless I am reading the gdocs codebase incorrectly, this is from another build, etc etc.

Is it possible there was a change in the wxWidgets API that would cause the text cursor not to appear in this text selection element?

Yes, it is possible that changes to the wx API have caused both the cursor and faulty text element read.

Not sure why the text element is behaving poorly, but the value read might be this:

wxString x_val = textctrl_value_x->GetLabel();
...should possibly be...
wxString x_val = textctrl_value_x->GetValue();

Doesn't fix the odd text selection behavior, but it does make the read work again.

1. The border appears to be missing or transparent until mouse-over, but I am not sure what would cause this. One you mouse over and it gets focus, the border turns slightly blue. when you mouse away, it goes back to gray.

2. The missing cursor seems to stem from this call:
   connect_macro(textctrl_value_x, CheatSearchTab::ApplyFocus, wxEVT_SET_FOCUS, this);
   which is supposed to select the "user value" radio button if you click the edit text.
   I am not familiar with wxWidgets event handlers, but you can fix it by naming the wxCommandEvent& parameter 'ev', then calling ev.Skip(true); in the CheatSearchTab::ApplyFocus method.
   I find the syntax of skip(true) confusing, but I believe this allows the default event handlers to process the onFocus and draw the editing caret.

So with my above comment (#6) and the tweak above, we still have wonky borders, but the code window is again functional.

Thanks,
--jh

Would you please create a patch?

For the missing borders, perhaps the layout needs to be altered slightly?

Very minor changes. I can keep poking at the border stuff, but I don't have any good theories for why it's behaving like it is.

Issue 5433 has been merged into this issue.