Version 1.9.8 (November 7, 2019)
- Added: ListView ItemSelectionChanged event.
- Added: ListView ColumnClick event.
- Added: ListView.BeginUpdate and ListView.EndUpdate for situations when adding many items during a bulk add.
- Added: ListViewRow, ListViewColumn to the e EventArgs passed to certain ListView event handlers.
- Added: Code to manipulate ListView Columns Text, Width, Alignment, Add, Insert, Remove, Clear for situations outside of the Form's Initialize event.
- Fixed: Much faster deallocation of memory for large collections of items for controls like ListView and ListBox.
- Fixed: ListView Click event now only fires once rather then three times when fired.
- Fixed: freebasic_keywords.txt to remove duplicate entries (thanks cbruce).
- Fixed: Regression fixed whereby compile would fail for source code files that have spaces in their full path filename. However, the problem still persists if your WinFBE installation folder contains spaces. Install WinFBE to locations with folder paths containing no spaces until a permanent fix can be found for this problem.
https://github.com/PaulSquires/WinFBE/releases
Hi Paul, the link in your post for 1.9.8 is the URL for 1.9.7 https://github.com/PaulSquires/WinFBE/releases/tag/1.9.7 (https://github.com/PaulSquires/WinFBE/releases/tag/1.9.7)
Maybe it's my PC!
Sorry, I didn't "Publish" the release. It was still in Draft status.
You may see the "TreeView" icon in the ToolBox. That is still a work in progress and not yet usable.
It's there now, thanks.
I think i will have remembered every line of my test file before much longer. ;) Anyway, it takes 22 seconds to read in the file, and show the first few lines in a text box. It takes only 18 seconds to read in the file and display it in a listview, which allows scrolling over the whole file. So, I think that can count as another success for Paul.
Having programmatically selected a line e.g. frmmain.fileview.SelectedIndex = aline, how do I get that line, to show in the listview window?
Quote from: raymw on November 09, 2019, 10:00:55 AM
Having programmatically selected a line e.g. frmmain.fileview.SelectedIndex = aline, how do I get that line, to show in the listview window?
Not sure that I understand the question because if you know the SelectedIndex then you simply should only have to access the Item and SubItem:
frmmain.fileview.Item(aline).SubItem(0)
frmmain.fileview.Item(aline).SubItem(1)
frmmain.fileview.Item(aline).SubItem(2)
etc...
Hi Paul,
Basically, using your example code for listview, I want to be able to enter a value of 20, say and get the display in the attached image, without altering the values in the list, or using the scroll bars. I guess in pseudo code, I'm looking for 'display.top = 20, display.bottom = 26' I just can't think of the answer at the moment.
Thanks
Okay, you want to set the top item in the display window of the ListView to be your desired index. There is no ListView_SetTopIndex macro (even though a ListView_GetTopIndex exists). I did a quick search and adapted the code below from Gary Beene over in the PB forum:
Function ListView_SetTopIndex( byval hLV as hwnd, byval index AS Long ) AS Long
dim rc AS RECT
SendMessage( hLV, LVM_GETITEMRECT, 0, cast(LPARAM, @rc) )
function = SendMessage( hLV, LVM_SCROLL, 0, (index - GetScrollPos(hLV, SB_VERT)) * (rc.Bottom - rc.Top))
End Function
Set it using:
ListView_SetTopIndex( frmMain.ListView1.hWindow, 20 )
frmMain.ListView1.SelectedIndex = 20
Thanks, Paul, works great. (I was looking into ListView_Scroll, above my pay grade!)
Ray, Insure the mouse pointer isn't over the listview control or the Row will change from ListView_SetTopIndex( frmMain.ListView1.hWindow, some_number) to the mouse pointer position.
> There is no ListView_SetTopIndex macro
There is one that I prefer, Listview_EnsureViisble.
Thanks.
I'm coming to the conclusion, that it may not be best to have all the arrays as listviews, since I need to carry out various calculations, maybe, such as scaling the coordinates, removing ones outside or inside a particular area, and generally manipulate individual or chunks of items, and that would involve a lot of string/number conversions. I think, for my purpose it may be best to stick to the idea of using it as a viewer of lists, instead of using it as a list and viewing it.
With two lists, it is straightforward to tie together the selected items, but is it possible to get at the scroll bars, and coordinate their movements, possibly remove one scrollbar, but the other one controlling both lists?
I have a list of strings from the file, and another shorter list of a about a screen full of rows (about 80) of ten subitems. The subitems are parsed from the file list. The filelist scroll bar has a range of, say 0 to 2million, the parsed list scroll bar 0 to 80. If I select a file list line, then it can quickly parse 80 lines and display the resulting 10 or more. It would be nice to be able to get a line number directly from the scroll bar in the file list.
I've a feeling this may be an XY problem, where what I want to achieve is Y, but my thinking to get there I have to use X.
I guess I can in effect remove the scroll bar by ensuring the parsed view list is less than or equal to the number of lines it can show in the viewlist window. (for my particular, font number of rows = (frmmain.fileview.height -3)/15)
Quote from: José Roca on November 09, 2019, 04:27:14 PM
> There is no ListView_SetTopIndex macro
There is one that I prefer, Listview_EnsureViisble.
The only problem is that EnsureVisible doesn't place the item at the top of the window area. It will only ensure that it's visible somewhere within the window.
You can use:
ListView_EnsureVisible(hListview, item number + number of visible rows, TRUE)
ListView_EnsureVisible(hListview, item number, TRUE)
3 things I noticed:
1) I was testing an anomaly with the main menu where e.ListViewColumn and e.ListViewRow are popup choices in the Menu's Click event.
2) Any Menu choice will fire frmMain_Deactivate and associated shutdown routines. Then go on to load frmMain again (and associated startup routines) which partially locks up the program (the exit routines will still work with manual intervention but it's not very tidy).
3) I closed WinFBE 1.9.8 and opened WinFBE 1.9.0 to see if I could determine where 1 and 2 anomalies started. The older version 1.9.0 wouldn't load a ListView, a Statusbar or a Progressbar so I closed WinFBE 1.9.0 without saving or clicking on anything. Tried 1.9.1 and the same thing so I reverted back to the current 1.9.8 release and the ListView, StatusBar and ProgressBar were still missing...
I added the 3 (new) controls to frmMain and positioned and sized them roughly as before and all works the way it did before opening in 1.9.0.
Added note:
It appears as though after frmMain_MainMenu_Click() code resumes somewhere it shouldn't. I placed a Return 0 immediately after the first Select Case Str( sender.Name ) > Case "mnuExit" and the problem is still there.
More: I placed a Return 0 as the first line of code in frmMain_MainMenu_Click() and nothing happens until I give the Console focus then frmMain_Deactivate fires and all that entails (threads detach etc...).
Thanks. If got it to work quite nicely with ListView_EnsureVisible(frmmain.fileview.hwindow ,frmmain.fileview.selectedindex +displaylines-1,TRUE) I found it interesting, calculating the number of lines for the multicolumn listview, to ensure that the number of rows is no more than will fit in, so that the vertical scroll bar is not present for that list view, then having to subtract 1 since the fileview listview has a horizontal scrollbar. And then, if I change the font?
At the end, when this is all working, it will look very simple. If I need to go back and modify it, it will give me yet more headaches, a bit like programming in APL, but in that case you spent a day writing a line of hieroglyphics to change the world, the next day you found it hadn't, and you could never understand what you had written, and neither could anyone else.
edit to add - I've been testing the font sizes. It used to be that font sizes were in points, 72 to the inch, but that was in the analogue world. However, in Windows, it appears that the same size value for courier heights are less than the segoe ui, for example. By empirical testing, I have found, that for a text box and segoe ui, that the (font size * 1.83 ) +6 gives a usable text box height, for the usual range of font sizes, say 6 to 20. for courier, it is something like font size*1.4.
Quote from: SeaVipe on November 09, 2019, 07:55:54 PM
1) I was testing an anomaly with the main menu where e.ListViewColumn and e.ListViewRow are popup choices in the Menu's Click event.
2) Any Menu choice will fire frmMain_Deactivate and associated shutdown routines. Then go on to load frmMain again (and associated startup routines) which partially locks up the program (the exit routines will still work with manual intervention but it's not very tidy).
Hi Clive, I am trying to work through your post. I think in this case you may be misinterpreting what "frmMain_Deactivate" represents. That event is fired when the form loses focus, not when it is being closed. So, if your main menu pops up a message box the the focus will shift from the form to the message box...thus firing your Deactivate handler. If you want to handle form closing then you need to put tat code in frmMain_FormClosing or frmMain_FormClosed. This is assuming that I am understanding the problem that you are describing.
Thanks, Paul. I was starting to figure that out but I was focused on the main menu issue and hadn't quite linked the dots.
If I select a row with the mouse, it is highlighted blue, if programmatically, it is highlighted grey. Is it possible to be able to select these colours, possibly in designer toolbox properties? Is there a simple ratio between font size and row height in Pixels? If so what is it? Does the grid effect this?
I just these new Events:
- Added: ListView DoubleClick, RightClick events.
- Added: ListView Click event will now also fire if ENTER is pressed on a ListView line.
Quote from: raymw on November 10, 2019, 06:36:56 PM
If I select a row with the mouse, it is highlighted blue, if programmatically, it is highlighted grey.
It shows blue because it has focus. If the control loses focus then you'll get the grey. In code you can do this to set the selected index and also the focus to the control.
frmMain.ListView1.SelectedIndex = 0
frmMain.ListView1.Focused = true
Quote
Is there a simple ratio between font size and row height in Pixels? If so what is it? Does the grid effect this?
Windows automatically adjusts ListView row heights based on the font defined for the control. I don't know what magically forumla that is used. To set our own row height would entail having to write the ListView as an OwnerDrawn control and that is outside my scope of development for this ListView control.