Author Topic: Help bug (may be)  (Read 10739 times)

Offline MaxGaspa

  • Almost regular
  • **
  • Posts: 129
Help bug (may be)
« on: February 17, 2006, 01:17:54 pm »
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.

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Help bug (may be)
« Reply #1 on: February 17, 2006, 01:31:04 pm »
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

Offline MaxGaspa

  • Almost regular
  • **
  • Posts: 129
Re: Help bug (may be)
« Reply #2 on: February 17, 2006, 01:34:53 pm »
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

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Help bug (may be)
« Reply #3 on: February 17, 2006, 01:38:31 pm »
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

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5177
Re: Help bug (may be)
« Reply #4 on: February 17, 2006, 01:47:11 pm »
Michael has build it himself

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Help bug (may be)
« Reply #5 on: February 17, 2006, 02:09:46 pm »
from the sources of the help-plugin


Code: [Select]
// max 20 help items (it should be sufficient)
#define MAX_HELP_ITEMS 20

only the first 20 items are initialized ;-)

Offline MaxGaspa

  • Almost regular
  • **
  • Posts: 129
Re: Help bug (may be)
« Reply #6 on: February 17, 2006, 02:12:54 pm »
Uh... Could you please increase to ... 32?

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

Thankx

Max

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Help bug (may be)
« Reply #7 on: February 17, 2006, 02:15:27 pm »
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 !
« Last Edit: February 17, 2006, 02:17:45 pm by tiwag »

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Help bug (may be)
« Reply #8 on: February 17, 2006, 03:20:06 pm »
lol, hardcoding limits is something fun... but 20?? lol :lol:

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Help bug (may be)
« Reply #9 on: February 17, 2006, 03:31:08 pm »
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 :)
Be patient!
This bug will be fixed soon...

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1442
    • CenizaSOFT
Re: Help bug (may be)
« Reply #10 on: February 17, 2006, 05:23:16 pm »
I'll take a look this night... if I remember to.

Offline MaxGaspa

  • Almost regular
  • **
  • Posts: 129
Re: Help bug (may be)
« Reply #11 on: February 18, 2006, 09:33:44 am »
Thanks for reply. I opened a bug report.

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1442
    • CenizaSOFT
Re: Help bug (may be)
« Reply #12 on: February 19, 2006, 03:43:03 pm »
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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Help bug (may be)
« Reply #13 on: February 19, 2006, 03:57:18 pm »
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 ;)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline MaxGaspa

  • Almost regular
  • **
  • Posts: 129
Re: Help bug (may be)
« Reply #14 on: February 19, 2006, 07:31:00 pm »
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  :D) 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.  :D

Thanks for the modification (32).

Bye

Max

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Help bug (may be)
« Reply #15 on: February 19, 2006, 07:46:16 pm »
20 help items aren't unreasonable. You've obviously not used something like Documancer before.

Never assume anything. :wink:

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Help bug (may be)
« Reply #16 on: February 19, 2006, 10:54:41 pm »
Never assume anything. :wink:
...and you code will be more extensible, robust, and long lasting.

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Help bug (may be)
« Reply #17 on: February 20, 2006, 03:40:40 am »
Never assume anything. :wink:
...and you code will be more extensible, robust, and long lasting.

I agree with Thomas that it doesn't make sense rewrite the plugin only for that.

In the past I thought of rewritting it, but for integrating help files (CHM, HTML, HTB) inside C::B. However after some experimentations it turned out that wxHtml is not suited for the task, it doesn't know anything about CCS and complex HTML, so it could open only HTB files, not CHM, nor any other type.
The only real solution was to use wxMozilla or wxIE (in Windows), but it'll add a huge dependency. I don't discard it yet, but that dependency kinda turned me off.

Offline AkiraDev

  • Multiple posting newcomer
  • *
  • Posts: 71
Re: Help bug (may be)
« Reply #18 on: February 20, 2006, 09:51:05 am »
Quote
In the past I thought of rewritting it, but for integrating help files (CHM, HTML, HTB) inside C::B. However after some experimentations it turned out that wxHtml is not suited for the task, it doesn't know anything about CCS and complex HTML, so it could open only HTB files, not CHM, nor any other type.

I happen to working on precisely that. What's so wrong about only HTB being opened inside C::B? It's platform agnostic. Having it working seamlessly inside C::B would both promote the format and give C::B a robust cross-platform help system.

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Help bug (may be)
« Reply #19 on: February 20, 2006, 01:17:03 pm »
Warning: long post, read carefully :P

Quote
In the past I thought of rewritting it, but for integrating help files (CHM, HTML, HTB) inside C::B. However after some experimentations it turned out that wxHtml is not suited for the task, it doesn't know anything about CCS and complex HTML, so it could open only HTB files, not CHM, nor any other type.

I happen to working on precisely that. What's so wrong about only HTB being opened inside C::B? It's platform agnostic. Having it working seamlessly inside C::B would both promote the format and give C::B a robust cross-platform help system.

It's almost ok, but there are two problems: there are little few books on this format. All of them can be getted from http://htmlhelp.berlios.de/books/htb.php
(I note the ones we could use: wxwidgets, libstdc++, gdb, gcc, make).

