Seems to be difficult due to the dynamic appearance of the scrollbars. So will not be included..
Printable View
Hi Krool,
When selecting a large number of grid-rows with the mouse, VBFlexGrid can only scroll through many pages at a very slow speed to select hundreds or thousands of grid-rows, which takes a lot of time. Is it possible to make VBFlexGrid able to scroll quickly when selecting a large number of grid-rows?
I don't know if anyone understands what I mean. If anyone understands what I mean, hopefully he could explain it to Krool.
Can you record a video of your screen? Maybe then....
Thank you, Calcu and Arnoutdv.
I'll rephrase my problem.
When we need to select a lot of grid rows with the mouse, we do it like this:
(1) Click on the first row you want to select
(2) Hold down the mouse and drag down, and the grid rows will start to scroll
(3) Soon, the mouse moves to the bottom of the grid component and moves outside the grid.
(4) When the mouse has moved outside the grid the grid should continue to scroll, and the scrolling speed should be more than three times the normal scrolling speed (i.e., the speed of the mouse inside the grid).
(5) When all the grid rows to be selected have been included, the mouse should move up to the grid, and the scrolling speed of the grid will return to the normal state (i.e., slow down). At this point, the mouse can select exactly the hundreds or thousands of rows that need to be selected.
My requirement is that when the mouse has moved outside of the grid, the grid should scroll at more than three times the normal scrolling speed (i.e., the speed of the mouse inside the grid).
@SearchingDataOnly: I've tried it in a grid with about 4.500 Rows. Selected row 1 and moved down outside the control, still button pressed. Now moved the mouse erratic fast outside the control, e.g. to the left and right, and so the selection in the grid sped up. Is this like what you want to have? In my opinion the selection speeds up with the movement of the mouse, and it is fast.
Greetings
I personally am not a big fan of doing such a select using "auto scrolling", and especially not when the scroll starts accelerating, as it's usually hard to stop at the right moment. I would select the first row, use the slider in the scrollbar to quickly go to the end of the selection, press <Shift> and then click the last row that has to be selected.
@SearchingDataOnly: I tested it on a 84,000 rows grid in the IDE (I had to change my code to display the number of selected rows) and it took me 5 seconds to mark about 5,000 rows - in my opinion it's fast (and my PC is really outdated :-)). But as Erwin69 mentioned, it's almost impossible to stop on a certain row. So I'd prefer another method to select that much rows, e.g. via keyboard (ctrl + pagedown, slower) or via code (if possible). So in the first place, what's the goal?
Greetings
Yep, the greater the (Pixel-)-distance in y-Direction from a "Fix-Point" -
the higher the "Rows-per-Tick"-speed in the ScrollTimer-Event (which you probably already have anyways).
The only difference is, that there's now two "Fix-points" you measure Pixel-distances from:
- in Scroll-down-mode, the Pixel-Diff is measured as Delta to the BottomLine of the Ctl
- in Scroll-up-mode, to the Top-Line of the Ctl respectively
For the cwVList-Widget, I think I have 3 speed-levels (related to the Pixel-Delta):
- 1-15 = "normal speed"
- 16-30 = "higher speed"
- > 30 = "highest speed"
Olaf
Thanks Schmidt. Before in getting into the acceleration topic there is one more fundamental thing to solve first.
Currently the scroll is reacting upon WM_MOUSEMOVE. (SetCapture)
That's fine and keep like that BUT:
For my non-OLE DragRow/DragCol methods which enter a modal message loop I have timers which ticks when mouse is idle, so it's a combination of WM_MOUSE and SetTimer/KillTimer. Any WM_MOUSEMOVE will reset the timer to not have "double" thing.
Question is now I guess I should add this to the normal scrolling also? Certainly vsFlexGrid seem to do it.
This should be separable with relative ease, via proper bool-Flags -
which depend on, whether MouseY is inside the Control or not (whilst the Mousekey is down).
If outside the Control, then only the timer is responsible, if inside the Control, then only Mouse_Move...
Olaf
I based the logic upon https://devblogs.microsoft.com/oldne...5-00/?p=104757
To note is that for "down" scrolling there is an acceleration the farther the mouse is. This is due to the fact that the selection will extend to the current mouse row/col.
For "up" scrolling it is currently just 1 line. So, there a small function could calculate the amount of lines to be scrolled based on the distance. Like it's already for the "down" scroll.
Then that's solved, the acceleration part for "up" is missing. Then a timer could help to scroll when mouse is idle and outside the scroll-able area ..
Update released.
Improvement in the "capture mouse move" scroll.
The "down" and "right" scroll build up acceleration due to MouseRow/MouseCol.
However, the "up" and "left" scroll was too simple and just did a single line scroll.
Now the number of lines are calculated based on the distance and edge of fixed rows/cols.
So, all directions behave and feel now the same for the user.
@SearchingDataOnly, now I understand what you mean. I couldn't repro because I just did a "down" scroll on "capture mouse move" scroll.
It speeds up now also on "up" and "left" scroll. Plus the more you wiggle the mouse the more often a "mouse move" occurs.
IMO I think we can save the overhead here to integrate a timer here on a "capture mouse move" scroll when the mouse is idle for a moment?
This also has a benefit for the user to "pause" the scroll and continue when moved again. :)
For the "non-OLE drag row/col" the timer was useful because it scrolls when near the edge of the scroll-able area, so the user can pause any moment by moving the mouse to the scroll-able area and continue when moving against the edge again.
@Krool, @Olaf, @Seniorchef,
A good scrolling algorithm/pattern is essential for modern spreads/grids.
VSCode's scrolling algorithm is excellent. I'm going to use VSCode as an example to illustrate what some good scrolling algorithms look like.
1. Open the source code of VBFlexGrid.ctl with VSCode.
2. Select a row with the mouse and drag the mouse down to select more rows.
3. When the mouse reaches the horizontal scroll bar at the bottom of the code window, the page starts scrolling.
4. Even if the mouse is stationary/resting on the horizontal scroll bar at the bottom of the code window, the page scrolling is still going on
5. Continue to move the mouse down, and when the mouse leaves the horizontal scroll bar at the bottom of the code window, the scrolling starts to accelerate
6. When the mouse leaves the code window, even if the mouse is stationary, the page scrolling is still frantic.
7. The longer you hold down the mouse, the faster the scrolling speed seems to increase.
8. When you have selected enough rows, move the mouse back to the code window, at this point, the scrolling stops, and then you can use the mouse to select the grid rows exactly.
VSCode is a perfect example of what a good scrolling pattern looks like.
@SearchingDataOnly, did you test the new update ?
As further information.. the MS(H)FlexGrid is also lame/lazy (1 liner scroll only) on the "up" and "left" "capture mouse move" scroll.
So the VBFlexGrid is in this regard now better as to take the distance and calculate actual number of lines to scroll, like in the "down" and "right" scroll which is done naturally due to MouseRow/Col.
Yes, I tested it yesterday. It seems to be a little faster, but it's not noticeable. The reason for this is that when I move the mouse outside of the grid, I need to keep moving the mouse left and right to keep scrolling. As soon as the mouse stops moving, the scrolling of the grid stops. It is recommended that the scrolling of the grid should continue even if the mouse is stationary.
VBFlexGrid is getting better and better. Five years ago, the performance of VBFlexGrid was only a few tens of times that of Farpoint-Spread. Now, the performance of VBFlexGrid has surpassed that of Farpoint-Spread
Update released.
Support of the VP_FORMATRANGE message. (like MS(H)FlexGrid and vsFlexGrid)
See the demo VB6 Simple EMF-based FlexPrint-Reporting (incl. Print-Preview) by Olaf of how it can be used.
Info: I couldn't figure out what rcPage is actually needed for and it is ignored for now .. it uses only rc where the actual drawing appears. (FORMATRANGE)
Also I couldn't figure out the actual difference (in code) for hdc and hdcTarget. So only hdc is taken into account.
Hi, new question, wordwrap works if you have an space on the line, but is there any option to wrap by character? i mean, this line:
11212,1311,13131,131313,131313,131313,1313131,131313,13131,131313
I can't find a way to wrap it.
but this one:
11212, 1311, 13131, 131313, 131313, 131313, 1313131, 131313, 13131, 131313
works as expected.
Thanks! that was perfect.
Hi all, i'm having a problem and i can't check if it's me or...
can somebody check if this works with the last version?
If i use:
the cell from row 1 and col 2 will have the background red.Code:grid.cell(FlexCellBackColor, 1, 2 ) = vbRed
But if i use:
It's not painting from the col 2 to col 8, it's painting col 2, but not from 2 to 8. or this 2 last options aren't for this ?Code:grid.cell(FlexCellBackColor, 1, 2, 1, 8) = vbRed
thanks!
Update released.
Included enum FlexPictureTypeEnhMetafile for the PictureType property.
This enables much better results on Printer.PaintPicture on the .Picture property. (vbPicTypeEMetafile)
The VP_FORMATRANGE message will render according to the PictureType property. (Color, Monochrome or EnhMetafile)
Of course EnhMetafile will give best results when rendering to a PDF printer or such ..
The OCX 1.7 got also updated using the EditTLB tool.
I responded to your question back in Oct 5th 2023 to workaround this by using SetWindowPos on the EditSetupWindow event.
However, vsFlexGrid seems to increase the drop-down list width when the longest entry is wider then the cell width.
Should VBFlexGrid maybe also here "automatically" make the width based on the cell width, and while inserting the items measure them and increase the drop-down list width, if necessary ?
Or should we offer extra functions/properties to set these and react on an event ?
Of course doing this by default would feel intuitively and standard behavior. Risk is here only to have an extreme wide drop-down list when there is a large entry...
I vote for the auto width, i think we can limit the large of an input in a lot of places/events.
Update released.
The width of the combo drop-down list now auto-fits.
This means the minimum width by default is the cell boundary. If an list entry is larger then the drop-down list width is adjusted to the bigger size.
There should be no "compatibility" break as this is the initial window size.
Any existing code to change the width via SetWindowPos on the EditSetupWindow event will continue to work as it fires after the initial setup.
Update released.
Support of vbTab in the ComboItems/ColComboItems run-time property.
This allows for a real multi-column drop-down list. (owner-drawn)
If there is no vbTab in the ComboItems then the drop-down list is not owner-drawn.
Attachment 192322
The feature plays nice with the recent auto-fit change.
QUESTION: Should the gray-line between the columns be always gray, even when selected ? Currently the color changes to highlight text color.
Update released.
Included the ComboHeader/ColComboHeader run-time property.
This allows to define a header for the multi-column drop-down list. (non-client area)
Attachment 192342