Help bug (may be)

[Max]

Hi,

I would like to flag a possible bug using latest nightly build (16 Feb , build 2016) and Windows XP.

I add several .chm and .pdf files into the help menu, using

Setting->Environment->Help Files

Clicking on the help menu items I get, correctly, the window showing the contents of the help file. But not for all
items. A click in the last item simply do nothing. It is not related to the file itself. If I change the order
of the items in the help menu all the items work but the last is not working. It seems the the last item of the help file
is inactive.


I would like to have a bug confirmation before opening a new bug report.


Thanks

Max.

[Michael]

Hello,

I have 2 help files in the Help menu and both work well (even if I change their order). I use C::B rev2021.

May be your problem happen when you have a certain number of help files in the menu?

Best wishes,
Michael

[Max]

I have 21 file (item) in the help menu. But you are using the recv 2021, in the latest nightly build I got the 2016 (or the rev is not correctly flagged in the help-About). Where have you got the 2021?

Max

[Michael]

I have 21 file (item) in the help menu. But you are using the recv 2021, in the latest nightly build I got the 2016 (or the rev is not correctly flagged in the help-About). Where have you got the 2021?

I build C::B by myself (from the SVN sources). This morning there were some updates (anyway, none of them seem to be related to solve you problem), which lead to C::B rev2021.

Best wishes,
Michael

[killerbot]

Michael has build it himself

[tiwag]

from the sources of the help-plugin

Code Select Expand

// max 20 help items (it should be sufficient)
#define MAX_HELP_ITEMS 20


only the first 20 items are initialized ;-)

[Max]

Uh... Could you please increase to ... 32?

Have I to open a bug report or a feature request?

Thankx

Max

[tiwag]

it's a bug - it should read the number of available items from the config and not use any hardcoded limit
until Ceniza will bugfix this you'll have to live with 20 ;-)

but you can build your own codeblocks from svn sources and then you can do whatever you like !

[takeshimiya]

lol, hardcoding limits is something fun... but 20?? lol :lol:

[mandrav]

When Ceniza took over this plugin, he switched from a static C array to using a std::vector for the help items. But it seems he left the old static arrays for the menu item IDs.

Or something like that anyway

[Ceniza]

I'll take a look this night... if I remember to.

[Max]

Thanks for reply. I opened a bug report.

[Ceniza]

Well, this bug won't be that easy to fix and it'll require even more understanding of bourricot's original code, or a redesign.

The redesign idea sounds better, and I've thought an implementation that should do, but the problem right now is time.

I'll increase the limit to 32 as a quick solution and try to get the generic solution implemented soon.

[thomas]

I looked into the code shortly, out of interest. The problem with the present design is that the maximum number of items is also used to hook the menu events (which is hardcoded, too, as are a couple of other things).
To make it entirely flexible, one would really have to rewrite 80% of the plugin. I seriously doubt if that amount of work justifies the small gain, though... Where is the need for this, really? Hardcoding seems quite acceptable to me in this particular case.

Adding 20 help files is already unreasonable, but adding more than 32 is really insane :lol:
Complexity is never good. If someone wants to add 50 or 60 help files, then he has a serious problem, but that problem is not the plugin

[Max]

Dear Thomas

I am using many different libraries. Summimg help files and references for API I got 21 help files. It is conveninet
(so not unreasonable  ) to get the help with just one click.

I agree with you, 60 help items are unreasonable. 

From my point of view 32 items will fulfill present and future needs. At the end the limit can be considered as a feature
and not a bug. 

Thanks for the modification (32).

Bye

Max