WinFBE Suite 2.0.1 (December 13, 2019)

[Paul Squires]

Version 2.0.1 (December 13, 2019)
- Added: Month Calendar control.
- Added: DateTimePicker control.
- Added: TabControl control. (still a work in progress but it is currently usable).
- Added: ToolTip and ToolTipBalloon properties for most controls.
- Added: New form property called ChildForm. Creates form with WS_CHILD style and is used when specifying child Tab Pages for Tab Control.
- Changed: Updated German language file as provided by Joerg Buckel.
- Fixed: ListView Hover event was not removed from the Visual Designer list of selectable methods.
- Fixed: ListView GPF if number of defined subitems did not match number of defined columns.
- Fixed: ListView regression whereby mouse clicking on checkbox item was not being recognized.
- Fixed: ListView GPF if horizontal scroll bar moved to the right and then all columns deleted.
- Fixed: ListView text property changes were not being immediately displayed (programmer would have to do a manual call to Refresh first).
- Fixed: Attempting to close an unsaved new file belonging to an open project would not remove the reference to that file from the project.
- Fixed: Bug whereby switching amongst Forms would cause changed Property values to also follow to the newly selected form and cause that form to show as "dirty" and needing to be saved.
- Fixed: RichEdit TextAlign property not showing a list of valid choices.

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

[raymw]

Thanks Paul, a couple of misleading bugs fixed, which were probably bugging my stuff, afaik, and thanks for adding the tooltips.

[SeaVipe]

Thanks, Paul! Calendar works great. I'll try Tab control next.
Couple of things:
Existing ListBox has developed a significant quiver when mouseover (Not an Event that is checked, just Click).
Existing ListView with 30 Items and 3 SubItems takes about 2 to 3 seconds to populate. It appears to be refreshing multiple times but the flicker of visual data is just too fast to tell (Added BeginUpdate/EndUpdate and that appears to have sped things up somewhat but still slow).
Also, same ListView, setting colours with WFBE 2.0.0 using .Refresh after the colours were set simply changed the FG and BG colours, with 2.0.1 the ListView clears and about a second or so later refreshes with correct colour changes.

Code Select Expand



Sub set_rows_colour(  ByVal fg as Long, ByVal bg as Long )
    With frmMainj.lvJournal
        .BeginUpdate
        For ubRow as UByte = 0 to .Items.Count - 1
            .Item( ubRow ).SubItem( 0 ).ForeColor = fg
            .Item( ubRow ).SubItem( 1 ).ForeColor = fg
            .Item( ubRow ).SubItem( 2 ).ForeColor = fg
            .Item( ubRow ).SubItem( 3 ).ForeColor = fg


            .Item( ubRow ).SubItem( 0 ).BackColor = bg
            .Item( ubRow ).SubItem( 1 ).BackColor = bg
            .Item( ubRow ).SubItem( 2 ).BackColor = bg
            .Item( ubRow ).SubItem( 3 ).BackColor = bg
       
        Next ubRow
        .EndUpdate
        .Refresh
    End With
End Sub


[raymw]

List view flicker is there when populating the list. Is it because

- Fixed: ListView text property changes were not being immediately displayed (programmer would have to do a manual call to Refresh first).

Not had chance to test if I can make it go away, but it is 'nasty' as it is now.
done a bit more testing. For my purposes, listview is now unusable. Also compiling takes longer, and when the form is first presented on screen, with no data in the listview, it takes a while to show the blank listviews. The tooltip seems to be OK, 'though.

[raymw]

for tooltips, it seems you have to put a character in the tooltip property in the toolbox - you can not put something like (geditform.fz.tooltip= "find z ") in your form_load code, without first putting something in the tooltip property at the gui design stage. It's not limited to 80 chars. It's actually sort of interesting. The tool tip takes a while to generate on screen. If I generate 2800 chars as the tool tip, it appears for only an instant, if I generate 3000 or so characters, the window of opportunity closes, before anything is shown. I'm emphasizing this is not a problem, just interested in what the limits are. Most tips will be most likely 20 or 30 characters and there is enough time to read them.

[Paul Squires]

I had to make changes to the Listview display so that you didn't have to manually do a refresh. Looks like that "fix" is causing too much flicker now from the sound of your reply posts. I will look at the problem again and see if I can come to a better solution. I will post a new package Monday evening December 16.
Thanks for the heads up on the Tooltip at runtime. I know what that problem is.  :-)

