Wiki improvements

[SARG]

As default value of parameters in procedures it's possible to use a variable (only a shared one).

I didn't see this information in the help so maybe it would be usefull to add it.

Code: Select all

dim shared as integer vshared
dim        as integer vlocal=15

vshared=19

sub test1(aa as integer=vshared)
	print aa
End Sub

'sub test2(aa as integer=vlocal)   ''not allowed
	'print aa
'End Sub

test1

vshared=17
test1

sleep

[fxm]

This is only a special case of variables which, to be implicitly accessible (not passed as a parameter) from a procedure, must therefore be shared.

[SARG]

My purpose is just to complete the information about default value as nothing says that a variable can be used (in help it's written : value).
And I don't remember if I already did or saw a such use.

[fxm]

OK.
I propose to complement the 'Parameters' paragraph of the SUB/FUNCTION keywords ('default_value' line).

[fxm]

Done:
- KeyPgSub → fxm [default parameter initializer can be a literal, or a constant, or a shared variable]
- KeyPgFunction → fxm [default parameter initializer can be a literal, or a constant, or a shared variable]

[SARG]

Thanks.

[fxm]

@Jeff,

According to rtlib: win32/win64: MULTIKEY() remove the 'FindWindow()', can you update the paragraph 'rtlib/win32' in Keyboard Input ?
(I am afraid I would not do it well)

[coderJeff]

Thanks, updated:

fb_ConsoleMultikey() uses a FindWindow()/GetForegroundWindow() hack on older versions of windows (before Windows 7) to determine whether the console window is focused, and if yes, simply uses GetAsyncKeyState(). Newer versions of windows should limit function of GetAsyncKeyState() to the currently focused window. In newer versions of windows when using windows terminal, the FindWindow() hack causes issues and must be disabled.

[adeyblue]

Newer versions of windows should limit function of GetAsyncKeyState() to the currently focused window.

This isn't true. GetAsyncKeyState is 'get the current state of the key from the keyboard'. Which app asked for it and which app is currently being interacted don't factor into it. GetKeyState is the one that's tied to apps, but it's unreliable in console apps since they don't have a message loop.

I'm not sure what the issues are this change was fixing, but with this, Multikey will respond positively to input typed anywhere (and maybe that's ok, idk). For instance, run this (with the changed code), minimize the console, click whatever app you like and press A. You get the "A pressed" message without any inkey.

Code: Select all

#include "fbgfx.bi"

dim inkeystr as string
dim wholestr as string

Do

   wholestr = ""
   If MultiKey(FB.SC_A) Then
      Do
         inkeystr = Inkey
         wholestr += inkeystr
      Loop Until inkeystr = ""
      Print "A pressed, inkey is " & wholestr
   End If

   Sleep 10

Loop Until InKey = "q"

You can still get something similar with the old MultiKey code if you run the above simultaneously in two Windows Terminal tabs. Activate either tab and press A, the message will appear in both.

Also, the changelog comment says Win 10, the version check in the code is Windows 7 (<= Vista).

[coderJeff]

GetKeyState is the one that's tied to apps, but it's unreliable in console apps since they don't have a message loop.

dang, ok. Will have to try and fix another way. thanks, I will revert the change first chance I get.

The issue trying to fix is that the helper proc 'find_window(void)' in ./src/rtlib/win32/io_multikey.c doesn't work under windows terminal and so fb's MULTIKEY was getting no response at all because the console window never passed the test for being in focus / foreground; and under conhost I think was working for me but only when legacy support checkbox was enabled.

hmm, so not sure what the new way is to test that console app has current focus.

[adeyblue]

