Thread: Current CVS: Cursor disappears

Current CVS: Cursor disappears

From
Troels Arvin
Date:
Hello,

In the query window of current pgadmin3 CVS with wxGTK2ud v.
wxGTK2ud-2.5-20031010.5 on Red Hat Linux 9 (running GNOME; haven't tried
KDE):

Initially, a cursor is seen, but if focus is taken away from the window
(e.g. by using the mouse or ALT-TAB) and then returned, the cursor is
gone. I can still write charaters in the query window, but I have to
guess where the characters will be put.

If focus is once again taken away from and then returned to the query
window, then the cursor re-appears.

--
Greetings from Troels Arvin, Copenhagen, Denmark


Re: Current CVS: Cursor disappears

From
Jean-Michel POURE
Date:
Le Lundi 27 Octobre 2003 22:16, Troels Arvin a écrit :
> Initially, a cursor is seen, but if focus is taken away from the window
> (e.g. by using the mouse or ALT-TAB) and then returned, the cursor is
> gone. I can still write charaters in the query window, but I have to
> guess where the characters will be put.
>
> If focus is once again taken away from and then returned to the query
> window, then the cursor re-appears.

Dear Troels,

I can confirm this STC problem as I have exactly the same problem under Debian
and RedHat.

Sometimes also, in the editor, after selecting text, the cursor becomes the
following sign|_ (vertical and horizontal bar) and the display freezes. I
have to open a seperate display and manually kill pgAdmin3. Nothing is
written in the log.

Did anyone notice this bug too?

Best regards,
Jean-Michel


Re: Current CVS: Cursor disappears

From
Andreas Pflug
Date:
Jean-Michel POURE wrote:

>Le Lundi 27 Octobre 2003 22:16, Troels Arvin a écrit :
>
>
>>Initially, a cursor is seen, but if focus is taken away from the window
>>(e.g. by using the mouse or ALT-TAB) and then returned, the cursor is
>>gone. I can still write charaters in the query window, but I have to
>>guess where the characters will be put.
>>
>>If focus is once again taken away from and then returned to the query
>>window, then the cursor re-appears.
>>
>>
>
>Dear Troels,
>
>I can confirm this STC problem as I have exactly the same problem under Debian
>and RedHat.
>
>Sometimes also, in the editor, after selecting text, the cursor becomes the
>following sign|_ (vertical and horizontal bar) and the display freezes. I
>have to open a seperate display and manually kill pgAdmin3. Nothing is
>written in the log.
>
>Did anyone notice this bug too?
>
>
Yes, I've seen this. Still no idea what's happening.

Another weird detail:
If the query window is moved, caret disappears, moved again, caret is back.
This also happens with the official stctest, so it's a wx problem.

Regards,
Andras


STC Caret disappears

From
Andreas Pflug
Date:
Andreas Pflug wrote:

> Jean-Michel POURE wrote:
>
>> Le Lundi 27 Octobre 2003 22:16, Troels Arvin a écrit :
>>
>>
>>> Initially, a cursor is seen, but if focus is taken away from the window
>>> (e.g. by using the mouse or ALT-TAB) and then returned, the cursor is
>>> gone. I can still write charaters in the query window, but I have to
>>> guess where the characters will be put.
>>>
>>> If focus is once again taken away from and then returned to the query
>>> window, then the cursor re-appears.
>>>
>>
>>
>> Dear Troels,
>>
>> I can confirm this STC problem as I have exactly the same problem
>> under Debian and RedHat.
>>
>> Sometimes also, in the editor, after selecting text, the cursor
>> becomes the following sign|_ (vertical and horizontal bar) and the
>> display freezes. I have to open a seperate display and manually kill
>> pgAdmin3. Nothing is written in the log.
>>
>> Did anyone notice this bug too?
>>
>>
> Yes, I've seen this. Still no idea what's happening.
>
> Another weird detail:
> If the query window is moved, caret disappears, moved again, caret is
> back.
> This also happens with the official stctest, so it's a wx problem.
>
OK, finally, I found it:
For some reason, the control loses focus (probably to the frame) which
in turn has to give it back to the stc control. So I could fix this by
catching the frame's focus.
Since only every second time the focus falsely goes to the frame, there
might be some flaw in the wxTopLevelWindow focus handling code.

Regards,
Andreas