I'm trying to let the user select some items in a multi-selection listbox, and then pop up a menu when the user right-clicks on the selected items. The problem is that right-clicking resets the selection. Is there any way around that? I think there should be some way to tell the listbox to only allow selecting with left-click. I'm using Nana 1.7.

I'm trying to let the user select some items in a multi-selection listbox, and then pop up a menu when the user right-clicks on the selected items. The problem is that right-clicking resets the selection. Is there any way around that? I think there should be some way to tell the listbox to only allow selecting with left-click. I'm using Nana 1.7.

Have you tryied setting the event for key/button mouse down & mouse right button and then cancel the event if/after you open the menu?

Have you tryied setting the event for key/button ``mouse down & mouse right button`` and then cancel the event if/after you open the menu?

Have you tryied setting the event for key/button mouse down & mouse right button and then cancel the event if/after you open the menu?

I was able to do something with mouse_down and mouse_up, but it got too complicated to manage the unintended side effects. In the end, I had no choice but to modify the library, it's the easiest solution.

>Have you tryied setting the event for key/button mouse down & mouse right button and then cancel the event if/after you open the menu? I was able to do something with `mouse_down` and `mouse_up`, but it got too complicated to manage the unintended side effects. In the end, I had no choice but to modify the library, it's the easiest solution.

Hi, @Error Flynn , I added a new method to set a predicate that decides to deselect the selected items in mouse_up event.

        /// Sets a predicate that indicates whether to deselect items when mouse_up is triggered.
        /**
         * The predicate is called before the listbox attempts to deselect the selected items in the mouse_up event. Other situations,
         * the predicates isn't called, for example, releasing mouse button after user performed a box selection, because listbox doesn't deselect the items during this operation.
         * @param predicate Decides to deselect the items.
         *    The paramater of predicate indicates the mouse button which is releasing.
         *    It returns true to deselect the selected items. It returns false to cancel to deselect the selected items.
         */
        void set_deselect(std::function<bool(nana::mouse)> predicate);

//Don't deselect the items when right-click and one of selected items is hovered.
list.set_deselect([&](nana::mouse btn) {
    return !(btn == nana::mouse::right_button && !list.hovered(false).empty());
});

I will push this change to the develop branch today later.

If the comment of set_deselect confuses you, please let me know.

Thank you for your feedback!

Hi, @Error Flynn , I added a new method to set a predicate that decides to deselect the selected items in mouse_up event. ```c++ /// Sets a predicate that indicates whether to deselect items when mouse_up is triggered. /** * The predicate is called before the listbox attempts to deselect the selected items in the mouse_up event. Other situations, * the predicates isn't called, for example, releasing mouse button after user performed a box selection, because listbox doesn't deselect the items during this operation. * @param predicate Decides to deselect the items. * The paramater of predicate indicates the mouse button which is releasing. * It returns true to deselect the selected items. It returns false to cancel to deselect the selected items. */ void set_deselect(std::function<bool(nana::mouse)> predicate); //Don't deselect the items when right-click and one of selected items is hovered. list.set_deselect([&](nana::mouse btn) { return !(btn == nana::mouse::right_button && !list.hovered(false).empty()); }); ``` I will push this change to the `develop` branch today later. If the comment of `set_deselect` confuses you, please let me know. Thank you for your feedback!
edited May 22 at 11:16 am

Jinhao,

Sometimes the nana methods' name or methods' arguments that you choose is long and perhaps not necessary!

For example a method either select or deselect a functionality, so adding set to select i.e. set_select () or set deselect() does not add any more meaning to the method.

I have seen quite a few functions or methods in NANA which have redundant phrase in them. I suggest to choose the minimal description for functions and method in NANA and avoid addition of unnecessary words and phases to the methods name or their arguments. This would makes the code cleaner and shorter. I hope you take my suggestion in good fate, and I am sure this would make NANA code more readable.

For example

void set_deselect(std::function<bool(nana::mouse)> predicate);

Can just be:

 void select(std::function<bool(nana::mouse)> predicate);
 void deselect(std::function<bool(nana::mouse)> predicate);

or in the nana::filebox

nana::filebox::add_filter()

Can just be

nana::filebox::filter()

or in the nana::menu

nana::menu::item_proxy

Can just be:

nana::menu::item

There are many others that I leave it to you to find out.

Jinhao, Sometimes the nana methods' name or methods' arguments that you choose is long and perhaps not necessary! For example a method either select or deselect a functionality, so adding **set** to select i.e. **set_select ()** or **set deselect()** does not add any more meaning to the method. I have seen quite a few functions or methods in NANA which have redundant phrase in them. I suggest to choose the minimal description for functions and method in NANA and avoid addition of unnecessary words and phases to the methods name or their arguments. This would makes the code cleaner and shorter. I hope you take my suggestion in good fate, and I am sure this would make NANA code more readable. For example ```` void set_deselect(std::function<bool(nana::mouse)> predicate); ```` Can just be: ```` void select(std::function<bool(nana::mouse)> predicate); void deselect(std::function<bool(nana::mouse)> predicate); ```` or in the nana::filebox ```` nana::filebox::add_filter() ```` Can just be ```` nana::filebox::filter() ```` or in the nana::menu ```` nana::menu::item_proxy ```` Can just be: ```` nana::menu::item ```` There are many others that I leave it to you to find out.
edited May 22 at 5:40 pm

