Hi everyone,
I know that some of you try the latest Tiko versions via the github "development" branch. I can inform you that the branch now contains the latest most feature complete version. I do not intend to add any more major features, so the work that remains is testing and tweaking the program before the new version is released.
https://github.com/PaulSquires/tiko/tree/development
You just need to "Download ZIP" and extract to your hard drive preferably to a location without spaces in the folder names.
DO NOT INSTALL THIS OVER YOUR EXISTING TIKO INSTALLATION
NOTE: It is a large download because it contains the full Help Centre html files, plus Tiko help html files, plus FBC toolchain. The actual Tiko Editor and DLL's are pretty small in comparison.
It is best if you unzip the program into a folder path that does not contain any spaces.
Please post here any major issues that you find so that I can polish things up before Tiko goes out for general release.
Thanks
No major reports in the 3 days that this beta has been active.
I am taking that as a positive sign. :)
@José Roca if you have tried this beta then I would be interested to know if the dialog and font sizes are okay on your computer/laptop. This beta's dialogs and fonts are larger than in the most recent released version. I remember that you had trouble with the long height of top menus a version or two ago, so I expect that screen real estate is important for you.
Hi Paul,
Thanks for beta-Test phase - works fine -and here my remarks
a) Screen display on old Laptop 1366x768 :full sized windows: settings pop-up uses app.80% , Fonts resized to 10
b) Big 27inch - need only to be resized à gusto : visual acuity : sizing and local position
c) Observing a "crash" ::
Starting the Tiko out-of-the box , loading a test file and try to compile:
==> error ( warning pop-up --> cannot not find compiler path
Then it stops like a "crash" without further option for adapting new settings-
(... logically this might correct, but new user not knowing the background may be scared.)
Background : out-of-the-box path setting may be (are) not known and may be different from mine .
Tiko ought to be able to find it's way i.e. "default path" in the "Toolchains" below the own path.
P.S. My ideas are ::
::@(b) :: Output windows for Big Screen :: option for display in a "side panel"
::@(c) :: an stop-over on the settings page for that choice.
b.r. (Hajubu) Hans
Excellent, thanks Hans, appreciate it 8)
Hi, just tried the new "UString" with fbc-win (1.20?) under the Toolchains within Tiko-beta.
How can we add the additional compiler with the help of the Settings options (Ctrl + ,).
I do know to add them manually in the settings.ini ( that worked).
Testing this with Tiko132 - it does offer to set the alternatives with the options (Shift + F7) as it find the new folder under the "Toolchains" by itself.
It would be a great support you could check the possibilities.
Thanks Hans (Hajubu)
Hi Hans,
I tried doing so myself and the new toolchain did not show up under the list of available toolchains. Turns out there was a bug in the new PsListTree control that scrolled the first item off the top of the list (which happened to be that new toolchain). it's fixed now but not in the development branch because I am doing other major work off a feature sub-branch from development that I don't want to disturb.
To make things easier for you, I have attached the new tiko.exe with the fix included.
Just add the whole \fbc-win folder from the USTRING repo to the \toolchains folder off of Tiko. I renamed my new toolchain to fbc-win-USTRING so that I would know for sure what that toolchain does.
thanks , Paul
I'm trying a little the USTRING, but I'm struggling withe visualization.
The character used in the showcase "ustring_usage_test_owl.bas" U+1D11E is not visible in TIKO.
The emoji OWL can be visualized as it show below.
I added/changes from the Musical Clef values to the values for OWL. )inclusive for the surrogate pair (hi,lo)
All 146 test running fine for both , but not the visibility for the clef.
Also the compiler log files do not show the symbol, which may by nature of the fbc.
Your TODO/NOTES TAB Panels show the OWL with the emoji for the black & white symbols.
The Musical Clef sees , do not have an equivilant (?).
b.r. Hans
'#define ASTRAL wchr(&h1D11E) '' surrogates( hi:0xD834, lo:0xDD1E ) i.e. |𝄞| U+1D11E MUSICAL SYMBOL G CLEF)
'#define ASTRAL wchr(&h1F989) '' surrogates ( hi:0xD83E, lo:0xDD89 ) i.e. |🦉| U+1F989 OWL
The OWL produces the following error output:
USTRING usage showcase
FAIL m[1] is the HIGH surrogate got= 55358 want= 55348
FAIL m[2] is the LOW surrogate got= 56713 want= 56606
FAIL units recombine to U+1D11E got= 129417 want= 119070
142 checks, 3 failed
I'll post a fix/explanation as soon as I can.
The problem is not the compiler, but rather the test code itself. The #DEFINE set at the top of the code has hardcoded values later in the test suite based on that value. Changing that value from a clef to an owl did not (obviously) change the hardcoded HI/LO values later in the test.
Use the attached test code file (in the zip) until I can update the Github repository.
Thanks, Paul.
Yes , I had edited the "OWL" for all the necessary entries manually.
therefore the results are the same , as what you did with the adapted defines and surrogates
Therefore my observation , said before, can be also confirmed with your edition.
a) The CLef-symbols IS NOT visualized in TIKO Editor : OWL is Visible as it should
b) FBC log text does not display the UNICODE symbols (by nature).
c) TODO/NOTES show a equivalent of the OWL in Black & White only
b.r. Hans
P.S: I'll try to understand the reason behind - then I'll will be back.
Quote@José Roca if you have tried this beta then I would be interested to know if the dialog and font sizes are okay on your computer/laptop.
No. I guess there are "Ok" and "Cancel" buttons, but they aren't visible.
Thanks José,
As I feared, the larger font and spacing was too much. The OK, CANCEL don't fit on the dialog based on your display.
It is not a problem of the size of the font, but of the space between lines. Like writing with Word using 1.5 between lines. The same problem that happened with the menus in an early version.
Quote from: José Roca on August 06, 2026, 09:14:36 PMIt is not a problem of the size of the font, but of the space between lines. Like writing with Word using 1.5 between lines. The same problem that happened with the menus in an early version.
Yes, I kind of figured it would result in the same issue as the top menu problem we dealt with. I'll get it all fixed up.
Be aware that HD monitors are wide, but not very tall.
Hi Paul,
I downloaded the beta version and, as always, it works great. The issues I reported previously have all been resolved.
Regarding the problem in ANSI mode where backspace only deletes half of a double-byte character, please take a look at my feedback in another thread — I'm hoping for a fix!
https://www.planetsquires.com/protect/forum/index.php?msg=36811
Feedback:
1. The interface is still very well-coordinated. On my 2K screen（2240X400）, the Chinese-to-English display ratio looks normal. There are a couple of small things that might be intentional on your part — for example, the "normal" text in the upper-right corner of the edit area appears noticeably larger than everything else, and the button heights inside the theme settings dialog seem inconsistent with others.
2. Formatting is something I care about quite a bit. After looking at your formatting module, I realized that's what real professionalism looks like — it's something worth studying. The test results are excellent. Here is my feedback:
1) To make the formatter more complete, it should support logical compound assignment operators as valid syntax. Here's a reference implementation:
' --- Detect logical/shift compound assignment operators (and=, or=, xor=, eqv=, imp=, shr=, shl=) ---
dim as string sLow = lcase(sWord)
if (sLow = "and" or sLow = "or" or sLow = "xor" or sLow = "eqv" or sLow = "imp" or sLow = "shr" or sLow = "shl") then
' Save current position, skip whitespace after the word
dim as long j = i
while j <= nLen
dim as long c = asc(mid(sText, j, 1))
if (c <> 32) and (c <> 9) then exit while
j += 1
wend
' Check if the next non-whitespace character is '='
if j <= nLen then
dim as long c = asc(mid(sText, j, 1))
if c = 61 then ' '='
' Only merge if there is no whitespace between the word and '=' (i.e. j == i)
if j = i then
i = j + 1 ' Skip '='
sWord &= "=" ' Merge into "and=" etc.
' Set this token type to operator, not word
tokens(nCount).kind = FMTTOK_OP
tokens(nCount).text = sWord
nCount += 1
bStmtStart = false
continue while ' Return to the main loop to continue processing subsequent characters
end if
end if
end if
end if
private function FMT_IsBinaryOp( byref sOp as string ) as long
select case sOp
case "=", "+", "-", "*", "/", "\", "^", "<", ">", "<=", ">=", "<>", "&", _
"+=", "-=", "*=", "/=", "\=", "^=", "&=", "=>", _
"and=", "or=", "xor=", "eqv=", "imp=", "shr=", "shl="
return true2) The Extern statement has two forms: block and single-line.
The block form should be added to auto-completion, like:
extern
end externFor the single-line form, when a line is fully entered, e.g.
extern foo alias "foo" as longthe next line continues to indent incorrectly.
Here's a reference implementation of the fix I made:
' Add single-line extern detection to avoid unwanted auto-indent
case "extern"
' If there's only one word, or the second word starts with a double quote, treat as a block opener; otherwise it's a single-line declaration
if nWords < 2 then
return FMTLINE_OPENER
else
if left(sW2, 1) = """" then
return FMTLINE_OPENER ' Extern "C" ...
else
return FMTLINE_PLAIN ' Extern foo Alias ...
end if
end if3) In the current version of Tiko (compared to 1.3.2), there is a regression in the auto-completion of nested blocks. Specifically:
A first-level block (e.g., the outermost if) correctly auto-completes end if after pressing Enter.
However, for second-level and deeper nested blocks (e.g., inner if, for, do, etc.), the matching closing block is sometimes not automatically inserted after pressing Enter.
In version 1.3.2, all nested blocks were completed correctly.
3.Other things:
I'm not quite sure about the following points:
a) I notice that the top of the sidebar currently groups together common icons like Config, Run, Debug, Save, etc. The sidebar itself is used for managing files, functions, and bookmarks. Now that the top is filled with these action icons, it feels a bit crowded. Is there any plan to add a toolbar to separate the action icons from the sidebar functions? That would make the interface cleaner and align with the layout conventions of most editors.
b) I'm not sure how to properly use the new bar added below the tab bar — it feels like its functionality overlaps with the sidebar (except for jumping between the main file and header file). If this is intended for project purposes, the sidebar's tree structure already works well. If the sidebar isn't being used, then icons like normal, M, H could just as well be placed on a toolbar (if one existed). If possible, could an option toggle be added to let users decide whether to display this bar?
c) Regarding the logic of debug breakpoints and bookmarks — I've mentioned this before. In the settings, clicking on the margin is configured to be either a bookmark or a breakpoint. However, I've noticed that when using keyboard shortcuts, both can be set simultaneously, and their icons can even overlap. This seems to create an inconsistency in the interaction logic — if mouse clicks are limited to one or the other, shouldn't keyboard shortcuts follow the same rule? Or, if simultaneous setting is allowed, could the mouse also support it (for example, left-click for bookmarks, right-click for breakpoints) to maintain consistency?
These are my thoughts — please feel free to disregard anything that doesn't align with your vision.
Thank you, Paul. Tiko is getting better and better.
Hi Paul,
- All CLear -
My observation had been correct - BUT I stepped in the mousetrap of Win11 "CONHOST" versus Terminal-Cmd-Input.
CONHOST uses the std. cmd.exe with chcp 65001 which is utf8 / or any OEM CP850 , etc.
Openening the Cmd-Input with the terminal (" wt -d ." ) command or "Win-R" uses a terminal-Cmd-Input (opt.Setting) which can handle "allmost all" U+1xxx codes in direct presentation. ( Owl 🦉 and also the music.Clef-G 𝄞 )
The old Cmd windows ( conhost ) has the some limitation , even with the /U (chcp 65001), which is creepy for W7 (in and out) and w10+ on input.
All apps which are working on ANSI or UTF8 base can not safely (or at all ) handle the U+1xxx codepoints.
One modern exception exists : the world of Emoji , ((Win+{period/dot}) is input help pop-up for window 11.) -> like this Musical clef 🎼
Thanks for your patience.
b.r. Hans