Author |
Topic: Limitations of Syntax Coloring (Read 3150 times) |
|
Richard Russell
Administrator
member is offline
 
Posts: 1348
|
 |
Re: Limitations of Syntax Coloring
« Reply #33 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.
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #34 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.
|
|
 Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender: 
Posts: 210
|
|
Re: Limitations of Syntax Coloring
« Reply #35 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.
|
| « Last Edit: Sep 26th, 2016, 06:19am by tsh73 » |
Logged
|
|
|
|
CryptoMan
New Member
member is offline
Gender:
Posts: 46
|
|
Re: Limitations of Syntax Coloring
« Reply #36 on: Sep 26th, 2016, 2:49pm » |
|
Fixedsys Excelsior works fine with Turkish.
Thanks.
|
|
Logged
|
|
|
|
CryptoMan
New Member
member is offline
Gender:
Posts: 46
|
|
Re: Limitations of Syntax Coloring
« Reply #37 on: Sep 26th, 2016, 2:51pm » |
|
Alt-Shift works properly with Turkish Keyboard Windows 10.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #38 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.
|
|
Logged
|
|
|
|
bluatigro
Full Member
member is offline
Gender:
Posts: 111
|
|
Re: Limitations of Syntax Coloring
« Reply #39 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
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #40 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:
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.
|
|
Logged
|
|
|
|
net2014
New Member
member is offline
Posts: 37
|
|
Re: Limitations of Syntax Coloring
« Reply #41 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. 
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Limitations of Syntax Coloring
« Reply #42 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.
|
|
|
|
|
