Hi Paul,
WinFBE 64 and 32. When editing the 2 key on the keyboard - not the number pad - opens the Designer Reference PDF. I Have a User Tool for this purpose but there is no shortcut key associated with it. Adding a shortcut key to the User Tool worked correctly and released the 2 key for it's normal purpose. Removing the shortcut key (in this case the 3 key) release the 3 key but reinstated the 2 key behavior of opening the Designer Reference PDF.
This Tool is in the 3rd position at the bottom of a 3 Tool list. If I move it to the 2nd position the 1 key opens the PDF. Moving the Tool to the top position then no key opens the PDF.
The 2 default Tools have shortcut keys CTRL/1 for ASCII Chart and CTRL/2 GUID Generator. Removing those 2 shortcut keys solved the problem. I put the 2 shortcut keys back in and the problem returned. This happens regardless of whether the CTRL, ALT or SHIFT (or all 3) is checked in combination with a key.
Hi Clive, I can honestly say that I can not follow what it is you're trying to convey in this report. You hit the "2" key and it opens the PDF but yet you have no shortcut key associated with the tool? How is that possible? Are you hitting Alt+T to activate the top menu "Tools" menu dropdown and then hitting the "2" key or something similar?
Open your WinFBE.ini file and paste here the lines in the Tools section:
[UserTools]
USERTOOL_00=ASCII Chart|-|.\UserTools\asciichart32.exe|-||-|1|-||-|1|-|0|-|0|-|0|-|0|-|0|-|1|-|0
USERTOOL_01=GUID Generator|-|.\UserTools\GUIDgen32.exe|-||-|2|-||-|1|-|0|-|0|-|0|-|0|-|0|-|1|-|0
I would interested to see that Tool that you created and how it is configured.
Hi Paul,
Here is my User Tools section:
[UserTools]
USERTOOL_00=ASCII Chart|-|.\UserTools\asciichart32.exe|-||-|1|-||-| 1|-| 0|-| 0|-| 0|-| 0|-| 0|-| 1|-| 0
USERTOOL_01=GUID Generator|-|.\UserTools\GUIDgen32.exe|-||-|2|-||-| 1|-| 0|-| 0|-| 0|-| 0|-| 0|-| 1|-| 0
USERTOOL_02=Designer Reference|-|C:\WinFBE_Suite\Help\WinFBE_VisualDesigner-Reference.pdf|-||-||-||-| 0|-| 0|-| 0|-| 0|-| 0|-| 0|-| 1|-| 0
USERTOOL_03=Designer Tips|-|C:\WinFBE_Suite\Help\WinFBE_VisualDesigner-Tips.pdf|-||-||-||-| 0|-| 0|-| 0|-| 0|-| 0|-| 0|-| 1|-| 0
Pressing the '2' key in any module opens the file associated in USERTOOL_02A '2' is not entered in to the text. Pressing 12345678 produces the text 1345678 - no 2. And "C:\WinFBE_Suite\Help\WinFBE_VisualDesigner-Reference.pdf" opens in Acrobat Reader.
I'll try to be more succinct and to the point in future. :-[
Thanks Clive!
I added those entries to my WinFBE.ini, and sure enough, I see EXACTLY the same problem that you are reporting. Pressing the "2" key (by itself) does indeed invoke the User Tool to open the visual designer pdf. That's one of the strangest things I've seen in a long time. :)
I will dig into this see where this strangeness is coming from.
In hindsight, your report was fine, I just couldn't understand it :)
Fixed. :)
I had to add "nKey = 0" to reset the value in the loop that processes the User Tools. The second Tool used "Ctrl+2" as the shortcut which left the nKey value = 2. The next Tool (the one that opens the pdf) doesn't have a shortcut but the nKey was still at a value of 2. This resulted in an accelerator key being created for the "2" key.
I am uploading a new package in the next hour with the fix.
Thank you, Paul :)
Somewhat off topic. Double-clicking an error in the Compiler Results list opens the offending module and moves the cursor to the error line, but the cursor is not visible. This is not too much of a problem if the Highlight Current Line option is checked, but without that option, there is no visual way to tell where the cursor is - but the keyboard is still partially active within the editor as well as the Compiler Results tab. Alphanumeric keys produce a chime and nothing else that is visible, the TAB key results in an editing tab at the Error line.
One exception (to the hidden cursor) is to open any other window or dialog box and either close it or alt/tab to it - the cursor will now be visible. Double-clicking the error in the Compiler Results list will hide it again.
In the image, the line containing "error2" is selected (no highlight, no cursor). The result of pressing the TAB key is in the second image.
Update: I just see your "Fixed" post. Thanks.
That's odd because on my system when I double click the compiler error listview (with highlight line setting off), I get taken the correct source code file with the cursor set to position 1 in the line and is blinking.
Anyone else readying this post experience what Clive is seeing?
What I'm seeing in the captures is that the font that he is using is not smooth (looks like a bitmap font from the past century). You made some changes to support it. Don't know if there is a relation.
Hi Paul,
QuoteWhat I'm seeing in the captures is that the font that he is using is not smooth (looks like a bitmap font from the past century). You made some changes to support it. Don't know if there is a relation.
It doesn't matter which font I use like Courier New (Windows 3.1 from 1992 - definitely from past century) or Lucida Console (or crisp or dina which are quite new by comparison to Courier New) or any other font, the result is still the same on my machines.
However, earlier versions of WinFBE do not exhibit this behavior.
I have tested it with WinFBE 32 and 64 bit on Windows 10 64 bit. I will test it tomorrow on Windows 7 32 bit to see if a different configuration triggers the behaviour.