Request : C::B View::notebook enhancements

[ollydbg]

One more info: I've turned on the  debug output on parserthread.cpp

Code

#define CC_PARSERTHREAD_DEBUG_OUTPUT 1

and I see lots of messages in the DebugLog panel (as expected). If I change from one tab to another before waiting for *all* messages to show up, i.e. while the logging is in progress, it freezes here, no matter what!
I'm just not sure if this is because the parser hasn't finished and that causes the freeze or it's just a display problem, that the DebugLog is flooded with messages and moving to another editor tab just cannot be treated by the painting thread... Anyway, just FYI.

This is because there are too many log message, so you will get freeze, You can disable all the "header path search" in the CC dialog, so that CC can only parse your project files.

[oBFusCATed]

There is another bug with the enhancement:

1. Goto the main menu
2. Open a menu that is rendered on top of the notebook
3. Hover on an item on top of the notebook

The result is that the menu closes and the tooltip shows

[daniloz]

There is another bug with the enhancement:

1. Goto the main menu
2. Open a menu that is rendered on top of the notebook
3. Hover on an item on top of the notebook

The result is that the menu closes and the tooltip shows

Here, on Windows Vista 32-bit, trunk svn 7010, the menu doesn't close when the tooltip shows and I can come back to it...
However, if I do one more step:
4- after the tooltip is shown, click outside C::B

C::B crashes! :-o

[Jenna]

I look into it, thanks for reporting.

[Jenna]

Could you please test svn r7011 (if needed, I can merge trunk to debugger-branch).
I was not able to reproduce the crash on windows (tested on vista 64-bit), but the tooltip should not appear any more if the tab is behind an open menu.
So the crash might also be fixed.

[daniloz]

Could you please test svn r7011 (if needed, I can merge trunk to debugger-branch).
I was not able to reproduce the crash on windows (tested on vista 64-bit), but the tooltip should not appear any more if the tab is behind an open menu.
So the crash might also be fixed.

Great work! 
I can confirm, no more tooltip if the menu is open and, most important, no more crashes !!!

[oBFusCATed]

(if needed, I can merge trunk to debugger-branch).

I can test only after a merge, but don't worry, too much.

Another thing:
If I click on a tab that is not the first one, but it is not the last one either, the tab I've clicked on is made the first one.
There more tabs, than there is space on the notebook, so probably your code for scrolling is kicking in.
This behaviour is a bit annoying...

[Jenna]

Another thing:
If I click on a tab that is not the first one, but it is not the last one either, the tab I've clicked on is made the first one.
There more tabs, than there is space on the notebook, so probably your code for scrolling is kicking in.
This behaviour is a bit annoying...

Confirmed.
Next issue to fix.

[Jenna]

Another thing:
If I click on a tab that is not the first one, but it is not the last one either, the tab I've clicked on is made the first one.
There more tabs, than there is space on the notebook, so probably your code for scrolling is kicking in.
This behaviour is a bit annoying...

Confirmed.
Next issue to fix.

Should be fixed in svn r7015 on trunk and svn r7016 in debugger-branch.

[oBFusCATed]

Testing it ... seems the two problems are fixed...

Can you implement an invert scrolling options?
I want to have the same scrolling as in Firefox, but at the moment it is in the opposite direction.
It is a little bit confusing, because I'm scrolling first to the wrong direction, then I realize it is the opposite,
so I always do two operations instead of just one.

[Jenna]

Testing it ... seems the two problems are fixed...

Can you implement an invert scrolling options?
I want to have the same scrolling as in Firefox, but at the moment it is in the opposite direction.
It is a little bit confusing, because I'm scrolling first to the wrong direction, then I realize it is the opposite,
so I always do two operations instead of just one.

Inverse scrolling for both kinds of scrolling ?

[oBFusCATed]

Yes, also the scrolling of the active editor could have an option to enable/disable wrapping

[oBFusCATed]

Hm, I think, I've solved the tooltip steeling focus bug.
The problem seems to be in the wxWidgets, more specifically in the constructor of wxTipWindow.
Replace the line 120 in tipwnd.cpp from:

Code

           : wxPopupTransientWindow(parent)

To:

Code

           : wxPopupTransientWindow(parent, wxBORDER_NONE|wxWANTS_CHARS)

I've not talked with the wx guys, nor have I tested it thoroughly...

[nanyu]

I have a "half finished" work about "tab on left/right".
Is the code useful?
sorry for my english, let's see a image:

[Jenna]

Hm, I think, I've solved the tooltip steeling focus bug.
The problem seems to be in the wxWidgets, more specifically in the constructor of wxTipWindow.
Replace the line 120 in tipwnd.cpp from:

Code

           : wxPopupTransientWindow(parent)

To:

Code

           : wxPopupTransientWindow(parent, wxBORDER_NONE|wxWANTS_CHARS)

I've not talked with the wx guys, nor have I tested it thoroughly...

I'm not at home this week (and the next two weeks also), but I will test it theis evening in the hotel or at one of the weekends.
It would be really great  if that can fix it.