[raymw]

Hi Paul, The manual refresh did not bother me in the way in which I was using listview in version 2.0.0, since I couldn't smoothly scroll over the whole list of a couple of million rows in one go, (no scroll bars yet in winfbe), but refreshing about 100 rows of ten columns was more or less instantaneous. The 'list', is mainly ten columns of single or integer numbers, and the values are converted to strings for listview to display, as I hop around the list. I've not, as a user, tried manually changing the string values directly, and expecting that to reflect back into the full list. It isn't just the flicker, it's the time taken (similar to listing the whole file in the console window). I think I'll reload v2.0.0 until Mon night, although Ii could use shorter lists for testing, and live with the couple of seconds delay/flicker, I'll see how it goes.
Best wishes

edit to add - resizing is also tardy, have to move the curser very slow to get window with listviews to follow.

Also, Although you fixed the search/replace all a few weeks ago, if you replace one by one, instead of replace all, it does not go to the next item. e.g. replace '1' by '21' in a line like '123412341234' after a number of replaces gives '22222222123412341234' instead of '212342123421234 etc.'

[Paul Squires]

Existing ListBox has developed a significant quiver when mouseover (Not an Event that is checked, just Click).

My fault. A slip of my typing fingers when adding the control type to the code. I accidently used ListView when I should have used ListBox.

- Fixed: ListBox code regression in wfxApplication.inc WM_ERASEBKGND handler that caused excessive visual flicker (ControlType.ListBox was accidently set to ControlType.ListView).

[Paul Squires]

Existing ListView with 30 Items and 3 SubItems takes about 2 to 3 seconds to populate. It appears to be refreshing multiple times but the flicker of visual data is just too fast to tell (Added BeginUpdate/EndUpdate and that appears to have sped things up somewhat but still slow).

Okay, I figured this one out finally. Everytime the Text or Colors were changed in the ListView I was issuing a refresh of the ListView. It didn't matter if the item was visible or not. I introduced a call to ListView_IsItemVisible to determine if the item is visible on screen and if it is then only do the redraw. Everything is now significantly faster.

- Fixed: ListView now draws significantly faster becase only affected changed visible line items invoke a redraw of the ListView. Uses ListView_IsItemVisible to determine if item is visible.

[Paul Squires]

Also, same ListView, setting colours with WFBE 2.0.0 using .Refresh after the colours were set simply changed the FG and BG colours, with 2.0.1 the ListView clears and about a second or so later refreshes with correct colour changes.

Code Select Expand



Sub set_rows_colour(  ByVal fg as Long, ByVal bg as Long )
    With frmMainj.lvJournal
        .BeginUpdate
        For ubRow as UByte = 0 to .Items.Count - 1
            .Item( ubRow ).SubItem( 0 ).ForeColor = fg
            .Item( ubRow ).SubItem( 1 ).ForeColor = fg
            .Item( ubRow ).SubItem( 2 ).ForeColor = fg
            .Item( ubRow ).SubItem( 3 ).ForeColor = fg


            .Item( ubRow ).SubItem( 0 ).BackColor = bg
            .Item( ubRow ).SubItem( 1 ).BackColor = bg
            .Item( ubRow ).SubItem( 2 ).BackColor = bg
            .Item( ubRow ).SubItem( 3 ).BackColor = bg
       
        Next ubRow
        .EndUpdate
        .Refresh
    End With
End Sub


I took your code above and made a more general function from it. I changed the fg and bg to COLORREF parameters; allowed the passing of any ListView object; and changed the hardcoding of the subitems to use a For/Next loop over the SubItems collection.

You call the function something like this:

set_rows_colour( frmMain.ListView1, colors.white, colors.red )

Code Select Expand


Sub set_rows_colour( byref ListView as wfxListView, ByVal bg as COLORREF, byval fg as COLORREF )
   With ListView
      ' Because we are manually setting specific foreground and
      ' background colors, we do not want any color defined for
      ' the OddRowColor property to interfere. Therefore, set
      ' that property to equal our incoming backcolor.
      .OddRowColor = bg
      .BeginUpdate
      For iRow as long = 0 to .Items.Count - 1
         For iCol as long = 0 to .Item(iRow).SubItems.Count - 1
            .Item(iRow).SubItem(iCol).ForeColor = fg
            .Item(iRow).SubItem(iCol).BackColor = bg
         next iCol
      Next iRow
      .EndUpdate
   End With
End Sub