Author |
Topic: Limitations of Syntax Coloring (Read 3165 times) |
|
Rod
Full Member
member is offline
Gender: 
Posts: 110
|
 |
Re: Limitations of Syntax Coloring
« Reply #17 on: Sep 19th, 2016, 6:46pm » |
|
I am on Win10 in Europe and cannot see the problem. Every font change is instant and the font is consistent no matter what font I pick. The syntax colour always kicks in on pressing the second ".
|
|
 Logged
|
|
|
|
Jack Kelly
Full Member
member is offline
Gender:
Posts: 106
|
|
Re: Limitations of Syntax Coloring
« Reply #18 on: Sep 20th, 2016, 11:17am » |
|
My observations agree with Rod's. There are no quirky problems with fonts on my PC. But I don't try to use any national character sets, or anything beyond plain vanilla. Courier_New bold 18 is just fine on my system.
|
|
Logged
|
|
|
|
CryptoMan
New Member
member is offline
Gender:
Posts: 46
|
|
Re: Limitations of Syntax Coloring
« Reply #19 on: Sep 21st, 2016, 4:34pm » |
|
tsh73 is replicating my problem exactly as I observe it.
The problem starts with FixedSys font. So, if others are trying with other fonts they may not see it.
When I start with FixedSys the problem starts immediately and eventually gets very bad and the source code becomes completely uneditable.
It is not really related to national fonts. Originally, I thought that was the reason but it is not. First of all, my FixedSys font has Script=Turkish and thus have all of the necessary additional fonts and thus RichEdit have no reason at all to substitute fonts on the assumption that additional fonts are not existing and thus it tries to find another font. It is already happening with just test$="ABCDE" very simple UK/US ASCII characters. In fact it starts with test$=" in Arial as TSH73 also observed and as soon as the quotes closed it turns into test$="ABCDE"
whatever inside quotes turns to FixedSys but test$= remains Arial. After this point RichEdit thinks the font is Proportional Arial but some of it is FixedSys with different characters and thus cursor position is now incorrectly calculated and the source editing becomes impossible.
I have also see 0x20 space characters becoming 1 or 0 pixel size and thus white spaces dissappear.
And, on a Windows 2012 Server have seen it got even worse. I have seen this on many different machines but as I understand some maybe most people are not seeing this problem.
I changed to work with Courier New or Consolas now and so far I have not seen this problem with these fonts. So, I can do without FixedSys and live with Courier.
At least from TSH73 message, some other people also have seen what I have been seeing.
|
|
Logged
|
|
|
|
Rod
Full Member
member is offline
Gender:
Posts: 110
|
|
Re: Limitations of Syntax Coloring
« Reply #20 on: Sep 21st, 2016, 5:45pm » |
|
To be clear FixedSys font worked perfectly ok for me. Also the entire text adopts the selected font.
|
| « Last Edit: Sep 21st, 2016, 5:46pm by Rod » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #21 on: Sep 21st, 2016, 6:30pm » |
|
on Sep 21st, 2016, 4:34pm, CryptoMan wrote:| my FixedSys font has Script=Turkish and thus have all of the necessary additional fonts and thus RichEdit have no reason at all to substitute fonts |
|
I don't know how many times I must keep repeating this, but that is not correct. Your statement is based on a naïve assumption about the way font substitution works, which is not how it works in practice. I do not know exactly the rules that Rich Edit uses but they are quite obviously not what you describe.
I do not understand why you are so resistant to accepting that the most straightforward explanation is actually the right one. Both you and Anatoly have reported that when you select FixedSys the Rich Edit control is substituting a different font from the start. Yet somehow you want to believe that it is not a font-substitution issue!
Quote:| I changed to work with Courier New or Consolas now and so far I have not seen this problem with these fonts. |
|
Courier New and Consolas are Unicode fonts which have all the characters that are needed for Russian, Turkish and most other languages, therefore the Rich Edit control has no need to perform any substitutions. In contrast the FixedSys font is not a Unicode font and substitutions may be required.
It is certainly interesting that the Rich Edit control is using a substitute font from the start, even when it is not strictly necessary. I don't know the precise reason for that, but it may be to prevent mixing different fonts in the same paragraph which could be ugly. Irrespective, it doesn't alter the basic issue.
I am glad you have found a solution that you are happy with, but I feel I should point out that I told you about that solution (using a Unicode font rather than FixedSys) a long time ago!
Richard.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Limitations of Syntax Coloring
« Reply #22 on: Sep 21st, 2016, 6:39pm » |
|
I wonder if this depends on richtextbox control version, which might be depending on Windows version?
Here on XP home SP3 sysinternals process explorer shows that LBB loaded
windows\system32\riched20.dll
version 5.30.0023.1230
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #23 on: Sep 23rd, 2016, 08:41am » |
|
on Sep 21st, 2016, 6:39pm, tsh73 wrote:| I wonder if this depends on richtextbox control version, which might be depending on Windows version? |
|
Although there are certainly several different versions of the Rich Edit control, I don't think that's a likely cause of the anomaly. I still believe that the underlying issue is the PC's language selection.
There are several different ways in which a PC can be configured for different locales, among which are the keyboard layout, the default display language, the default Code Page and the input method. My guess is that based on some or all of these settings the Rich Edit control tries to determine whether the selected font contains all the characters that are likely to be required, and if not performs a font substitution.
Richard.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #24 on: Sep 23rd, 2016, 5:44pm » |
|
I notice that there is an 'unofficial Unicode extension' of the FixedSys font called Fixedsys Excelsior. If this works well it might make it possible to use FixedSys, or something very much like it, without triggering the font-substitution issue that has caused so much aggravation.
Perhaps somebody who has been experiencing the Rich Edit anomaly could try this font and report back on whether it fixes the problem. Here is the download link for the TTF file. As usual, once downloaded you should right-click on the file and select Install.
Richard.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Limitations of Syntax Coloring
« Reply #25 on: Sep 24th, 2016, 06:14am » |
|
Quote:Perhaps somebody who has been experiencing the Rich Edit anomaly could try this font and report back on whether it fixes the problem.
|
|
It looks like it fixes things for me.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Limitations of Syntax Coloring
« Reply #26 on: Sep 24th, 2016, 06:41am » |
|
Err...
Richard, does LBB IDE uses Alt-Shift for anything?
It is one of two common hotkeys for switching input language, in my case English/Russian
So while testing I found that in LBB 3.05 I can paste russian text, can switch language by mouse (by applet in system tray), but somehow I cannot switch language by pressing Alt-Shift.
I have separate folder with LBB 2.51 - and Alt-Shift switches language there.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #27 on: Sep 24th, 2016, 08:47am » |
|
on Sep 24th, 2016, 06:41am, tsh73 wrote:| does LBB IDE uses Alt-Shift for anything? |
|
No, but something strange is happening here (Windows 10 laptop) because if I press and release Alt - rather than using Alt+letter as a menu shortcut - it seems to freeze the LBB IDE. If that's happening to you too it may well impact on your hotkey.
I'm away from home at the moment so I can't investigate further, but that should definitely not be happening.
Richard.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #28 on: Sep 24th, 2016, 12:07pm » |
|
on Sep 24th, 2016, 06:41am, tsh73 wrote:| does LBB IDE uses Alt-Shift for anything? |
|
Further to my earlier reply, although LBB doesn't use Alt+Shift itself, Rich Edit controls do, and of course the LBB editing pane is a Rich Edit control. There is a list of keyboard shortcuts here and you will notice that it includes Alt+Shift+X, Alt+Shift+Ctrl+F11 and Alt+Shift+Ctrl+F12.
So it is possible that the Rich Edit control is intercepting your Alt+Shift hotkey and preventing it doing what it normally does. Probably Alt+Shift is a poor choice of hotkey if it is already used for other purposes in standard Windows components like the Rich Edit control.
Richard.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Limitations of Syntax Coloring
« Reply #29 on: Sep 24th, 2016, 4:15pm » |
|
Quote:| Probably Alt+Shift is a poor choice of hotkey |
|
It's default Windows language switching hotkey.
That mean bigger part of Russia and what not uses it on daily basis, at least since Windows 3x.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #30 on: Sep 24th, 2016, 9:19pm » |
|
on Sep 24th, 2016, 4:15pm, tsh73 wrote:| It's default Windows language switching hotkey. |
|
There's clearly an anomaly in Microsoft having used the same key combination as both a language-switching hotkey and as a modifier for some Rich Edit keyboard shortcuts. It's exactly the sort of thing they are usually careful to avoid.
I see that (from Windows 8 onwards anyway) you can use Windows+Space as a hotkey to bring up the language-selection menu, so I wonder if that might be a workaround for your issue. On this PC Windows+Space allows me to switch between a UK and US keyboard layout.
Richard.
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #31 on: Sep 25th, 2016, 12:45pm » |
|
on Sep 24th, 2016, 08:47am, Richard Russell wrote:| something strange is happening here (Windows 10 laptop) because if I press and release Alt - rather than using Alt+letter as a menu shortcut - it seems to freeze the LBB IDE. |
|
I've now had a chance to check this on other machines and the problem seems to be specific to this Windows 10 laptop. I've tested it on Windows XP, Windows 7, Windows 8.1 and a desktop Windows 10 PC and in every case pressing-and-releasing Alt works normally. So it doesn't seem likely that whatever is causing this problem is related to the Alt+Shift hotkey issue.
It has nevertheless been interesting to discover the keyboard shortcuts built into the Rich Edit control, a few of which could be genuinely useful in LBB. For example you can enter any character by typing its hexadecimal code value and then pressing Alt+X, so to enter a capital eth character you can type 00D0 followed by Alt+X giving Ð
Richard.
|
|
Logged
|
|
|
|
|