The other problem is that all the rendering through wxHtml is html in very basic form. That means for example, that the C::B SDK documentation is out (doxygen/doxys can't generate html so basic to work on wxHtml).

In case you want, I have an implementation of wxHelpController that can be embedded in a window, so the help can be rendered in a C::B EditorBase instead of an outside window. However I think that an external window option should exist, some users couldn't like having the help embedded in C::B.


As you may know, wxHelpController can only open in it's own renderer HTB files, not CHM, nor any other.

But my goals (wishes) for the plugin was/are:
-HTB support
-CHM support
-HTML support
(local files and online)
-DevHelp support (it's popular enough on linux)
-PDF support
-Man pages support
-Info pages support


Now, one by one:

-HTB support: This should be the most easy to implement, and also the most likely to have first (if any).
It will requiere to use the reimplemented wxHelpController I have and adapting it so the embedded/external option can exist.

-CHM support: This is one of the most important for me, because there's plenty of free CHM books everywhere. It's very comfortable to use it.

Now, the problem relies on that CHM is a MS format. But fortunately it's already reverse enginered, and it exists a program called wxCHM which uses that library. It was programmed for Linux only, but some months ago a Mac port appeared. There isn't in Windows as the author wasn't interested (with rights, if Windows can read CHM natively :) ).

But I took the source and after some (heavy?) modifications, I could compile it, and finally run it on Windows, with very few glitches. :D

But then I discovered: wxCHM uses as render wxHtml, and kinda reimplements all the wxHelpController window interface.
Which is not good (using wxHtml as render), because most (almost all) CHM books out there uses CSS and HTML code that wxHtml can't cope with.

However, wxCHM have pieces of code that can be used without problem.

-HTML support: This is were I left frustrated. HTML is the most important format for obvious reasons. wxHtml can't render almost any page online well. And almost all API documentations have an HTML (downloadable or online) version.

And here the choices are very little: wxMozilla (Windows, Linux), wxIE (Windows), and wxSomethingMac (Mac, can't remember it's name).

The choice I would made would be wxMozilla, but it seems that it doesn't work well on Mac yet.
Using different APIs, like using wxMozilla in linux, wxIE on windows and wxSomethingMac on mac could be done, but writting for 3 different APIs to do the same thing, I don't know if it's worth the effort.

But the single most important problem I have with wxMozilla (which uses an embedded gecko) is the huge (relative) dependacy it will add. It will take a lot of resources regarding compile time and executable size, which I couldn't decide if it was the effort or not.

So I gave up at that point on this matter. :(

-DevHelp: It's a CHM-like format but OpenSource, used mostly for Linux APIs. Not my priority, but something to have in mind.

-PDF support: Probably a though one, not easy to do, unless there is a wx PDF friendly library.
I think the best approach here would be the same as is now: calling Acrobat Reader or whatever, because there are almost always PDF readers installed on any platforms, so it shouldn't be a concern like the other formats (except HTML), that are available most of times in only one platform.
So not important for now.

-Man pages and Info pages support: This is low on the priority list also. But given the simple these formats are, we could write a parser for them that displays them in the HTML window. Note that I've spent a lot of time searching for any Man or Info pages reader for windows, but there is nothing (yes I was surprised to know that, but no, there isn't a man nor info win32 port yet, neither any other program can open them).



Well, that's enough. My conclusions are that the single most important problem right now is wxHtml incompetence. And I've reading some wx-devel lists saying that everyone is aware of the poor render of wxHTML, and that they were looking for using already existant implementations at some future (even with more than one backend in the same platform).

If you ask me, I think the best implementation wxHtml could have is reimplementing all the KHTML API, which is a lot lightweight than Mozilla. And it's the first and only (yet) OpenSource implementation to pass the CSS Acid2 test.

Hope that adds a bit (:D) of info on the matter.

PS: Do you think this should be in the Wiki?

Regards,
Takeshi Miya
« Last Edit: February 20, 2006, 01:24:34 pm by Takeshi Miya »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Help bug (may be)
« Reply #20 on: February 20, 2006, 04:38:05 pm »
To explain why I called adding more than 20 items "unreasonable" in the first place, look at what you get when you right click in the editor:



I have only 5 help files listed, now imagine there were 30... the menu would fill the entire screen! Maybe you feel differently, but to me, having many choices is not a good thing.

Anything beyond 5-6 choices starts getting irritable, and anything beyond 10 will start to seriously hinder your work.

Of course if you never right-click in the editor (and use "Find declaration/implementation", for example), then this does not matter an awful lot. :lol:
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline duncanka

  • Multiple posting newcomer
  • *
  • Posts: 53
Re: Help bug (may be)
« Reply #21 on: February 20, 2006, 06:39:27 pm »
To explain why I called adding more than 20 items "unreasonable" in the first place, look at what you get when you right click in the editor:

...

On that subject :)...why is this not done using a submenu?  The Export functions had the same problem, so they were (quite sensibly, IMHO) switched to a submenu in the File menu.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Help bug (may be)
« Reply #22 on: February 20, 2006, 07:22:55 pm »
That would at least prevent excessive pollution of the main popup :)

Makes the lookup function yet more complicated, though.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Help bug (may be)
« Reply #23 on: February 21, 2006, 09:16:46 am »
That would at least prevent excessive pollution of the main popup :)

Makes the lookup function yet more complicated, though.

I thought the same when I requested the "uncluttering the contextual menu" some months ago.

The best solution I'm thinking right now is put an option to change between both, which defaults to like it's now, but power users can choose to become it a submenu.

Anyways, it looks like a natural thing with the ActionsManager. :)

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487