LB Booster
IDE and Compiler >> Integrated development environment >> Limitations of Syntax Coloring
http://lbb.conforums.com/index.cgi?board=ide&action=display&num=1473194176
Limitations of Syntax Coloring
Post by Richard Russell on Sep 6th, 2016, 8:36pm

This has been discussed before, but it has come up again in a private email so I thought it might be helpful once again to explain it.

The way I have bolted Syntax Coloring onto the Windows Rich Edit control relies on knowing what font the control is using to render the text. Normally this is straightforward - it is the font selected in the LBB 'Options... Set Font...' dialog - but there is a complication that arises if that selected font doesn't contain every character needed.

In that circumstance the Rich Edit control automatically substitutes a character from an alternative font that does include the character. Unfortunately that breaks the Syntax Coloring because it assumes the same font is used everywhere. The result is a real mess: the colored text doesn't line up with the uncolored text!

A classic situation in which this issue manifests itself is if you select FixedSys as the editor font. FixedSys is not a TrueType font: it's a non-scalable bitmapped font. But more importantly it's not a Unicode font, and includes only the basic ANSI 8-bit character set. So if you attempt to display a foreign-language (e.g. accented) character from a little-used character set - the case in point was Turkish - it is very likely that a font substitution will take place and the Syntax Coloring will fail.

There are only two ways of avoiding this problem: the first is to disable Syntax Coloring and the second is to select a font that includes every character you might need. Fortunately selecting a Unicode font and enabling Unicode Support in the Options menu is likely to satisfy the second of these. Add %options unicode to your program too.

Richard.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 17th, 2016, 11:02pm

I still think it is something else because FixedSys font contains Turkish characters.

If you go to Liberty Basic Font Selection Dialog for choosing Editor Font you can see that there is an option called "Script" and in this we can see Turkish exists for FixedSys. In some other fonts there are even richer national language support.

However, I have a font called "Elephant" and this font only supports "Western" and yes I know the effect of font substitution for this font.

I am very picky about fonts and not only here I observe these behaviour. Usually, when a silly office boy or girl makes an ugly PowerPoint presentation with one of these childish decorative fonts this issue shows it's face.

But, it is a different case here. There is no need for font substitution. We see the proper Turkish characters between quotes for a long time in the source code but at some undetermined time or condition it gets messed up. So, the question is when there is no need for font subsitution why does RichEdit messes up. I have seen different versions of this mess up. One of them is changing 0x20 space characters to Point Size 1 and thus words looses whites spaces between them. Also, after this point editing becomes impossible as cursor movements and insertion points becomes erratic. Probably because of font size change happened out of control the graphic system looses coordinates of characters on the screen.

This really happens. On many different hardware and Windows versions.
As I was evangelising LBB to my colleagues and put my code on their machines to show how good LBB is, several times I got stumped by this odd behaviour. As I was showing the source code on their machine by
going down with Page Down after some lines the code becomes garbled beyond recognition. Since then I am trying to pinpoint what causes this.
Probably, RichEdit is trying to make some unsuccesful and unnecessary
font substitution at Turkish Characters.

Obviously, there is something wrong with the RichEdit Control. As I sent you an example from Alyce's RichEdit example the Turkish Content existed fine inside for most of the cases. However, when I marked a part of the text and gave change font command that also misbehaved but strangely enough in that case Turkish Characters changed to FixedSys but other characters couldn't.

I think RichEdit control is buggy about this Font Culture settings. It can not handle them when you make various actions.

I believe that this is a never ending saga from Microsoft. For example,
in Word I have a document which originally came from someone whose Windows and Word is Arabic. Whatever inside hidden and unvisible I can not change it behave left to right as it insists on working right to left. This is on a simple, basic Times New Roman font.

Anyway, I just can not understand how Microsoft made some simple things so difficult and able to produce megabytes of .DOC fiies from few pages of text. When I look inside with a hexeditor such .DOC files my stomach turns upside down.

So, I changed to Courier New and replaced all TR characters with nearest UK unaccented characters and doing my big software conversion. After this, I haven't observed this odd behaviour. And, I agree that whatever it is coming from RichEdit.

On the other hand, this problem never happened in LB which you said using some other text editor library.

Anyway, I can live with it. No need to dwell on this but maybe some other LBB users may have encountered such oddities with their national character sets. In fact, TR character set is a Latin set with 6 additional
accented characters Ş ş İ ı Ğ ğ plus Ç ç Ö ö Ü ü written left to write. Not like Greek, Cyrillic, Arabic, Hebrew, Chinese, Korean or Japanese. It shouldn't cause a mess this easily with Rich Edit.

