IIRC, the 0x00 hex bug was caused by the data structures for a search being based on std::string and the c_str() method, which returns a NULL terminated string compatible with the C standard. However, when said data is used with anything like strlen() to determine the size of the array, the function will automatically break on the first 0x00 found in the search string, since it's recognized as the EOS token, thus ignoring the rest of the data. This didn't happen on bytecode stuff because it used another method for counting data size.
In the meanwhile, small updates on the GUI side:
Deriving classes for everything is just a dreamboat and allows so much control over everything, including fancy details such as menus with true color icons and other flashy GUI components (winky wink, Toolbars). Not to mention the new way dialogs are managed will allow extra functions in just a matter of defining a click event and associating a class method linked to it. Here's an example of how things are now managed inside the relative scan dialog:
This should be very similar to how Java button events works, but I'm not sure as I haven't touched Java since high school (about 9 years ago). Many thanks to Klarth for helping me in resolving a compiler error with class method pointers.
Also, table support is working again out of the blue; no idea why it even broke in the first place, but it seems like I fixed it by toying around with the Unicode settings. On a related matter, relative scan is working again as well, but according to what I see in the code, it would only properly behave with ASCII strings, rendering the Unicode support rather useless. Should I just leave it like that and let Monkey Moore do the dirty job?