PlanetSquires Forums

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2 3

Author Topic: WinFBE Suite 1.9.7 (November 2, 2019)  (Read 925 times)

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8913
  • Windows 10
    • PlanetSquires Software
WinFBE Suite 1.9.7 (November 2, 2019)
« on: November 02, 2019, 08:29:15 PM »

Version 1.9.7 (November 2, 2019)
- Fixed: ListView notifications (Events) failing on 64 bit compiles.
- Fixed: Added back several missing Codetip popup items for the ListView.

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

This release fixes the few problems that have been reported related to the new ListView control.
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

SeaVipe

  • Senior Member
  • ***
  • Posts: 229
  • Windows 10
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #1 on: November 02, 2019, 09:34:05 PM »

Hi Paul,
ListView Click Event: 1 click any row any column and Click event fires 3 times. Clicking the same row (any col) a second time has no effect.
Logged
Clive Richey
There is nothing government can give you that it hasn't already taken from you in the first place. Winston Churchill

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8913
  • Windows 10
    • PlanetSquires Software
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #2 on: November 04, 2019, 11:46:46 AM »

Hi Paul,
ListView Click Event: 1 click any row any column and Click event fires 3 times. Clicking the same row (any col) a second time has no effect.

Thanks Clive, I am looking into a different method for handling "Click". I believe that now it only fires when the selection changes rather when an item (or subitem) is clicked on. I will add a new event named something like "ItemSelectionChanged" to indicate that the selected row has changed. I also need to implement an event for "ColumnClick".
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

SeaVipe

  • Senior Member
  • ***
  • Posts: 229
  • Windows 10
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #3 on: November 04, 2019, 12:37:42 PM »

On my test form, Paul, moving the mouse pointer away from the ListView's "grid" to any other control (or the ListView's header row) and then moving the mouse pointer back to the non-header portion of the ListView, causes the Click event to fire 3 times (as per a mouse click) and displays the correct iTem and SubItems (using HitTest). No other Events are checked in the Visual Designer for the ListView control. Win64 Console (Debug)
Logged
Clive Richey
There is nothing government can give you that it hasn't already taken from you in the first place. Winston Churchill

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8913
  • Windows 10
    • PlanetSquires Software
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #4 on: November 04, 2019, 03:01:41 PM »

Thanks Clive, I have noticed this also. Basically, when you bring back the mouse cursor over the Listview it will "automatically" select the row under the cursor even if you don't click on it. Moving the mouse over other rows does not select any of those rows (as you would expect if a hot tracking extended style such as LVS_EX_TRACKSELECT was present). It only happens if you move the mouse cursor off of the control and then back over the control again. I need to figure out why this happens because it is bothering me greatly :)
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

raymw

  • Senior Member
  • ***
  • Posts: 355
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #5 on: November 04, 2019, 03:20:29 PM »

listview questions and ramblings.
 
Will it be able to handle files of say 5 million lines long, and ten columns, possibly sparsely populated? Is the size limit going to be memory or number of lines/whatever.

The example in the winfbe editor help
Code: [Select]
Row count = frmMain.ListView1.Items.Count
Selected count = frmMain.ListView1.Items.SelectedCount
Current row = frmMain.ListView1.SelectedIndex

dim i as Long

i = frmMain.ListView1.Columns.Add( "Column 1", 100, TextAlignment.Left )
i = frmMain.ListView1.Columns.Add( "Column 2", 100, TextAlignment.Center )
i = frmMain.ListView1.Columns.Add( "Column 3", 100, TextAlignment.Right )

for ii as long = 0 to 99
   i = frmMain.ListView1.Items.Add( "Line " & ii )
   frmMain.ListView1.Item(i).SubItems.Add( "L" & ii & "Sub1" )
   frmMain.ListView1.Item(i).SubItems.Add( "L" & ii & "Sub2" )
next

frmMain.ListView1.Item(0).SubItem(0).ForeColor = colors.Red
frmMain.ListView1.Item(0).SubItem(2).ForeColor = colors.Red