Hi, @ABD set_deselect is not a method to deselect selected items, it is used to set a predicate which decides to deselect selected items.

add_filter is to add a filter, while filter implies that the curent filter is overwritten with a new filter.

Hi, @ABD `set_deselect` is not a method to deselect selected items, it is used to set a predicate which decides to deselect selected items. `add_filter` is to add a filter, while `filter` implies that the curent filter is overwritten with a new filter.

Jinhao,

It does not matter if it is a method or not, my point was not to add redundant words or phrases.

Also filter() or add_filter() does the same thing!

I do not want to argue about these issues. It is your library and do what you like. I just wanted to point out a few things that makes NANA more readable and make more sense.

Thanks for at least reading what I said. Have a nice day.

By the way:

 nana::folderbox::allow_multi_select(true);

Can just be

 nana::folderbox::multi_select(true);
Jinhao, **It does not matter if it is a method or not, my point was not to add redundant words or phrases.** **Also filter() or add_filter() does the same thing! ** I do not want to argue about these issues. It is your library and do what you like. I just wanted to point out a few things that makes NANA more readable and make more sense. Thanks for at least reading what I said. Have a nice day. By the way: ```` nana::folderbox::allow_multi_select(true); ```` Can just be ```` nana::folderbox::multi_select(true); ````
edited May 22 at 8:02 pm

I have to agree with both @ABD and @jinhao.

Mayber smaller function names are easier to type in, agreeing with @ABD.

But, if you have an intelligend IDE, you will have autocomplete, with actually some tooltip from the function source showing the parameters and what it does (like the one @jinhao proposed as set_deselect). So cutting to smaller names might lose the meaning of the function. While set_deselect sets a deselect behaviour, just a function with select might confuse with another function when you need to select a specified entry or header. About the other examples of add_filter, there is a difference between overwriting and adding new filters: if you overwrite you cant have multiple extension filters, like for a image editor that you can select files with .png, .jpg, *.bmp. Thats why you can programatically add different filters to the file box, insted of just setting and overwritting the defined filter. item_proxy is an object type, if you want to have an object or function named item inside the menu class, then you cant.

And in the end, bigger function names means nothing on the compiled binary: on the compiling event all function names on the majority of the release settings will just cut them into assembly.

I have to agree with both @ABD and @jinhao. Mayber smaller function names are easier to type in, agreeing with @ABD. But, if you have an intelligend IDE, you will have autocomplete, with actually some tooltip from the function source showing the parameters and what it does (like the one @jinhao proposed as set_deselect). So cutting to smaller names might lose the meaning of the function. While ``set_deselect`` ``sets`` a ``deselect`` behaviour, just a function with ``select`` might confuse with another function when you need to select a specified entry or header. About the other examples of ``add_filter``, there is a difference between overwriting and adding new filters: if you overwrite you cant have multiple extension filters, like for a image editor that you can select files with *.png, *.jpg, *.bmp. Thats why you can programatically add different filters to the file box, insted of just setting and overwritting the defined filter. ``item_proxy`` is an object type, if you want to have an object or function named ``item`` inside the menu class, then you cant. And in the end, bigger function names means nothing on the compiled binary: on the compiling event all function names on the majority of the release settings will just cut them into assembly.

@eduardoroeder,

Referring to my previous posting:

nana::folderbox::allow_multi_select(true);

the word "allow" is redundant. We should either have:

nana::folderbox::allow_multi_select();
nana::folderbox::donot_allow_multi_select();

or better way:

nana::folderbox::multi_select(true);

The argument true or false decides the action of the method and not the word "allow". In fact the word "allow" is confusing when is it used with a boolean flag.

There are many example of this type of redundant or confusing naming in NANA.

But NANA is Jinhao's baby and we can't force it!

@eduardoroeder, Referring to my previous posting: ```` nana::folderbox::allow_multi_select(true); ```` the word "allow" is redundant. We should either have: ```` nana::folderbox::allow_multi_select(); nana::folderbox::donot_allow_multi_select(); ```` or better way: ```` nana::folderbox::multi_select(true); ```` The argument **true** or **false** decides the action of the method and not the word "allow". In fact the word "allow" is confusing when is it used with a boolean flag. **There are many example of this type of redundant or confusing naming in NANA.** But NANA is Jinhao's baby and we can't force it!
edited May 22 at 8:39 pm

The allow_ part is redundant, let’s improve these names in 1.8, I will start a new thread to discuss these redundant and confusing names

The allow_ part is redundant, let’s improve these names in 1.8, I will start a new thread to discuss these redundant and confusing names

Hi, @Error Flynn , I added a new method to set a predicate that decides to deselect the selected items in mouse_up event.

That works beautifully, thank you!

>Hi, @Error Flynn , I added a new method to set a predicate that decides to deselect the selected items in mouse_up event. That works beautifully, thank you!

Jinhao: The allow_ part is redundant, let’s improve these names in 1.8, I will start a new thread to discuss these redundant and confusing names

Thanks Jinhao, Looking forward to seeing your thread to discuss and revise methods' naming scheme for NANA library 1.8 soon!

>Jinhao: The allow_ part is redundant, let’s improve these names in 1.8, I will start a new thread to discuss these redundant and confusing names Thanks Jinhao, Looking forward to seeing your thread to ** discuss and revise methods' naming scheme for NANA library 1.8 soon! **
edited May 25 at 4:25 pm
97
views
11
replies
3
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft