Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Tidy main context menu

<< < (3/6) > >>

Alpha:
Menu registry would be a useful, however, I currently am unsure of how to implement it.  Until a design is figured out (by me, or anyone with ideas about it), I will see what I can to with organizing the existing structure.

MortenMacFly:

--- Quote from: Alpha on September 02, 2012, 03:11:49 pm ---Menu registry would be a useful, however, I currently am unsure of how to implement it.

--- End quote ---
I think most of the bits and pieces are there already. Basically the interface would change, so that plugins are not offered a menu which they can access themselves, but offer a menu they would like to plugin to and the code (SDK) decides where and if to plug.

So the interface functions are there, just the "direction" needs to change and the handler in the SDK that sorts the menus.

ollydbg:

--- Quote from: oBFusCATed on September 01, 2012, 05:14:25 pm ---
--- Quote from: ollydbg on September 01, 2012, 02:47:18 pm ---"Run to cursor" should not exist when the debugger is not running, right?

--- End quote ---
Why not? Have you tried it to see what it does in this situation :)

--- End quote ---

I just tried, when click on this menu item, it will start the debugging session, but sometimes it does not stop on the current cursor.( in this case,  I have the option "Do not run the debugee" option checked, then the debugger just halt when started) If this option does not checked, but have some breakpoints setting before the cursor, the debugger will stop at the breakpoint.
I realize that it's the normal behavior "Run to cursor" should do. :)

Thanks.

oBFusCATed:

--- Quote from: ollydbg on September 04, 2012, 08:57:45 am ---I realize that it's the normal behavior "Run to cursor" should do. :)

--- End quote ---
Yes :)

dmoore:

--- Quote from: MortenMacFly on September 02, 2012, 03:56:00 pm ---
--- Quote from: Alpha on September 02, 2012, 03:11:49 pm ---Menu registry would be a useful, however, I currently am unsure of how to implement it.

--- End quote ---
I think most of the bits and pieces are there already. Basically the interface would change, so that plugins are not offered a menu which they can access themselves, but offer a menu they would like to plugin to and the code (SDK) decides where and if to plug.

So the interface functions are there, just the "direction" needs to change and the handler in the SDK that sorts the menus.

--- End quote ---

Just my 2c:

At start up, the framework and each plugin should "register" the menu commands/popup/toolbar items it offers with a unique ID. That ID could then be used to control whether the item appears, key bindings (cannot current assign keybindings to pop up or toolbar items or menu items whose labels change) and with a lot more work where items appear in menus (I don't think that last one is really necessary, so might be nice).

I am agnostic on the implementation details, but want to keep things simple for plugin authors and don't want to impact runtime performance with lots of checks before opening menus.

Navigation

[0] Message Index

[#] Next page

[*] Previous page