Recent posts

#31

PlanetSquires Software / Tiko - new Format dialog

Last post by Paul Squires - August 02, 2026, 12:23:06 PM

New feature to "prettify" or "beautify" a code line, a document, all open documents, or all documents in a project.

Screenshots in this post:  https://www.planetsquires.com/protect/forum/index.php?topic=4872.msg36783#msg36783

#32

PlanetSquires Software / Re: Some Personal Notes on Cod...

Last post by Paul Squires - August 02, 2026, 12:21:28 PM

Here is the other screenshots

#33

PlanetSquires Software / Re: Some Personal Notes on Cod...

Last post by Paul Squires - August 02, 2026, 12:20:54 PM

The new Format functionality is now implemented. Looks good and seems to work well from my initial testing.

I have attached some screenshots.

#34

PlanetSquires Software / Re: Some Personal Notes on Cod...

Last post by Paul Squires - August 02, 2026, 12:14:40 PM

However, I am attempting to modify the scintilla lexer to allow ProperCase (ie Mixed Case) correctly. This has long been a sore point that I receive messages on. Will be nice to finally have it work correctly.

This is now fixed (finally!). The Scintilla and Lexilla sources have been modified along with Tiko's built in lexer to load keywords using ProperCase format. So, now all casing can work correctly: lowercase, UPPERCASE, ProperCase, and of course original case.

#35

PlanetSquires Software / Re: Some Personal Notes on Cod...

Last post by Paul Squires - August 02, 2026, 10:45:14 AM

Because of this, any automatic formatting feature in Tiko should be optional and user‑configurable.

I agree 100%. The formatting options dialog that I am working on now is opt-in by the user. It will allow formatting the current line (after ENTER), format the current document, all open documents, or all documents in a project.

I also only use Original Case.

However, I am attempting to modify the scintilla lexer to allow ProperCase (ie Mixed Case) correctly. This has long been a sore point that I receive messages on. Will be nice to finally have it work correctly.

#36

PlanetSquires Software / Re: Some Personal Notes on Cod...

Last post by José Roca - August 02, 2026, 09:27:50 AM

Your formatting notes are interesting and certainly useful for your own workflow.

However, it's important to remember that code formatting preferences vary widely between developers. What feels "correct" or "natural" to one person may feel distracting or even counter‑productive to someone else.

Because of this, any automatic formatting feature in Tiko should be optional and user‑configurable. A single fixed set of rules cannot satisfy everyone, especially when different BASIC dialects, coding styles, and personal habits are involved.

Your suggestions can definitely serve as a good starting point, but they should be treated as one possible style, not a universal standard. Ideally, Tiko will allow each user to choose the formatting rules that best match their own preferences.

I, personally, use "original case", that is: don't mess with I'm writing.

#37

PlanetSquires Software / Re: I sincerely hope the new v...

Last post by José Roca - August 02, 2026, 08:50:01 AM

Please note that the issue that I'm reporting is about ANSI files that contain double‑byte characters (Chinese, Japanese, Korean, Big5, Shift‑JIS, etc.). These encodings do not use Unicode at all. They rely on DBCS (Double‑Byte Character Sets), where each character occupies two bytes.

In ANSI DBCS files, Scintilla must be explicitly switched into DBCS mode. If not, Scintilla treats each byte as a separate character, which causes the Backspace key to delete only half of a character. This is unrelated to UTF‑8/UTF‑16 and remains an issue even if Unicode printing works perfectly.

#38

PlanetSquires Software / Re: I sincerely hope the new v...

Last post by José Roca - August 02, 2026, 08:39:32 AM

Hi Paul,

The easiest way to fix the ANSI double‑byte character issue in Tiko is to automatically enable Scintilla's DBCS mode whenever an ANSI file contains bytes in the DBCS range.

This requires no UI changes and works for Chinese, Japanese, Korean, Big5, Shift‑JIS, and other double‑byte encodings.

1. Detect whether the ANSI file contains double‑byte characters

When loading an ANSI file, scan the raw bytes.
If any byte is in this range:

0x81–0xFE

then the file is almost certainly encoded in a DBCS code page (GBK, Big5, Shift‑JIS, EUC‑KR, etc.). Western ANSI encodings never use bytes above 0x7F, so this detection is reliable.

2. If DBCS bytes are found, enable Scintilla's DBCS mode

Set a DBCS‑compatible code page (CP936 is the safest default)


SCI_SETCODEPAGE, 936  // GBK / CP936

CP936 is a good default because:

it supports a wide range of double‑byte characters,

it does not break Japanese or Korean text,

and it immediately fixes the backspace problem.

(You can refine this later if you want, but CP936 is enough to solve the current issue.)


Set an appropriate character set for rendering

SCI_STYLESETCHARACTERSET, STYLE_DEFAULT, SC_CHARSET_GB2312

This ensures correct width and font selection for double‑byte characters.

#39

PlanetSquires Software / Re: I sincerely hope the new v...

Last post by Paul Squires - August 02, 2026, 08:33:13 AM

Hi, this has all been fixed a couple of weeks ago.

The encoding was fixed on July 26 https://www.planetsquires.com/protect/forum/index.php?topic=4864.msg36748#msg36748

I just ran two tests on files using UTF-8 BOM and UTF-16 BOM. Both print to the console perfectly. I have attached screenshots.

These changes will be in the next Tiko update.

#40

PlanetSquires Software / I sincerely hope the new versi...

Last post by fbfans - August 02, 2026, 03:35:23 AM

The upcoming release is already remarkably robust—it's a powerful IDE that fully embodies all the modern features you'd expect. With its elegant UI, full Unicode support, and seamless integration with the latest afx framework for Windows programming, Tiko has clearly positioned itself as a forward-looking tool in the FreeBASIC ecosystem.
The reason I urgently need this fix is that, under FreeBASIC, the console does not handle Chinese characters perfectly when using UTF-8 BOM or UTF-16 BOM encoding—characters often overlap or get cut off. I posted about this on the official forum but received no response. Currently, the only encoding that allows the console to display Chinese correctly is ANSI. As a result, most of my programming work is done in ANSI format.
That's precisely why the current behavior—where a single backspace deletes only half of a double-byte character under ANSI—affects me so significantly. This is the kind of problem that belonged to IDEs from 20 or 30 years ago, not to a modern editor like Tiko.
For comparison, I've tested other FreeBASIC IDEs such as FBIDE, VFBE, and VFB, and they all handle double-byte characters correctly across encoding formats. As one of the few FreeBASIC IDEs that combines high-DPI support with a clean, user-friendly experience, Tiko really should offer flawless double-byte character handling in every encoding mode.
I sincerely hope Paul will address this in a future update. I'm really looking forward to it!