Wiki improvements
Re: Wiki improvements
These values (&h5B, &h5C, &h5D) appear in fbgfx.bi (instead of &h7D, &h7E, &h7F) from the fbc version 0.18.3b.
In the changelog.txt (version 0.18.3 beta), we find this fix:
- #1813104 - scancodes for SC_LWIN(&h5b), SC_RWIN(&h5c), SC_MENU(&h5d), are now same in both gfx/console modes and on all platforms (jeffm)
So it would seem that the documentation was not updated accordingly at the time!
In the changelog.txt (version 0.18.3 beta), we find this fix:
- #1813104 - scancodes for SC_LWIN(&h5b), SC_RWIN(&h5c), SC_MENU(&h5d), are now same in both gfx/console modes and on all platforms (jeffm)
So it would seem that the documentation was not updated accordingly at the time!
Re: Wiki improvements
Yes, wiki is wrong. Values were changed in 2007 and wiki never updated. inc/fbgfx.bi is correct.
Some explanation:
fb's scancodes come from legacy DOS use (which would have typically been the raw values returned by keyboard controller port &h60). The actual values used by the operating system (keyboard driver) probably won't match every value same as DOS. However, the intent is that from user's point of view, fbc's scancodes, both the symbolic name, and numeric value will work the same on all platforms where fbc is compiled. i.e. cross compatible code.
On linux & win can see private mappings between fbgfx's scancodes and the system's keycodes:
src/rtlib/linux/io_multikey.c
src/rtlib/win32/io_multikey.c
A user may find that for some keys, fb's scancodes won't match scancodes returned by direct system calls. I didn't check which ones are different, and I don't think it would be meaningful information for most users using MULTIKEY.
Some explanation:
fb's scancodes come from legacy DOS use (which would have typically been the raw values returned by keyboard controller port &h60). The actual values used by the operating system (keyboard driver) probably won't match every value same as DOS. However, the intent is that from user's point of view, fbc's scancodes, both the symbolic name, and numeric value will work the same on all platforms where fbc is compiled. i.e. cross compatible code.
On linux & win can see private mappings between fbgfx's scancodes and the system's keycodes:
src/rtlib/linux/io_multikey.c
src/rtlib/win32/io_multikey.c
A user may find that for some keys, fb's scancodes won't match scancodes returned by direct system calls. I didn't check which ones are different, and I don't think it would be meaningful information for most users using MULTIKEY.
Re: Wiki improvements
I have updated the 3 scancodes on the wiki. I left the comment '' Extra scancodes not compatible with DOS scancodes untouched.
Re: Wiki improvements
Thank you for that.
Re: Wiki improvements
I added an example to Bsave. I hope it is not too long (and free of errors).
Should I put the general description inside the code block?
I also noticed that the 'tag' {{fbdoc item="ex"}} is used twice on KeyPgPutfileio. Better to remove the second? Is it important?
Should I put the general description inside the code block?
I also noticed that the 'tag' {{fbdoc item="ex"}} is used twice on KeyPgPutfileio. Better to remove the second? Is it important?
Re: Wiki improvements
Thank you.
For my part, I usually put a title (if necessary) above the code box and a general description (if necessary) at the beginning of the code box.
A single paragraph "Examples" is better.
Everyone is free to document as he sees fit.badidea wrote:Should I put the general description inside the code block?
For my part, I usually put a title (if necessary) above the code box and a general description (if necessary) at the beginning of the code box.
Yes, you can remove the redundant '{{fbdoc item="ex"}}' on the third example of 'PUT (File I/O)'.badidea wrote:I also noticed that the 'tag' {{fbdoc item="ex"}} is used twice on KeyPgPutfileio. Better to remove the second? Is it important?
A single paragraph "Examples" is better.
Re: Wiki improvements
Why I never use the wiki help:
If I go to Badidea's put page (KeyPgPutfileio) and say I wanted to view get, I put get into the search, it says no matches for get.
I am probably using the wiki help incorrectly, but I am not practised in it, I always use the .chm help file.
If I go to Badidea's put page (KeyPgPutfileio) and say I wanted to view get, I put get into the search, it says no matches for get.
I am probably using the wiki help incorrectly, but I am not practised in it, I always use the .chm help file.
Re: Wiki improvements
"By default, searches are limited to text strings greater than 4 characters". And I agree that this is a problem. My personal favourite help system is the old and terribly obsolete WinHelp32 btw. Clearly the best!dodicat wrote:it says no matches for get
Re: Wiki improvements
Not true any longer.jj2007 wrote:"By default, searches are limited to text strings greater than 4 characters".
counting_pine changed that to 3 characters, recently ...
(this is in respect to forum search anyway, and not the wiki)
Re: Wiki improvements
@MrSwiss
I find the forum search at times totally useless, sometimes I need to resort to Google search instead.
I find the forum search at times totally useless, sometimes I need to resort to Google search instead.
Re: Wiki improvements
Yea, the forum search.
That is good now.
I also have the the win32.chm.
Also I use the pascal .chm files, but they are not well built, I mainly google for pascal help.
But I am definitely CHM people when help is needed (all the time in my case).
That is good now.
I also have the the win32.chm.
Also I use the pascal .chm files, but they are not well built, I mainly google for pascal help.
But I am definitely CHM people when help is needed (all the time in my case).
Re: Wiki improvements
... and anyway, "get" is one of the common words that do not trigger any search on the forum.MrSwiss wrote:Not true any longer.
counting_pine changed that to 3 characters, recently ...
(this is in respect to forum search anyway, and not the wiki)
Re: Wiki improvements
Me too.dodicat wrote:Why I never use the wiki help:
..... , I always use the .chm help file.
In general, I go on wiki only to make an update!
(Otherwise, I'm using the latest '.chm' version downloaded from http://users.freebasic-portal.de/stw/builds/)
Re: Wiki improvements
Me neither (chm as well) , but the wiki is the source for the other formats right? So, a change on the wiki will find its way to the other formats, eventually.fxm wrote:Me too.dodicat wrote:Why I never use the wiki help:
..... , I always use the .chm help file.
In general, I go on wiki only to make an update!
(Otherwise, I'm using the latest '.chm' version downloaded from http://users.freebasic-portal.de/stw/builds/)
Re: Wiki improvements
Such blocks (table of one column only):
Can we do some thing?
(same problem as Instrrev above for Asc, Wstring (Function), Right, Mid (Function), Left, Instr, Wchr)
in order to display the following:[u]INSTRREV[/u] wrote:<<'A Unicode example:
dim text as wstring*20
text = "Привет, мир!"
print instrrev(text,"ет") ' displays 5
<<::c::
induce bad display (mainly bad location) when compiled to manual.chm.'A Unicode example:
dim text as wstring*20
text = "Привет, мир!"
print instrrev(text,"ет") ' displays 5
Can we do some thing?
(same problem as Instrrev above for Asc, Wstring (Function), Right, Mid (Function), Left, Instr, Wchr)