frmMain.ListView1.Item(2).ForeColor = colors.Blue
frmMain.ListView1.Item(2).BackColor = colors.Yellow
frmMain.ListView1.Item(2).SubItem(1).ForeColor = colors.Blue

frmMain.ListView1.SelectedIndex = 0

the first three lines should be comments.

It makes more sense to me, to dispense with variable 'i' long. Somewhat unusual that a variable on the lhs is being changed without said variable being used. It works for me as far as the example shows and a bit more, but possibly it may cause problems later on. Is the intention, that the end user will be able to edit/delete values in listview?
   
 
Code: [Select]
   
 frmMain.ListView1.Columns.Add( "Column 1", 100, TextAlignment.Left )
  frmMain.ListView1.Columns.Add( "Column 2", 100, TextAlignment.Center )
 frmMain.ListView1.Columns.Add( "Column 3", 100, TextAlignment.Right )

for ii as long = 0 to 90
  frmMain.ListView1.Items.Add( "Line " & ii )
   frmMain.ListView1.Item(ii).SubItems.Add( "L" & ii & "Sub1" )
   frmMain.ListView1.Item(ii).SubItems.Add( "L" & ii & "Sub2" )
next

frmMain.ListView1.Item(0).SubItem(0).ForeColor = colors.Red
frmMain.ListView1.Item(0).SubItem(2).ForeColor = colors.Red

frmMain.ListView1.Item(2).ForeColor = colors.Blue
frmMain.ListView1.Item(2).BackColor = colors.Yellow
frmMain.ListView1.Item(2).SubItem(1).ForeColor = colors.Blue

frmMain.ListView1.SelectedIndex = 0
I have a number of minor questions.

afaik you are defining the number of rows as 100 in the following
 frmMain.ListView1.Columns.Add( "Column 1", 100, TextAlignment.Left )

