Opened 13 years ago

Closed 12 years ago

Last modified 12 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:
Has a Patch: no 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 Changed 13 years ago by diver

Cc: diver added

comment:2 Changed 13 years ago by axeld

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

comment:3 Changed 12 years ago by humdinger

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 Changed 12 years ago by 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.

comment:5 in reply to:  4 Changed 12 years ago by jackburton

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 Changed 12 years ago by 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.

comment:7 Changed 12 years ago by stippi

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.

comment:8 in reply to:  6 ; Changed 12 years ago by jackburton

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.

comment:9 in reply to:  8 Changed 12 years ago by humdinger

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.