Re: Limitations of Syntax Coloring
Post by Richard Russell on Sep 18th, 2016, 09:33am

on Sep 17th, 2016, 11:02pm, CryptoMan wrote:
I still think it is something else because FixedSys font contains Turkish characters.

It depends on the Code Page. You previously told me that you were carrying out the test on a UK/US standard PC, i.e. a PC configured for Code Page 1252. In that case FixedSys (which is not a Unicode font) definitely does not contain Turkish characters!

You can run this simple test program to find out which Code Page you are using:

Code:
    %options ansi
    open "Code Page Test" for text as #w
    #w "!font Arial 24"
    #w chr$(222)
    wait

If you see the Icelandic Thorn character Þ then you are (probably) using Code Page 1252.
If you see the Turkish S-cedilla character Ş then you are using Code Page 1254.

Quote:
This really happens. On many different hardware and Windows versions.

So you say, but you have failed to provide any evidence in the form of a screenshot. If I was reporting a problem with fonts displaying incorrectly the very first thing I would do is to press Alt+PrtSc to grab an image of the window! Rather than doing this you try to explain the problem in words.

Quote:
In fact, TR character set is a Latin set with 6 additional accented characters Ş ş İ ı Ğ ğ plus Ç ç Ö ö Ü ü .... It shouldn't cause a mess this easily with Rich Edit.

I agree that it should not cause a problem with a Unicode font (and with Unicode Support selected in the LBB options menu) and I have not seen any evidence that it does. However with a non-Unicode font like FixedSys then of course it will cause a problem because the standard UK/US Code Page does not contain those characters and the Rich Edit control will be forced to do a font substitution.

Richard.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 18th, 2016, 10:39am

OK, here is more about this.

I have made very easy repeatable case but before that let me make some remarks about the Font Selection Dialog where Script is shown.

Yesterday, I told you that LB Editor Font Selection on laptop indicates "Turkish" for FixedSys font. I checked most of the fonts there and most except some decorative fonts are all supporting "Turkish" character rendering.

Please, also remember that I am not complaining about a cosmetic issue like seeing Icelandic Thorn instead of S-cedilla. It is a more dramatic problem.

However, as I told you before, I bought a brand new ACER Windows 10 loaded with US/UK Windows. In fact, my previous LENOVO Yoga 2 was purchased from BEST BUY in California, USA. So, that was infact US Windows as good as it gets but that Windows 8.1 LENOVO was violated by Microsoft with numerous updates and eventually drivers ruined by the fateful Windows 10 upgrade. During Windows updates I noticed that Microsoft is deciding by itself what is best fit for you and I suspect it might have Turkishized some parts of the Win 10 upgrade.

So, to clear any doubts, I got a brand new US/UK Windows 10 with no
Turkish settings and started working with it admittedly with my favourite font FixedSys which works just fine with most other software.

Anyway, I checked the Editor Font Selection on my old LENOVO PC yesterday after seeing your post and saw my font showed "Turkish" a.k.a. Code Page 1254 in Script selection instead of "Western" a.k.a. Code Page 1252.

This morning I sat down on my new PC and wanted check what LBB says for Script vs LB. I noticed both were saying "Western" and there was no "Turkish" on the Script selection.

However, even at this point, without any involvement of Turkish characters it was showing the odd behaviour which is very easy to replicate.

Choose FixedSys font with Script=Western or Turkish. I can email you the Turkish FixedSys if you want but this is not really necessary to observe what I am trying to illustrate.

1) Select Editor Font FixedSys.

2) Start typing test$="ABCDEF and until you close the quotes LBB editor does not start using the FixedSys font.

3) When you close the quote only "ABCDEF" is rendered into FixedSys which I believe due to Syntax Colouring but test$= remains whatever font it started with.

4) I noticed that syntax coloured keywords are changing to FixedSys but others remaining with the other font.

You can try this simple example and see the effect.

I hope that you can replicate and I can be sure that I am not hallucinating and the only one to observe this problem.



Re: Limitations of Syntax Coloring
Post by Richard Russell on Sep 18th, 2016, 10:57am

on Sep 18th, 2016, 10:39am, CryptoMan wrote:
Please, also remember that I am not complaining about a cosmetic issue like seeing Icelandic Thorn instead of S-cedilla.

It seems you are having difficulty grasping what Code Pages are and how they work. I had hoped that my Thorn versus S-cedilla example would help you understand.

Quote:
1) Select Editor Font FixedSys.
2) Start typing test$="ABCDEF and until you close the quotes LBB editor does not start using the FixedSys font.

