2. New cheat list box 0.0.0.3 Alpha, changed the possibilities box to a CListCtrl rather than a simple CListBox, use a map for its buffer. It may not quite efficient currently, but I personally think it's much better than adding and deleting the items repeatedly every frame, and now its item can be selected while emulation is running, although there's not much usage for this...
3. added several context menus to possible list, now you can directly add address to memory watch or ram watch, or go to hex editor from here, currently it's still a single select list.
2. Fixed an ancient bug of cheat dialog that importing new cheats makes old existing cheats uneffective.
3. Restructured some cheat searching type to macros since the meaning of the mysterious number is unclear. Maybe the switch case was more efficient than if else... or not?
4. Use a temporary variable rather than a global one to indicate whether the null file pointer is cased by user clicking the cancel or close button of the open archive dialog or a loading error.
5. When recording a movie with cheats, show warning to the user and asking for disabling them.
6. Removed some seems like unused variables, hope this didn't break compiling crossing platforms.
cheats.cpp int converions warnings fix
change default tool index for vc project. if you have problem with it, feel free to revert. but i can't compile with just "8.1" in there sadly...
There are still many disadvantages, the list is not efficient enough since the separator needs too much calculation, when there are too many separators, the watchlist maybe slow.
I think some of their data can be stored in some map or list for fast accessing in the future development, since they don't requires calc every time.
2. Fix nothing was checked in the View menu when Hex Editor first launch.
3. Fix when Hex Editor is open, disabling all cheats in replay doesn't refresh the freezed addresses.
2. Some mysterious things:
In RAM Search, when the Data size was set to 4 Bytes, the value in the list was changed to 4 bytes but the gap of the items is still 2 bytes. I'm unclear it's an old bug or intentional, since some of the macros are used in comparison, they describe the template of the function as a short even in 4 bytes situation, but that might not compare 4 bytes value correctly.
owomomo