I guess there are two options:
Implement it the same way InKey works. Process the console input records for keyboard input (by defnition these only exist when they've been typed into the app), if the key exists in the records then it's been down. That would slightly change the meaning though from 'is it down now' to 'has it been down since the last input read'. Games that don't Inkey or Input might not work with that if the key events stay in the input buffer.

In that vein, as well as keyboard, there are also focus_events in the input records which are received when clicking into and away from the app. BUT (because there's always a but) the docs have said for 30 years that they "are used internally and should be ignored." They don't seem to work with older terminal versions (I had 1.12 where they didn't) but I updated it to 1.18 and now they do.

Here's a short vid of the below:
https://mega.nz/embed/TpBymAwZ#gp5OiaVc ... FaCxbKvE5s

Code: Select all

#include "windows.bi"

Dim Shared g_focussed as Long
Dim Shared g_hIn As HANDLE

'' add the guts of this to fb_ConsoleProcessEvents() in rtlib/win32/io_input.c 
Sub ReadEventsForFocus()

    Dim as Long numEvents, numRead
    GetNumberOfConsoleInputEvents(g_hIn, @numEvents)

    Dim As INPUT_RECORD rec = Any
    While (numEvents <> 0) AndAlso ReadConsoleInput(g_hIn, @rec, 1, @numRead)
       numEvents -= 1
       If rec.EventType = FOCUS_EVENT Then
           g_focussed = rec.Event.FocusEvent.bSetFocus
           Print "Setting focus to " & Str(g_focussed)
       End If
    Wend

End Sub

Function MultiKey_FocusTest(ByVal vk as Long) As Long

    ReadEventsForFocus()
    If g_focussed Then
        Return GetAsyncKeyState(vk) And &H8000
    Else Return 0
    End If

End Function

g_hIn = GetStdHandle(STD_INPUT_HANDLE)
Dim as ULong mode
GetConsoleMode(g_hIn, @mode)
mode Or= ENABLE_PROCESSED_INPUT '' mimic FB startup
SetConsoleMode(g_hIn, mode)
g_focussed = true

Do
   If MultiKey_FocusTest(&h41) Then '' a
      Print "A down"
   End If
   Sleep 10
Loop Until MultiKey_FocusTest(&h51) '' q

[fxm]

@Jeff,

This recent wiki update from badidea (for the first overload syntax of ImageInfo), seems correct to me :
KeyPgImageInfo → badidea [Wrong type for size, 32 bit fbc]

I was previously based on this fbc 1.08.0 change in the changelog.txt file:

- Change overload to IMAGEINFO( byval as const any ptr, byref as long = 0, byref as long = 0, byref as long = 0, byref as long = 0, byref as any ptr = 0, byref as longint = 0 ) as long

So it would then be desirable to also make a purely documentary correction in the changelog.txt file:

- Change overload to IMAGEINFO( byval as const any ptr, byref as long = 0, byref as long = 0, byref as long = 0, byref as long = 0, byref as any ptr = 0, byref as longint long = 0 ) as long

[coderJeff]

So it would then be desirable to also make a purely documentary correction in the changelog.txt file

Not a problem. Gives me an excuse to also perform some housekeeping on old branches. The change will appear in current development branch next time fbc-1.10 branch is merged to master branch.

[fxm]

@Jeff,

About the documentation update for '-gen clang':

- can you propose a description for the Compiler Option: -gen documentation page,

- on the SGN documentation page, should one or two 'clang' column(s) be added for the 2 tables in the 'Note' paragraph (and with what content)?
Already, the case 'llvm' is missing, is this normal?

[coderJeff]

First,
There are some changes for error messages. I have not updated the wiki yet; I will do it in the near future.
I will keep in mind to review instructions for installing toolchains ... another day.

For SGN:
- '-gen clang' and '-gen llvm' generate same results as '-gen gcc'
- but with most users using one of gas/gas64/gcc, this could be a (*) note that says "(*) applicable also for clang and llvm"

For -gen clang:
- '-gen clang' generates nearly the same C code as with '-gen gcc' - with only a couple of minor differences that would not affect users
- In general wherever '-gen gcc' is referenced then '-gen clang' is also valid.
- this of course may diverge in future but for now is correct

The major difference at the moment is the tools invoked:
- -gen gas|gas64: as-->ld
- -gen gcc: gcc-->as-->ld
- -gen clang: either "clang-->as-->ld" ... or "clang-->clang-->ld" depending on host and target.
- -gen clang is a work in progress, so may change as we find the best way to invoke and run tools. clang is a front-end for compiler/assembler/linker but also has good compatibility with gcc and binutils so there are variations on ways to run the tools. More possibilities than with gcc + binutils only. (but not every way works! so it's a WIP).

I was able to run the test-suite successfully on windows 32-bit using '-gen clang', but only with clang as the assembler since the 'GNU as' didn't understand all of the emitted assembly that clang produces.