Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Paul Squires]

Version 1.8.3 (November 10, 2018)
- Added: Back, Forward, Print, Find buttons to the Help Viewer display dialog.
- Added: MaximizeBox, MinimizeBox to the Help Viewer display dialog.
- Changed: The generated HTML help file code no longer imposes a fixed page width of 728 pixels.

https://github.com/PaulSquires/WinFBE/releases

[José Roca]

You should add the WS_CLIPCHILDREN OR WS_CLIPSIBLINGS styles to avoid flicker when resizing.

[SeaVipe]

Thanks, Paul!

Help Viewer:
FIND works perfectly, highlights each occurrence as it's typed into the find box making it very easy to locate results.


Quick observation: with Help Viewer open and with focus, the CTRL + key and F keys are still live in WinFBE editor, but other keys are not (I did not do a thorough test). CTRL/F opens the WinFBE Find dialog not the Help viewer dialog.



Also:

1) Is it possible for the Back and Forward buttons to move the tree highlight?


2) On my monitor the browser's bottom edge is (just) below the form bottom.


Here is a screenshot that demonstrates both 1 and 2 above...

[raymw]

nit picking again... when 'find' window open, no other help window actions work, it would be nice to be able to scroll through the text. If you back/forward, the tree view does not highlight current section. The find only operates on open section, which pre-supposes I know where whatever I'm looking for can be found. Find does not maintain the last search word entered when find window closed.

[Paul Squires]

Hi Ray yes Clive had somewhat similar suggestions that I will work on tomorrow. The find dialog is the one that is built-in to the web browser control. It is nodal and only works on the current document.

[Paul Squires]

I have also fixed an irritating bug whereby if you cancelled the New Project dialog that a phantom new project would remain in memory causing issues when closing the application.

[SeaVipe]

Hi Paul, I get a spurious mouse pointer hourglass during editing, usually after a failed compile. It takes quite a while to return to an arrow mouse pointer.

[Paul Squires]

Hi Paul, I get a spurious mouse pointer hourglass during editing, usually after a failed compile. It takes quite a while to return to an arrow mouse pointer.

That is a odd behaviour and one that I have never experienced. Prior to compiling, WinFBE sets the screen cursor and the cursor related to the active scintilla document to an hourglass. Once compiling finishes then the cursors are reverted to previous states. After that is when any processing of successful/failed compile is handled.

If you can recreate the steps then it would help me a lot to fix it. How is compile invoked - toolbar icon, top menu, F5 shortcut? Is a file open or is a project open? Moving your mouse elsewhere in the application (outside of the code editor window), change the cursor back?

[SeaVipe]

Will do. I'll keep an eye on it as it is not something I have been able to duplicate, it just happens periodically.

[SeaVipe]

Paul, in looking to duplicate the hourglass pointer I came across the following:

I removed Check1 checkbox from frmMain (the sample code you posted a few days ago) and removed the 3 events associated with it then attempted a compile. Image4 is the result - Linking Failed...


Image4 also shows Combo1 Click Event in the function list.

I then closed and restarted WinFBE and attempted a compile. Image5 is the result, where the function list correctly shows Check1 missing BUT also Combo1 - which was not removed and should still be there.


Image6 shows Combo1 in the Designer which has not been edited for many successful compiles.


Unchecking the Combo1 Click Event and rechecking it added the Click Event code back into frmMain but without its original code of course.


I seldom use folding but it's used here just so all of the functions in frmMain can be seen on 1 screen.


I hope you find this understandable and helpful.

[Paul Squires]

Hi Clive, thanks for the report. This one took me awhile to figure out. There was a bit of a 'chicken and egg' problem happening when code was deleted and then a compile took place. No checks were there to regenerate the missing code therefore DECLARE were generated for now non-existing Functions. I am pretty sure that I have that problem corrected now. I will upload new package later today.

[SeaVipe]

Thanks, Paul,

ComboBox:
KeyDown fires Click and KeyDown,
Nothing fires TextChanged

Off topic. Where should this line go: "frmMain.ShowInTaskBar = True" I've placed it just about everywhere and it does not appear to make any difference, the form is only shown in the TaskBar by ALT/Tabbing to it. Once selected, the form remains in the TaskBar until the program ends.

[Paul Squires]

TextChanged fires for ComboBoxes of style ComboBoxStyle.Simple. Those are the comboboxes that have a textbox on top where you can enter text.

[Paul Squires]

Hmmmm, yeah the ShowInTaskBar is not working correctly. I checked again and got it working by changing the extended windows styles to WS_EX_TOOLWINDOW or using WS_EX_APPWINDOW but using that approach obviously changes the caption bar style which is probably not what the user would want. I believe that Pierre posted a COM example over on the PB forum that could show/hide the taskbar icon. I will investigate that approach.

[Paul Squires]

Just so you folks know that I'm still working on getting the visual designer finished.... here is a screenshot of the next big addition to the WinFBE visual designer.