I cannot reproduce that. Typing 'test$="ABCDEF' renders the text in FixedSys from the start: even the initial character "t" is rendered in FixedSys. The only thing that happens when the quotes are closed is that the Syntax Coloring changes the quoted string to magenta.

Quote:
You can try this simple example and see the effect.

I tried your simple example: I did not see the effect.

Can I ask that other users also try the test and report back their results. If you select the editor font as FixedSys and then start typing, does it render the characters using the FixedSys font from the very start or not?

Richard.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 18th, 2016, 11:10am

Let me add a few more comments.

If you turn off Syntax Colouring and Select FixedSys LBB editor never renders the fonts with FixedSys.

With syntax colouring this problem happened with US/UK ASCII characters and therefore is nothing to do with Turkish.

As I told you before it was never a font substitution problem or Unicode problem. Turkish fonts really doesn't need Unicode. At worst, we will see Icelandic Thorns and when that appears we know how to fix it by finding the correct font file or modifying a a Western fonts with a font editor.

Most probably, this is a Rich Edit bug.

But the question is why LBB Editor is not starting by using the choosen Editor font FixedSys?

I agree RichEdit is bombing when you ask it do find and replace font changes but a source code editor is not a Word Processor and will work with only one font. Only need for RichEdit is for syntax colouring. The font and character size should remain the same all through the text.

And, I have seen this odd behaviour even in the earlier versions of LBB without any syntax colouring with font's are changing to strange fonts and sometimes italic. I think the RichEdit control is loosing track of atribute information of characters due to reasons which I don't know.

I haven't studied the internal logic of RichEdit. Most probably, there is a linked list of pointers indicating position of font atribute changes and as the text gets bigger and bigger; and with insertions and deletions in the text memory map probably corresponding updates on the atributes list looses it at certain points and the mess starts.

If you remember the original IBM PC screen memory map at 0xB000
for monochrome and 0xB800 for colour displays each character was represented as two byte, first byte the character and second by the character atribute: color,underline,bold,etc. That's probably a wasteful strategy for large documents but really does Microsoft care about any efficiency these days?

