2 problems with function help/Code Completion

[Rosch]

Hi...

Today I spotted 2 problems with the function help/Code Completion (eg. when you hit CTRL+SPACE to complete a function you have started typing). I am running most recent Codelite from SVN (rev 5945) on windows 7 64bit.

Problem 1: Jumping yellow help box
When I type the beginning of of a symbol name and hit CTRL+SPACE the nice completion help pops up. One can scroll using the cursor keys. For the current highlighted element a yellow help box opens up showing some help extracted from headers. So far so good. BUT: Sometimes it jumps from the left to the right side of the main help box. (BTW: I am running in a dualscreen configuration maybe this problem has something to do with it.)

Example1: left of the box

CL_Help_left.png

Example2: right to the box

CL_Help_right.png

This is a "bit" distracting. Especially when you move with the cursor thru the main box. The yellow box always jumps from left to right and back. It appears to me that Codelite first tries to place the yellow box always left to the main box. Only if the place is too small it jumps to the right side. Wouldn't it be better to always open the yellow box in the bigger side of the main box - independant of left and right?

EDIT: I started to explore the code now. cc_box_tip_window first tries to place to the right if not possible go to the left. It appears that it is only "seeing" my left monitor not that the desktop also extends to the right screen.

Problem 2: Incomplete help shown
Sometimes it happens that the help extracted from the function header is cutted off.
This appears to be dependant on the string I try to complete.

Example 1:
In my case I type OVWebRocke<CTRL+SPACE>. This happens:

CL_Help_cuttoff.png

The help is cut off befor the description of the parameters.

Example 2:
In my case I type OVWebRocket_Add<CTRL+SPACE>. This happens:

The help is NOT cut off (Just the snapshot is cut off here in the forum).
Why is this happening? Why is it depending on the text I try to complete?

Thanks for your help,

Roland

[Rosch]

Regarding problem one: The "jumping" CodeCompletion Tip windows...

When reading the code I have seen that there is already some dual head code in CCBox::Display().
When I copy this code to CCBoxTipWindow::PositionRelativeTo() then this also stops the jumping of the tip windows in my case.

I have taken a look at what wxWidget does on display management. I fear that there might be some potential of problems in regard of dual head. On windows when you have 2 monitors and you specify the right monitor as the primary monitor it can happen that you get negative screen coordinates for the left monitor (which are perfectly legal and visible in this case). Will do a test at some time. Additionally the code in CCBox takes the asumption that the display are always extending to the right which can also cause trouble in case of the coordinates go negative.

Hmmm... Shall I formulate my local change as a patch to stop this jumping in case there is a second screen? It copies behaviour of CCBox. Or might it anyway be the better solution to ALWAYS show the tipwindows right to the CCBox (to disable the jumping to the left at all)?

Roland

[eranif]

Regarding problem one: The "jumping" CodeCompletion Tip windows...

When reading the code I have seen that there is already some dual head code in CCBox::Display().
When I copy this code to CCBoxTipWindow::PositionRelativeTo() then this also stops the jumping of the tip windows in my case.

This is because, codelite checks where it can place the tooltip and it will be shown properly (if it jumps to the left, it means that if codelite would have placed it on the right, it will be truncated by the screen size)

Or might it anyway be the better solution to ALWAYS show the tipwindows right to the CCBox (to disable the jumping to the left at all)?

No - as it should jump as it does now. A patch for dual screens is welcomed. But when using single screen it works as expected

Eran

[Rosch]

Or might it anyway be the better solution to ALWAYS show the tipwindows right to the CCBox (to disable the jumping to the left at all)?

No - as it should jump as it does now. A patch for dual screens is welcomed. But when using single screen it works as expected

Eran

So here is the patch to avoid unneeded jumping of the tip window on dualscreen. It is the same code which is also used in cc_box.cpp.

cc_box_tip_window.patch

Regarding the second problem (the cutoff comments). Do you have any clue where this could come from?

Roland