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

wxKeyBinder problems/solutions discussion

(1/5) > >>

Pecan:
I''ve been wadeing in wxKeyBinder crashes for two days now. Man, they're
the same ones I encountered when fooling around with a cbKeyBinder
plugin a month ago. Pernicious little buggers.

1) frames/buttons etc. appear and disappear without keybinder knowledge
2) Menu items appear and disappear without keybinder knowledge
3) keybinder has memorized all the disappearing frames and wxMenuItems.
4) keybinder is memorizing items it should be filtering out (buttons/dividers...)
5) There are items created by code::blocks that blow wxWidgets out
    of the water when manipulated by keybinder (Maybe this is item2 in
    disguise).

Solutions: (Maybe)

1) Dont allow keybinder to memorize windows it isnt explicity told about
    via an array of "names" or window_handles.
    Mostly taken care of by cbEvt_(open/close events) already.
2) Institute a cbEvt_Menu_HasChanged(id) event so keybinder can
    clean out its old memorized items that are disappearing.
3) Taken care of by #1.
4) Taken care of by #1 and #2
5)  More confirmation needed to see if wxWidgets wxMenuItem->GetLabel()
     is actually being confused by "\" chars in filenames, or its just that the
     menu item disappeared.

Just my thoughts.
I'd love to work on it with some direction of course.

thanks
pecan

mandrav:
If you want my thoughts on wxKeyBinder, having used it for about a month now, I believe it's not up-to-par (at least for C::B). It's a good library for smaller/simpler projects but not for C::B.
I think we should begin an implementation discussion for commands/actions, like what Takesh Miya started at this topic.

takeshimiya:
I couldn't agree more :lol:

If something like that gets implemented, I'll love to see it available as a standalone too, so we could use it in other projects appart from C::B.
Making it a wx contrib, and perhaps calling it wxCommandBinder or wxActionBinder. :P

mandrav:

--- Quote from: Takeshi Miya on December 09, 2005, 07:03:57 pm ---I couldn't agree more :lol:

If something like that gets implemented, I'll love to see it available as a standalone too, so we could use it in other projects appart from C::B.
Making it a wx contrib, and perhaps calling it wxCommandBinder or wxActionBinder. :P

--- End quote ---

I just hope you have time to work on it ;)

Pecan:
mandrav

I certainly agree. wxKeyBinder was not designed for as dynamic
an environment as C::B. I think you'd have to yank it out within
another version anyway.

A better way, I think, is for C::B to be the "server" for a bunch of
keybinder type plugins. C::B could provide the services AND
verifications/validations for
1) a menu keybinder plugin
2) a key macros plugin eg. {Ctrl-Enter} = {\n}{Tab}{Tab}{or whatever}
3) or a scintilla recorder event server thingie so a plugin could record the movements to a file
4) scripting (already planned I've read)

ie, dont pollute the main C::B code with jobs that a plugin can do. Just
provide the means so a plugin can do the job. With events for example.

Anyway, if you want to yank the keybinder code, I'll
re-implement the keybinder plugin as a stopgap measure.
Then when a "real" solution arrives, the plugin can be disposed of.

But to make the stopgap keybinder plugin really workable,
we'll still need the cbEvt_MenuChanged(id) event so that
keybinder can get rid of disappearing menu items from it profile arrays.

I've solved the disappearing windows/frames problem by only alllowing
keybinder to attach() via an array of know windows.

What do ya think

thanks
pecan

Navigation

[0] Message Index

[#] Next page