- Welcome to PlanetSquires Forums.
PlanetSquires Forums
"It’s not a bug; it’s an undocumented feature" - Anonymous
Recent posts
#1
José Roca Software / Re: AfxNova progress
Last post by Paul Squires - July 19, 2026, 11:28:08 PMCongratulations on both successes! I was thinking of you today as I watched the World Cup championship match. I could just picture you smiling from ear to ear as happy can be! 
#2
José Roca Software / Re: AfxNova progress
Last post by José Roca - July 19, 2026, 10:22:01 PMGreat news, at least for me. Spain has won the World Cup and I have managed to replicate the functionality of the operator "await", used in .NET, that allows to use asynchronous operations as if they were synchronous. Now we can use DIM x AS DOUBLE = pKonva->GetX("circle1"), Tomorrow I will implement the "getters". You will also receive mouse and keyboard events in WM_KEYDOWN and WM_KEYUP. The graphic library based on Konva.js is near to completion.
#3
PlanetSquires Software / Re: Help with formatting modul...
Last post by Paul Squires - July 15, 2026, 08:39:45 AM@fbfans
I now realize that the problem is that the SCN_CHARADDED notification is received AFTER the ENTER character is inserted. We need to capture the ENTER key BEFORE it ever reaches the Scintilla control. Normally we would do this by subclassing the Scintilla control but there is a much easier way. We test for the keypress in the main message loop via the raw incoming messages received from Windows.
I have tested the following sequence of code and it works.
Modify "frmMain.inc" message loop. That's the code area towards the end of the file that handles the GetMessage.
' Message loop
do while GetMessage(@uMsg, null, 0, 0)
Insert the following after the line that calls "handleKeysFindReplace:
' Handle ENTER for Scintilla control (beautify current line)
if handleScintillaENTER(uMsg) then continue do
Create that "handleScintillaENTER()" function in "modMsgPump.inc"
This should work.
I now realize that the problem is that the SCN_CHARADDED notification is received AFTER the ENTER character is inserted. We need to capture the ENTER key BEFORE it ever reaches the Scintilla control. Normally we would do this by subclassing the Scintilla control but there is a much easier way. We test for the keypress in the main message loop via the raw incoming messages received from Windows.
I have tested the following sequence of code and it works.
Modify "frmMain.inc" message loop. That's the code area towards the end of the file that handles the GetMessage.
' Message loop
do while GetMessage(@uMsg, null, 0, 0)
Insert the following after the line that calls "handleKeysFindReplace:
' Handle ENTER for Scintilla control (beautify current line)
if handleScintillaENTER(uMsg) then continue do
Create that "handleScintillaENTER()" function in "modMsgPump.inc"
Code Select
function handleScintillaENTER( byval uMsg as MSG ) as boolean
' Catch any ENTER key destined for the Scintilla editor and beautify the
' current text line. We replace the line with our new code and then allow
' the ENTER key to continue to pass on to Scintilla where it will do the
' insertion of the ENTER character. Scintilla will then fire SCN_CHARADDED
' where we do additional things like AutoIndent.
dim pDoc as clsDocument ptr = gApp.GetDocumentPtrByWindow( uMsg.HWnd )
if pDoc = 0 then return false
dim as HWND hEdit = pDoc->hWndActiveScintilla
if (uMsg.HWnd = hEdit) andalso (uMsg.message = WM_KEYDOWN) andalso (uMsg.wParam = VK_RETURN) then
dim as long nCurLine = pDoc->GetCurrentLineNumber()
dim as string strLine = pDoc->GetLine(nCurLine)
' CALL YOUR FORMATTING ROUTINE HERE AND RETURN THE NEW LINE
' Beautify the current line
'dim as string strNewLine ='AddSpacesAroundOperators( strLine )
' Replace the old line with our new line (don't use pDoc->SetLine)
dim as long lineStart = SendMessage( hEdit, SCI_POSITIONFROMLINE, nCurLine, 0)
dim as long lineEnd = SendMessage( hEdit, SCI_GETLINEENDPOSITION, nCurLine, 0)
SendMessage( hEdit, SCI_SETSELECTIONSTART, lineStart, 0)
SendMessage( hEdit, SCI_SETSELECTIONEND, lineEnd, 0)
SendMessage( hEdit, SCI_REPLACESEL, 0, cast(LPARAM, strptr(strNewLine)) )
end if
' we want our message to continue so return FALSE
return false
end function
This should work.
#4
José Roca Software / Re: Trackbar question & anima...
Last post by José Roca - July 14, 2026, 04:57:29 PMYes, it does exist, but it has one parameter, not two. It is in AfxCtl.inc.
Code Select
' ========================================================================================
' Sets the interval frequency for tick marks in a trackbar.
' ========================================================================================
PRIVATE SUB Trackbar_SetTicFreq (BYVAL hTrackbar AS HWND, BYVAL wFreq AS WORD)
SendMessageW(hTrackbar, TBM_SETTICFREQ, cast(WPARAM, wFreq), 0)
END SUB
' ========================================================================================
#5
José Roca Software / Re: Trackbar question & anima...
Last post by Frank Bruebach - July 14, 2026, 01:34:09 PMConcerning my First and second example..
hello again.. simple question.. does "Trackbar_SetTicfreq" hTrackBar, 2, 0 exist in cWindow?
TBM_SETTICFREQ ?
thanks, frank
hello again.. simple question.. does "Trackbar_SetTicfreq" hTrackBar, 2, 0 exist in cWindow?
TBM_SETTICFREQ ?
Code Select
' // Adds a Trackbar control
DIM hTrackBar AS HWND = pWindow.AddControl("Trackbar", hWin, IDC_TRACKBAR, "", 75, 60, 240, 32)
' // Set the range values
Trackbar_SetRangeMin hTrackBar, 0, TRUE
Trackbar_SetRangeMax hTrackBar, 20, TRUE
' new
' Trackbar_SetTicfreq hTrackBar, 2, 0 ' doesnt exist in cWindow ?
' SendMessageW hTrackBar, TBM_SETTICFREQ, 2,0 ' included in cWindow or commctrl ?
thanks, frank
#6
PlanetSquires Software / Re: Images of some new Tiko fe...
Last post by hajubu - July 14, 2026, 07:10:06 AM@paul
- oh - that's a pitty.
Tiko 126 - Ok , Tiko 132 - half -and the 140 beta with the full fletched Log file , seems already structural overloaded.
Compiler Results was always readable enough and the well distributed #print message gave an well structured overview.
Let's wait and see the final outcome.
b.r. Hajubu
- oh - that's a pitty.
Tiko 126 - Ok , Tiko 132 - half -and the 140 beta with the full fletched Log file , seems already structural overloaded.
Compiler Results was always readable enough and the well distributed #print message gave an well structured overview.
Let's wait and see the final outcome.
b.r. Hajubu
#7
PlanetSquires Software / Re: Images of some new Tiko fe...
Last post by fbfans - July 14, 2026, 07:05:12 AMThanks for your hard work, Paul.
The current Find and Replace feature works really well in my opinion. I don't think the input fields for it need to be quite so wide.
The current Find and Replace feature works really well in my opinion. I don't think the input fields for it need to be quite so wide.
#8
PlanetSquires Software / Re: Help with formatting modul...
Last post by fbfans - July 14, 2026, 06:48:37 AMPaul, thank you for fixing the bookmark issue.
My technical knowledge is limited, and I didn't expect the several issues I brought up to be this tricky. It turns out you'd already thought through all of them long beforehand — I overcomplicated things unnecessarily.
I'd like to explain the current situation of my formatting code.
In the frmmainonnotify.inc module, once the Enter key is pressed, Scintilla moves the cursor to a brand new blank line immediately. That's why my code reads and processes the previous typed line — this logic itself is correct.
I also tried moving the formatting routine before AttemptAutoInsert() as suggested, but the indentation bug still persists.
The specific issue: only the first-level indentation works properly, while all second-level and multi-layer nested indentations break entirely, as shown in this sample:
I'm confused about one thing: I only added spaces around operators and never modified the leading indent whitespaces, so I don't understand why this breaks auto-indentation judgment entirely.
If this bug is indeed tied to the underlying global document parsing cache mechanism, I don't have the ability to fully resolve this conflict with my current skill set.
After weighing all factors, I will remove the auto-formatting logic triggered by the Enter key and stop developing this feature.
Thanks again, Paul.
My technical knowledge is limited, and I didn't expect the several issues I brought up to be this tricky. It turns out you'd already thought through all of them long beforehand — I overcomplicated things unnecessarily.
I'd like to explain the current situation of my formatting code.
In the frmmainonnotify.inc module, once the Enter key is pressed, Scintilla moves the cursor to a brand new blank line immediately. That's why my code reads and processes the previous typed line — this logic itself is correct.
I also tried moving the formatting routine before AttemptAutoInsert() as suggested, but the indentation bug still persists.
The specific issue: only the first-level indentation works properly, while all second-level and multi-layer nested indentations break entirely, as shown in this sample:
Code Select
if a>b then
print "hello"
else
print "china"
end if
do while a>b
print "word"
loop
end ifI consulted an DeepSeek(AI) tool for analysis, and it pointed out the root cause: my formatting function calls SetLine to rewrite the entire line, which triggers the SCN_MODIFIED notification and forces bNeedsParsing = true. This marks the global document's nested level and keyword parsing cache as outdated, so the reference data used to calculate multi-layer indentation stays invalid all the time.I'm confused about one thing: I only added spaces around operators and never modified the leading indent whitespaces, so I don't understand why this breaks auto-indentation judgment entirely.
If this bug is indeed tied to the underlying global document parsing cache mechanism, I don't have the ability to fully resolve this conflict with my current skill set.
After weighing all factors, I will remove the auto-formatting logic triggered by the Enter key and stop developing this feature.
Thanks again, Paul.
#9
PlanetSquires Software / Re: Images of some new Tiko fe...
Last post by Paul Squires - July 14, 2026, 05:58:37 AM@hajubu
This is a small change based on my discussions with Jattenalle over on the FB Discord server. He has a project called fbCOLLECTION that uses #print statements to print out an internal manual to the console. Tiko would try to display that Help in the "COMPILER RESULTS" list which obviously made the text horrible to read because Tiko expects to read an FB compiler generated log file, and not a file with user defined messages. Therefore, the Line / File / Description columns is not a good place to display the information.
Tiko now tries its best to automatically switch to the more verbose raw display of the log file via the "COMPILER LOG FILE" tab whenever it can not display errors or warnings that do not nicely conform to the Line/File/Description paradigm of the "COMPILER RESULTS" tab.
This also works better for some normal FB compile fails such as Linking errors or Resource file compiling errors where no filename/error message can be parsed and you just get a somewhat cryptic error message in the "COMPILER RESULTS" window telling you to view the log file. Now, Tiko will actually switch you directly to the "COMPILER LOG FILE" tab and show you the log file.
This may not be 100% perfect, but it seems to work pretty good in the majority of cases.
This is a small change based on my discussions with Jattenalle over on the FB Discord server. He has a project called fbCOLLECTION that uses #print statements to print out an internal manual to the console. Tiko would try to display that Help in the "COMPILER RESULTS" list which obviously made the text horrible to read because Tiko expects to read an FB compiler generated log file, and not a file with user defined messages. Therefore, the Line / File / Description columns is not a good place to display the information.
Tiko now tries its best to automatically switch to the more verbose raw display of the log file via the "COMPILER LOG FILE" tab whenever it can not display errors or warnings that do not nicely conform to the Line/File/Description paradigm of the "COMPILER RESULTS" tab.
This also works better for some normal FB compile fails such as Linking errors or Resource file compiling errors where no filename/error message can be parsed and you just get a somewhat cryptic error message in the "COMPILER RESULTS" window telling you to view the log file. Now, Tiko will actually switch you directly to the "COMPILER LOG FILE" tab and show you the log file.
This may not be 100% perfect, but it seems to work pretty good in the majority of cases.
#10
PlanetSquires Software / Re: Function/Sub/Label window
Last post by Paul Squires - July 13, 2026, 08:23:37 PMI assume you're referring to the Tiko editor.
The sub/function listings are there. It's called "View Functions List". Several ways to access it. I always press F4 which will toggle between the Explorer showing in the left pane, and the Functions List. Similarly, the Bookmarks list shows in that pane (Shift_F4). There is also a menu item under the "View" menu. You can also click on the second icon from the left just above the Explorer pane.
The find/replace window has been totally redesigned. I posted images of it yesterday: https://www.planetsquires.com/protect/forum/index.php?topic=4857.msg36684;topicseen#msg36684 The new UI will be in the next version release.
The sub/function listings are there. It's called "View Functions List". Several ways to access it. I always press F4 which will toggle between the Explorer showing in the left pane, and the Functions List. Similarly, the Bookmarks list shows in that pane (Shift_F4). There is also a menu item under the "View" menu. You can also click on the second icon from the left just above the Explorer pane.
The find/replace window has been totally redesigned. I posted images of it yesterday: https://www.planetsquires.com/protect/forum/index.php?topic=4857.msg36684;topicseen#msg36684 The new UI will be in the next version release.