but you can enter any value in the fill loop e.g.
for ii =0 to 1000
it will fill 1000 rows. (I've not tried answering my first question, for ii= 0 to 5000000) There is always a blank row at the end (almost as if being trapped by the basic language not knowing whether the first item is a 1 or a zero - but I guess that tells you you've got to the end. If the text is longer than the width of the column, you put ellipsis at the end, but can the whole text be viewed (scroll bar/multi line)? Will it be possible to alter the colour, or darken the grid lines.

In general, I think the referencing system to a specific location, row, column, is rather convoluted and confusing. There appears to be too many item/subitem/items. Is there an argument/discussion where column could not be used instead of subitem? It may not be so, but if you show a grid to someone, they generally refer to rows and columns, not items and sub items. I think a sub item is thought more in relationship to a branch /leaf on a tree structure or profit/loss accounting, not engineering.

I hope this doesn't come over as being too critical, if I didn't think much of what you were attempting, I wouldn't be here, trying to break things  ::)

Best wishes,

Ray

edit to add, I'm guessing it is a memory limit. using above code, ii=0 to 750000 runs OK, but ii=0 to 760000 or above, does not run. I maybe able to squeeze in my 2M lines.

 again - the line such as frmMain.ListView1.Columns.Add( "Column 1", 100, TextAlignment.Left )   the 100 is NOT the length of list, but somehow connected to the width of the column, but although the columns seem to be for text, the 100 is not number of characters, maybe pixels or something. A pretty rubbish example, imnsho. comments would be helpful.
« Last Edit: November 04, 2019, 04:29:51 PM by raymw »
Logged

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8913
  • Windows 10
    • PlanetSquires Software
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #6 on: November 04, 2019, 06:06:11 PM »

...causes the Click event to fire 3 times (as per a mouse click)
Got this one fixed. I was not filtering out the state change to isolate the LVIS_SELECTED state.
Fix will be in the next update.

Also, as you can see, in addition to the CLICK event, I have also added a ITEMSELECTIONCHANGED event.

Code: [Select]
                  if lNotification = LVN_ITEMCHANGED then
                     dim lpStateChange as NMLISTVIEW ptr = cast(NMLISTVIEW ptr, pNMHDR)
                     IF (lpStateChange->uChanged AND LVIF_STATE) = LVIF_STATE THEN 
                        if (lpStateChange->uNewState AND LVIS_SELECTED) = LVIS_SELECTED then
                          if pListView->OnItemSelectionChanged Then pListView->OnItemSelectionChanged(*pListView, e)
                        end if         
                     end if
                  end if   
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

raymw

  • Senior Member
  • ***
  • Posts: 355
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #7 on: November 04, 2019, 06:12:22 PM »

No use me winging, nobody listens... anyway I thought the proof of the pudding etc. so I started replicating something similar to that which I had written using firefly, last December, and it used the virtual list (or what I used to call a circular buffer) concept to handle large files. As it is, the raw listview will not accept files of that size, but I will look at including the vlist code. The listview looks a bit prettier than my firefly gui of a number of list boxes side by side. Just for proof, I've put a jpeg of part of the screen below. One thing that will be a bit of a gotcha, is that the whole view, or at least a whole row, must be populated at one go, even if by using code similar to frmmain.ListView1.item(j).subitems.add ("") . As always, when reading in large files, it is a toss up between displaying some sort of counter, or saving a bit of time. I think, but have not tested, that even though I read a line at a time and fill a row, the the listview is not displayed until all the file is read. But early days, yet.
Logged

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8913
  • Windows 10
    • PlanetSquires Software
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #8 on: November 04, 2019, 06:17:29 PM »

Will it be able to handle files of say 5 million lines long, and ten columns, possibly sparsely populated? Is the size limit going to be memory or number of lines/whatever.
Seriously doubt that there would be enough memory to hold that many items. Even Microsoft Excel is limited to 1,048,576 rows per worksheet. If you are trying to display 5 million items in a Listview then you may want to rethink your UI because I can't imagine a user trying to navigate 5 million rows.

Quote
The example in the winfbe editor help ......
Those are fair points. The documentation is pretty sparse right now because I am still flushing out some of the ListView functionality. I will give the documentation a better pass very soon.


Quote
afaik you are defining the number of rows as 100 in the following
 frmMain.ListView1.Columns.Add( "Column 1", 100, TextAlignment.Left )
100 refers to the width of the column that you are adding. It is measured in pixels (the value is high dpi aware).

Quote
but you can enter any value in the fill loop e.g.
for ii =0 to 1000
it will fill 1000 rows.
That will create 1001 rows. Also, ListView rows start at number 0. Just about everything in the Windows api and every C based language is zero based. BASIC variants seem to have always allowed 1 based but when you try to use that with Windows api then you have to do the -1 adjustment. You see this a lot when PowerBasic programmers try to use DDT along with Windows api.

Quote
In general, I think the referencing system to a specific location, row, column, is rather convoluted and confusing. There appears to be too many item/subitem/items. Is there an argument/discussion where column could not be used instead of subitem? It may not be so, but if you show a grid to someone, they generally refer to rows and columns, not items and sub items. I think a sub item is thought more in relationship to a branch /leaf on a tree structure or profit/loss accounting, not engineering.
I did it this way because this is the terminology that Microsoft .NET uses.

Quote
I hope this doesn't come over as being too critical, if I didn't think much of what you were attempting, I wouldn't be here, trying to break things 
I appreciate every word you've written! Thanks!

Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Josť Roca

  • Guru Member
  • *****
  • Posts: 3215
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #9 on: November 04, 2019, 06:53:18 PM »

It uses Item and Subitem instead of Row and Column because a ListView is not a grid. It only looks like a  grid when used in report mode, but if you use icon view or tile view, then row and column would be misleading and inappropriate.

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8913
  • Windows 10
    • PlanetSquires Software
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #10 on: November 04, 2019, 07:03:29 PM »

Also, as you can see, in addition to the CLICK event, I have also added a ITEMSELECTIONCHANGED event.

I have also added a COLUMNCLICK event. I have added two properties to the e EVENTARGS that are passed to CLICK, COLUMNCLICK, and ITEMSELECTIONCHANGED. These are ListViewRow and ListViewColumn. This allows you to write code like the following:

Code: [Select]
''
''
Function frmMain_ListView1_Click( ByRef sender As wfxListView, ByRef e As EventArgs ) As LRESULT
   ? "ListView CLICK.  e.ListViewRow: "; e.ListViewRow
   Function = 0
End Function

''
''
Function frmMain_ListView1_ItemSelectionChanged( ByRef sender As wfxListView, ByRef e As EventArgs ) As LRESULT
   ? "ListView ITEMSELECTIONCHANGED.  e.ListViewRow: "; e.ListViewRow
   Function = 0
End Function

''
''
Function frmMain_ListView1_ColumnClick( ByRef sender As wfxListView, ByRef e As EventArgs ) As LRESULT
   ? "ListView COLUMNCLICK.  e.ListViewColumn: "; e.ListViewColumn 
   Function = 0
End Function
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

raymw

  • Senior Member
  • ***
  • Posts: 355
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #11 on: November 04, 2019, 09:04:41 PM »

Hi Paul and Jose. thanks for the reply. The example image that I posted a bit earlier on, I find I can read in about 220000 (220k) lines of similar code before it crashes. (that is parsing and populating the ten columns, as necessary). It is very critical that you know how to count! If you have ten columns, you can't just populate nine, unless there are settings unknown to me. I think I'll see if I can blend in the Vlist algorithm that I used in firefly, to get more rows. Once I've got it working with the number of lines I need, then I'll be playing with editing, I expect, which so far looks to be fairly straightforward. Presumably I can get as well as set the text colors for each item.

edit to add - tried 64bit got 595698 lines. tried the larger file 3.2 million lines , took ages to load, I think it stalled on parsing.  I'll have a look later, it's late night/early morning here. But, in firefly, it loads very quickly, and completes populating in a couple of minutes. I'm getting the impression that firefly ran much quicker, certainly with my attempts at cgi graphics.
« Last Edit: November 04, 2019, 09:59:32 PM by raymw »
Logged

SeaVipe

  • Senior Member
  • ***
  • Posts: 229
  • Windows 10
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #12 on: November 04, 2019, 10:05:26 PM »

Hi Ray, How about only populating the ListView with a "range" of Rows that the user can comfortably navigate? Perhaps the height of the screen plus some number that can quickly be added or subtracted as the user scrolls up and down through the list. This would greatly cut down on memory usage.
Logged
Clive Richey
There is nothing government can give you that it hasn't already taken from you in the first place. Winston Churchill

Josť Roca

  • Guru Member
  • *****
  • Posts: 3215
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #13 on: November 04, 2019, 11:09:08 PM »

It's crazy to try to populate a ListView with so many items. The best approach is to use a virtual ListView and provide the data on demand. This way, you can have as many items as you wish.

raymw

  • Senior Member
  • ***
  • Posts: 355
Re: WinFBE Suite 1.9.7 (November 2, 2019)
« Reply #14 on: November 05, 2019, 11:30:58 AM »

Quote
I think I'll see if I can blend in the Vlist algorithm that I used in firefly, to get more rows.

But, where is the acceptable non crazy limit? I had thought that listview had incorporated something like that vlist facility, since it was mentioned that listview handled thousands of items, or similar, iirc. I had already asked whether the limit was memory size, or something else. I guess nobody says 'cos nobody knows.

All I'm doing is testing. The best way, often, is to test it in the real world, on applications/data that I know. I have found out a fair bit on how listview behaves in the last day or so. it is robust enough within it's limits, (whatever they may be), but it does not fail gracefully. I'm not saying that is a good or bad thing, it doesn't need to be bogged down in data validation, but either information needs to be available in a way that I can understand, or I'll have to work it out for myself, or do something entirely different.

Logged
Pages: [1] 2 3