The other strategy could be the ANSI.SYS or VT100/VT220 method with Esc[nnn for causing atribute change. These were working just fine in those days.

Anyway, this issue is wasting too much of your time and my time.
Let's switch to Courier New and hope Rich Edit behaves better with one of those proper fonts.
Re: Limitations of Syntax Coloring
Post by Richard Russell on Sep 18th, 2016, 11:14am

on Sep 18th, 2016, 11:10am, CryptoMan wrote:
But the question is why LBB Editor is not starting by using the choosen Editor font FixedSys?

It is, for me. Let's await the reports of other users.

Quote:
Turkish fonts really doesn't need Unicode. At worst, we will see Icelandic Thorns and when that appears we know how to fix it

That statement is wrong, or at least highly misleading, as I have explained so many times.

Richard.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 18th, 2016, 11:20am

Just to eliminate any doubts on Keyboard settings, I changed it to English (US) Keyboard and it is the same. It does not start with FixedSys.
Re: Limitations of Syntax Coloring
Post by Richard Russell on Sep 18th, 2016, 11:24am

on Sep 18th, 2016, 11:20am, CryptoMan wrote:
Just to eliminate any doubts on Keyboard settings, I changed it to English (US) Keyboard and it is the same. It does not start with FixedSys.

You said this was wasting too much time. I agree, so please let us wait for reports from other users so we can determine whether this is something peculiar to your setup or a more general issue. I hope not to see any more posts from you until then, thanks.

Richard.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 18th, 2016, 11:31am

I went to my old Lenovo and choose FixedSys and it does start with FixedSys.

On that machine FixedSys have only Turkish Script but the new machine has both Western and Turkish.

I will now erase one of them and see if this is the cause.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 18th, 2016, 11:36am

Windows refuses to erase FixedSys so I couldn't try this.

But, I tried with a similar font Terminal which has only one script OEM/DOS and it does start rendering with terminal.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 18th, 2016, 11:40am

In fact, when it works in the old Lenovo, as soon as type " syntax colouring starts.

In the new machine syntax colouring happens when I close the quote.

Why is these different behaviours happening?
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 18th, 2016, 11:48am

Old Lenovo is Windows 10 Home Edition
New Acer is Windows 10 Home Single Language

Yes, this is really a time waster and let's see if anybody else have seen anything like this.

Thanks for your patience.
Re: Limitations of Syntax Coloring
Post by tsh73 on Sep 19th, 2016, 06:37am

Her's what I got on Win XP prof SP3
(LBB version still 3.02 but I think it doesn't changed here)
http://s21.postimg.io/3zvqvn7yf/Syntax_Coloring_Fixedsys.gif

User Image

If I switch to Lucida Console font stays consistent (looks Lucida Console )

But syntax coloring was turned off to me. I will put it on and see if I see anything wrong.
Re: Limitations of Syntax Coloring
Post by tsh73 on Sep 19th, 2016, 07:03am

Aha.
So I went on reading "pressing ESC aborts the program" thread

and pasted piece of code from reply #23, this one
Code:
    htb = hwnd(#w.tb)
    calldll #user32, "GetWindowLongA", htb as ulong, _
      _GWL_STYLE as long, style as long
    print dechex$(style)

Pasted from Internet Explorer 8 (it happens pasting from Google Chrome works normally with/without syntax coloring!)

Now that I've got:
with syntax coloring on I got single line, syntax colored, of different font size, obviously garbled (some "(" not visible)
first word is Russian for "Normal" - have no idea where it gets from
(Last vertical line is text cursor)

If I turn off syntax coloring, this line gets same font size, but still as a single line it won't compile even after removing extra first word.

Now if I paste same thing with syntax coloring off it appears normal, compiles too
User Image
Still somehow pasted text font looks smaller.

so I'll turn it off for a while.

EDIT: that was Internet Explorer 8
From Google Chrome it works as supposed too, everything is fine.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 19th, 2016, 1:20pm

@tsh73: I can see you images. The linked web site is unreachable.
Re: Limitations of Syntax Coloring
Post by tsh73 on Sep 19th, 2016, 1:45pm

Quote:
@tsh73: I can see you images. The linked web site is unreachable.

It was postimage.org
Now let's try with photobucket:
User Image

User Image

Re: Limitations of Syntax Coloring
Post by Rod 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 ".
Re: Limitations of Syntax Coloring
Post by Jack Kelly 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.
Re: Limitations of Syntax Coloring
Post by CryptoMan 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.
Re: Limitations of Syntax Coloring
Post by Rod on Sep 21st, 2016, 5:45pm

To be clear FixedSys font worked perfectly ok for me. Also the entire text adopts the selected font.
Re: Limitations of Syntax Coloring
Post by Richard Russell 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.
Re: Limitations of Syntax Coloring
Post by tsh73 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
Re: Limitations of Syntax Coloring
Post by Richard Russell 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.
Re: Limitations of Syntax Coloring
Post by Richard Russell 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.

User Image
Re: Limitations of Syntax Coloring
Post by tsh73 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.
Re: Limitations of Syntax Coloring
Post by tsh73 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.
Re: Limitations of Syntax Coloring
Post by Richard Russell 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.
Re: Limitations of Syntax Coloring
Post by Richard Russell 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.
Re: Limitations of Syntax Coloring
Post by tsh73 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.
Re: Limitations of Syntax Coloring
Post by Richard Russell 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.
Re: Limitations of Syntax Coloring
Post by Richard Russell 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.
Re: Limitations of Syntax Coloring
Post by tsh73 on Sep 25th, 2016, 2:20pm

Hello Richard
it happens that I have previous versions of LBB saved on a harddisk
so I can check.

So: Sintax coloring with richtextbox appeared in version 3.0
Versions 3.0, 3.01,3.02,3.03 - language switching with Alt-Shift works
Versions 3.04,3.05,3.06 - language switching with Alt-Shift no more work.

So it is something introduced in version 3.4.
May be this?
Quote:
IDE enhancements:
The IDE now incorporates a combobox in which are listed all the branch labels, SUBs and FUNCTIONs in the currently loaded program. Selecting one of these causes the editor to jump directly to the appropriate program line. You can choose whether to sort the list alphabetically or in the order in which the items appear in the program.

Re: Limitations of Syntax Coloring
Post by Richard Russell on Sep 25th, 2016, 3:44pm

on Sep 25th, 2016, 2:20pm, tsh73 wrote:
So it is something introduced in version 3.4.

Well, the first thing to say is that Alt+Shift works here in LBB 3.06: If I press that key combination the language indicator in the Taskbar switches between 'ENG' and 'ENG US'. So whatever the problem is, it is not universal.

The change in v3.04 that affected your system was probably running the Rich Edit control in a separate thread in order to improve the support for Unicode, particularly the entry of complex script languages like Arabic. Up to version 3.03 the control was run in the same thread as the rest of the IDE.

As you will appreciate, I would not want to reverse that change - users who need support for Arabic (like SarmedNafi) would not be happy! Running the Rich Edit control in a separate thread also improves performance with multi-core CPUs. In any case there is no good reason why it should affect hotkeys.

So all things considered, and especially given that Alt+Shift works perfectly here in LBB 3.06, I am not contemplating making any changes.

Richard.
Re: Limitations of Syntax Coloring
Post by Richard Russell on Sep 25th, 2016, 4:02pm

on Sep 25th, 2016, 3:44pm, Richard Russell wrote:
Well, the first thing to say is that Alt+Shift works here in LBB 3.06

Just checked it on my other machines: the Alt+Shift language switching is working perfectly in LBB 3.06 with Windows 7, Windows 8.1 and Windows 10.

Richard.
Re: Limitations of Syntax Coloring
Post by tsh73 on Sep 25th, 2016, 5:20pm

Checked on another my machine and another virtual one, LBB 3.06.
Alt-shift works.
So it dosn't work only with my main home pc.
Ah well. I could live with it.
EDIT
and on my job PC it does't work as well.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 26th, 2016, 2:49pm

Fixedsys Excelsior works fine with Turkish.

Thanks.
Re: Limitations of Syntax Coloring
Post by CryptoMan on Sep 26th, 2016, 2:51pm

Alt-Shift works properly with Turkish Keyboard Windows 10.
Re: Limitations of Syntax Coloring
Post by Richard Russell on Sep 26th, 2016, 3:40pm

on Sep 25th, 2016, 5:20pm, tsh73 wrote:
Ah well. I could live with it.

Nevertheless the inconsistent behaviour is strange and annoying. Even though I keep several different PCs here, with different versions of Windows and different setups in other respects (a better test than using VirtualBox IMHO), I still can't hope to check every possible configuration.

It's evidently not just an LBB problem either; if you Google for 'Alt+Shift not working' there are many hits. You can change the hotkey (in Windows 10 it's under 'Control Panel... Clock, Language and Region... Language... Advanced settings... Switching input methods... Change language bar hot keys') so it's possible an alternative key combination might work more reliably.

Richard.
Re: Limitations of Syntax Coloring
Post by bluatigro on Sep 30th, 2016, 12:42pm


i wood like to have numbers a differend color
then the other stuf
and array's and function's too

explanation :
i have a eye-problem and have
difecultys whit 1's,l's and I's
Re: Limitations of Syntax Coloring
Post by Richard Russell on Sep 30th, 2016, 2:51pm

on Sep 30th, 2016, 12:42pm, bluatigro wrote:
I wood like to have numbers a differend color

Parsing numbers accurately is tricky, since there are so many different formats (leading minus sign, decimal point, exponent etc.). LBB's syntax coloring uses simple rules that can't easily be extended to numbers.

Quote:
i have a eye-problem and have difecultys whit 1's,l's and I's

Unfortunately coloring numbers differently won't always solve this problem. Consider these two variable names:

Code:
    ba11 = 123
    ball = 123

The first is ba followed by the number eleven and the second is the word ball but they are almost identical, even to somebody with good eyesight! Because neither of them is a number they would not be colored differently even if LBB supported that feature, and they are not colored differently either in LB 4 or in Liberty BASIC Workshop.

So you could try using LBW (it interfaces very nicely with LBB; there are instructions here) but syntax coloring is not a complete solution to the problem.

Richard.

Re: Limitations of Syntax Coloring
Post by net2014 on Dec 13th, 2017, 2:41pm

Although I have been using LBB for quite a long time now, I have only just discovered that the syntax colouring problem manifests itself in the same way when LBB is run with linux/wine. My language setting is English-UK and many fonts tried. My programs do not contain any foreign characters. Whether that helps or not I don't know, but I am not expecting a solution - I can live without colouring as I obviously have done for some time! Just thought I would add to the gathered knowledge. smiley
Re: Limitations of Syntax Coloring
Post by Richard Russell on Dec 13th, 2017, 5:24pm

on Dec 13th, 2017, 2:41pm, net2014 wrote:
I have only just discovered that the syntax colouring problem manifests itself in the same way when LBB is run with linux/wine.

You refer to "the syntax colouring problem" as if it is something well-known and common, but the 'problem' discussed in the earlier posts of this thread manifests only in very rare circumstances, as I have explained. I should perhaps delete those posts in which the issue was misunderstood and misrepresented.

To reiterate, it occurs only when Windows performs a 'font substitution', which can happen when your program contains a character that is not available in the currently selected font. You can often avoid it altogether by selecting a font with a wide coverage of Unicode glyphs (don't choose 'FixedSys' which is particularly poor in this respect; note the reference to 'FixedSys Excelsior' as a possible alternative).

There is nothing I can do about the rare occasions when it does misbehave, because the Rich Edit control does not notify the host program that a font substitution has taken place.

Syntax coloring works perfectly for me, and for most other users as far as I know.

Richard.