Opened 18 years ago

Closed 17 years ago

Last modified 17 years ago

#716 closed bug (fixed)

StyledEdit: selecting, selecting fonts

Reported by: kutspam@… Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/StyledEdit Version:
Keywords: Cc: diver
Blocked By: Blocking:
Platform: All

Description (last modified by axeld)

rev 18081

Start SE, type text select it, go to font menu, marked text won't be marked anymore. It seems that selecting text in SE and selecting diff fonts won't change the text's font sometimes, especially when font sub menu is already selected.

What is this sub menu selection marking, why is 1st (roman) type marked selected by default?

alt-a works more reliable but not entirely sure.

Can't start 2nd SE

Change History (9)

comment:1 by diver, 18 years ago

Cc: diver added

comment:2 by axeld, 18 years ago

Component: ApplicationsApplications/StyledEdit
Description: modified (diff)
Owner: changed from sikosis to axeld
Platform: All

comment:3 by humdinger, 17 years ago

I'm not sure this is related, but...

  • Open a text file in StyledEdit.
  • Select a word that will be (at least partly) obscured by a menu when it's invoked.
  • Click on that menu, that will (partly) obscure the selected word, e.g. "Font".
  • Now, instead of selecting a menu item, you cancel by clicking either into the text or somewhere else, e.g. the empty menubar.

--> The selected word keeps looking selected (inverted colours) even though it really isn't. Try block-selecting the whole paragraph with that word in it.

This artefact only disappears when you redraw the view, e.g. by reisizing the window or waving another in front of it.

comment:4 by humdinger, 17 years ago

Another selection bug: Go to e.g. line 5 and keep selecting by holding the shift key while hitting the cursor-up key. When you reach line 0 everything gets deselected.

in reply to:  4 comment:5 by jackburton, 17 years ago

Replying to humdinger:

Another selection bug: Go to e.g. line 5 and keep selecting by holding the shift key while hitting the cursor-up key. When you reach line 0 everything gets deselected.

This is a different bug, and it's been fixed in hrev20997. But thanks for reporting, anyway.

comment:6 by humdinger, 17 years ago

The thing I've reported is fixed with stippi's r21867.

I don't quite understand everything the original poster wrote, but at least the selected text still isn't kept marked selected when invoking a menu.

comment:7 by stippi, 17 years ago

Resolution: fixed
Status: newclosed

There might be some selecting bugs in BTextView which are reported here in the comments, please open separate bug reports for those. At least the original bug is fixed in hrev21867.

in reply to:  6 ; comment:8 by jackburton, 17 years ago

Replying to humdinger:

The thing I've reported is fixed with stippi's r21867.

I don't quite understand everything the original poster wrote, but at least the selected text still isn't kept marked selected when invoking a menu.

It's not kept marked, because the textview loses focus (and the menubar does get it). As soon as the menu window closes, though, the text is highlighted again.

in reply to:  8 comment:9 by humdinger, 17 years ago

Replying to jackburton:

It's not kept marked, because the textview loses focus (and the menubar does get it). As soon as the menu window closes, though, the text is highlighted again.

Right. Question is, wouldn't it be better to keep the selection marked the whole time? Then you could recheck if everything you want is really selected while looking for the right menu entry... One thing I often do: I mark the interesting paragraph of eg. a helpfile, move the window side-by-side to the described app and do a step-by-step.

Note: See TracTickets for help on using tickets.