VBFlexGrid Control (Replacement of the MSFlexGrid control)

Quote:

---

Originally Posted by Schmidt

FG.TextMatrix, as well as FG.Clip (and probably all other stuff) is routed to GetData/SetData of the DS-implementation, as soon as this was set.

---

Can you also please check if, once an DS-implementation is set, it is still possible to modify the '.Rows' property or to call 'AddItem'/'RemoveItem' because that would interfere in the number of records indicated by the DS-implementation and could raise an outer bound error?
Thanks

Update released.

Beside other small new features this update includes the FlexDataSource (run-time only) property which allows to define a custom (private) data source via the IVBFlexDataSource interface.
The definitions are equally to vsFlexGrid (IVSFlexDataSource) and hopefully also the behavior. The behavior in regard to row/col offset should match.
Concerning the behavior of the limitation (function disabling) I am not sure. However, they are now as following:
- Sort not possible
- Clear method is restricted. (not possible to clear text, only to clear formatting is possible)
- FindItem not possible

Everything else is redirected to/from the custom data source. (GetData/SetData)
Even changing the Rows/Cols is possible. Also to call AddItem/RemoveItem.
It is up to the application to sync that change to the custom data source. If that's not done an out of bounds error can happen or the change will be reversed after a .DataRefresh.

Included optional argument Direction in the FindItem function. (Down or Up)
Now it's very easy to use and apply the "Find and replace" Common Dialog with the .FindItem function.
Attachment 161749

Also the FindItem cannot be used anymore now on a fixed row. This was not a problem at all without the Wrap or DirectionUp search.
But now you wouldn't want to search from bottom to up and get a hit by the column name by coincidence..
So that limitation is cosmetic to avoid this issue right away.
VBFLXGRD11.OCX will not be commited with that cosmetic limitation since it does not have Wrap or DirectionUp anyway.

In FarpointSpread and my own Spread, ColHeaderRows and RowHeaderCols are separate from normal grid cols and rows, that is, changing ColHeaderRows and RowHeaderCols does not affect normal grid cols/rows. This design makes the source code and data storage structure more complicated, but it's also more user-friendly and more flexible.

VBFLXGRD12.OCX is now released.

Hi Krool, if I want to use another free registration OCX, how do I generate tblid in RES? Thank you!

Quote:

---

Originally Posted by ChenLin

Hi Krool, if I want to use another free registration OCX, how do I generate tblid in RES? Thank you!

---

You can use ResourceHacker to edit the .res file.

I) Hello Krool, I want to report two differences that I found between VBFlexGrid and MS ones:
The first is how it draws the vertically centered texts when they don't fit in the row:

Attachment 162017

II) And the second is that in MS FlexGrids the CellFontSize value take some "stepped" values, but in the VBFlexGrid it doesn't.

For example, I select a cell, then set the size FlexGrid1.CellFontSize = 22
When I select the cell again, in the MS ones when I get back that value I get 22.2, but with the VBFlexGrid I get 22.
I could say that the VBFlexGrid is more "exact", but still that makes a difference that in some cases cause visible differences (that it would be long to explain now).

III) I have another question: is there any way to know what cells have particular formatting without having to navigate each one? I mean something like a property Get FormattedCellsMatrix(Row, Col) As Boolean

TIA

Quote:

---

Originally Posted by Eduardo-

I) Hello Krool, I want to report two differences that I found between VBFlexGrid and MS ones:
The first is how it draws the vertically centered texts when they don't fit in the row:

Attachment 162017

---

Hello Eduardo,
thanks for your report. I will process issue 1 first. (step by step)

Yes. I was certainly aware and could reproduce the behavior now again. Let's explain little bit:

If you set on the MS control the WordWrap property to True it will behave exactly like VBFlexGrid. Only if WordWrap is False the behavior is "little bit" different.
That's because the MS control will use DT_SINGLELINE for DrawText when WordWrap is False.
I explicity avoided that because else having WordWrap or multiline text are two things and should not be dependent on. I wanted to allow multiline text even if WordWrap is False.

Below would be the code modification marked as red in internal sub 'DrawCell' (not yet implemented; to be discussed) to replicate exact behavior for both WordWrap False/True:

Code:

---

If PropWordWrap = True Then Format = Format Or DT_WORDBREAK Else Format = Format Or DT_SINGLELINE
[...skipped part for here...]
Dim CalcRect As RECT, Height As Long, Result As Long
Select Case Alignment
    Case FlexAlignmentLeftCenter, FlexAlignmentCenterCenter, FlexAlignmentRightCenter, FlexAlignmentGeneral
        LSet CalcRect = TextRect
        Height = DrawText(hDC, StrPtr(Text), -1, CalcRect, Format Or DT_CALCRECT)
        If PropWordWrap = True Then
            Result = (((TextRect.Bottom - TextRect.Top) - Height) / 2)
        Else
            Format = Format Or DT_VCENTER
        End If
    Case FlexAlignmentLeftBottom, FlexAlignmentCenterBottom, FlexAlignmentRightBottom
        LSet CalcRect = TextRect
        Height = DrawText(hDC, StrPtr(Text), -1, CalcRect, Format Or DT_CALCRECT)
        If PropWordWrap = True Then
            Result = ((TextRect.Bottom - TextRect.Top) - Height)
        Else
            Format = Format Or DT_BOTTOM
        End If
End Select
If Result > 0 Then TextRect.Top = TextRect.Top + Result

---

As you see here comes DT_SINGLELINE in place which I want to avoid. DT_BOTTOM and DT_VCENTER are only supported when DT_SINGLELINE is set.

Currently always DT_TOP is applied in both (no DT_SINGLELINE at all) and the vertical adjustment is done manually. That's no issue as DrawText will be clipped to not go beyond the cell rectangle. However, in order to have the manual vertical adjustment to work with DT_TOP I would need to have the text rectangle less beyond the cell rectangle, which would look like this:
Attachment 162035
Possible solution (fix) would be to create a region and clip the DC accordingly while doing that.
That would solve the issue?
Or going the exact replicate behavior and use DT_SINGLELINE ? I want to discuss this first before implementing.

Thanks

OK, Krool. It is not an "issue", at least not now.
Showing texts in the cells exceeding the height of the cells as I did is not a normal thing to do.
I found this difference only by chance while testing other things, but this code is not in an actual real life program.
Now thinking in your explanation of wordbreak <> multiline it makes sense to perhaps leave it as it is now.
Or wait to see if it is an issue for someone else. Now I can't think of a situation where it could be actually a problem.

Or perhaps (I'm not saying you to do it, but just something to think about whether it is a good idea or not) you could have a property where can be set compatibility flags, and where such differences could be avoided.
Let's suppose there are a couple more of this improvements that change the old behavior.

It could be a property named for example OldFlexBehavior.
It would have a Long type value. The default value being 0.
Let's suppose there are three flags: 1, 2 and 4.
7 means full MS emulation.

Then if (mOldFlexBehavior and 1) = 1 it means when WordWrap is False to write in single lines as MS does.

But the question is: does it worth the effort? Will someone ever benefit from that?
If it were me, perhaps I would wait until someone actually needs it.

Quote:

---

Originally Posted by Krool

However, in order to have the manual vertical adjustment to work with DT_TOP I would need to have the text rectangle less beyond the cell rectangle, which would look like this:
Attachment 162035
Possible solution (fix) would be to create a region and clip the DC accordingly while doing that.

---

I think that way would be best to have same behavior when WordWrap is True or False. But allowing multiline always (no DT_SINGLELINE when WordWrap is False)
My last concern is that this clipping region for every cell would slow down the drawing..

EDIT:
Or keep as is.. and just include a new MultiLine property which controls DT_SINGLELINE to use or not.
Then if WordBreak is False and MultiLine is False also DT_VCENTER and DT_BOTTOM come into play to have same behavior as MS. Else have "manual" vertical offset adjustment with DT_TOP. (Like now as is, support multiline text)
This way it's separated and more specific under control.

Quote:

---

Originally Posted by Krool

My last concern is that this clipping region for every cell would slow down the drawing..

---

Yes, I don't think that would be a good idea.

Quote:

---

Originally Posted by Krool

EDIT:
Or keep as is.. and just include a new MultiLine property which controls DT_SINGLELINE to use or not.
Then if WordBreak is False and MultiLine is False also DT_VCENTER and DT_BOTTOM come into play to have same behavior as MS. Else have "manual" vertical offset adjustment with DT_TOP. (Like now as is, support multiline text)
This way it's separated and more specific under control.

---

I vote for that.

Quote:

---

Originally Posted by Eduardo-

I vote for that.

---

Great. I will call the property 'SingleLine'. So False being the default.
I just need to ensure to make a restriction that WordWrap and SingleLine cannot be both set to True.
That's it. Update will follow accordingly soon after careful testing. (Also that LabelTip will be in sync etc.)

Quote:

---

Originally Posted by Eduardo-

You can use ResourceHacker to edit the .res file.

---

Thank you. I want to know how to get tblid.

Quote:

---

Originally Posted by ChenLin

Thank you. I want to know how to get tblid.

---

What is tblid?

The XML information needed in the manifest for SxS installations?

Yes, should this information be exempt from registration? And CLSID。

Please see the picture, which is the red line information.

Attachment 162071

There are several programs that people use for getting that information.
I use one that was made by dilettante (a forum member) but it is not available any more in the web site it used to be because it is not currently developed and not published any more from the original author (it was available with source code).
It is called MMM or "Make My Manifest". I found a version here in GitHub.
There is also another one called UMMM. It is from wqweto, another forum member.

There are also others that are commercial. So far I only used MMM. It is not perfect. I have a couple of versions and both produce (different) errors, mainly because of Service Packs that are installed. But I manage to make them work by editing the XML text by hand.
Perhaps UMMM is better.

Or perhaps someone else has another one to recomend.

Neither of them tested successfully, gave up testing, and now uses the shell "regsvr32 /s " & App.Path & "\MSHFLXGD.OCX", vbHide method in the program startup.

Still thank you for your reply.

Quote:

---

Originally Posted by ChenLin

Neither of them tested successfully, gave up testing, and now uses the shell "regsvr32 /s " & App.Path & "\MSHFLXGD.OCX", vbHide method in the program startup.

Still thank you for your reply.

---

But that does a very different thing. That registers the ocx in Windows. It is the same that an installer would do.
And I don't know if that would work in 64 bits Windows.

The manifest thing is somethign else. It is not registering the ocx in Windows, but making it work without registering it (and just with that program).

Maybe I didn't use it well, it just generated a file like this:

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <assemblyIdentity name="BVO Computing Services.MMM" processorArchitecture="X86" type="win32" version="0.12.0.311" />
    <description>XCopy Packager for VB 6.0</description>
    <file name="MMM.exe">
    </file>
</assembly>

---

it doesn't include files like TYPEID or clsid.

Quote:

---

Originally Posted by ChenLin

Maybe I didn't use it well, it just generated a file like this:

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <assemblyIdentity name="BVO Computing Services.MMM" processorArchitecture="X86" type="win32" version="0.12.0.311" />
    <description>XCopy Packager for VB 6.0</description>
    <file name="MMM.exe">
    </file>
</assembly>

---

it doesn't include files like TYPEID or clsid.

---

That's not right (what you did), but I think you should open a new thread in the Visual Basic 6 and Earlier because it is not really a question of VBFlexGrid.

Minor update.

RowID/RowIndex property included. The usage is similar to the ColKey/ColIndex property.
RowIndex returns a row given its ID, whereas RowID returns/sets the ID given its row.

In fact RowID can be abused to be as a "second RowData" property or as a helper for identification.
Normally RowData could be used to identify rows but maybe this property is already used by something other, that's the reason for this feature.

Example for a helper of identification could be on sorting rows:

Code:

---

Dim Row1 As Long, Row2 As Long
Dim Col1 As Long, Col2 As Long
With VBFlexGrid1
.GetSelRange Row1, Col1, Row2, Col2
.RowID(.Row) = 1 ' Temporary identification
.Sort = [whatever]
.Row = .RowIndex(1)
.RowID(.RowIndex(1)) = 0 ' Remove temporary identification
.CellEnsureVisible
If Row1 <> Row2 Then .RowSel = IIf(Row1 < .Row, Row1, Row2)
If Col1 <> Col2 Then .ColSel = IIf(Col1 < .Col, Col1, Col2)
End With

---

Because the row number will be the same before and after sorting. But the actual row information is moved.
This helps you to identify the old "new" row number.

Quote:

---

Originally Posted by Krool

Minor update.

RowID/RowIndex property included. The usage is similar to the ColKey/ColIndex property.
RowIndex returns a row given its ID, whereas RowID returns/sets the ID given its row.

In fact RowID can be abused to be as a "second RowData" property or as a helper for identification.
Normally RowData could be used to identify rows but maybe this property is already used by something other, that's the reason for this feature.

Example for a helper of identification could be on sorting rows:

Code:

---

Dim Row1 As Long, Row2 As Long
Dim Col1 As Long, Col2 As Long
With VBFlexGrid1
.GetSelRange Row1, Col1, Row2, Col2
.RowID(.Row) = 1 ' Temporary identification
.Sort = [whatever]
.Row = .RowIndex(1)
.RowID(.RowIndex(1)) = 0 ' Remove temporary identification
.CellEnsureVisible
If Row1 <> Row2 Then .RowSel = IIf(Row1 < .Row, Row1, Row2)
If Col1 <> Col2 Then .ColSel = IIf(Col1 < .Col, Col1, Col2)
End With

---

Because the row number will be the same before and after sorting. But the actual row information is moved.
This helps you to identify the old "new" row number.

---

why not RowKey for uniform with ColKey? Normally, Grid provides RowKey and RowTag, not RowID.

Quote:

---

Originally Posted by DaveDavis

why not RowKey for uniform with ColKey? Normally, Grid provides RowKey and RowTag, not RowID.

---

Because for columns a string representation is better (e.g. field name) whereas by rows a number representing fits better (e.g. primary key)
Also Long (4 bytes) * rows is smaller than String (4 bytes + lenb()) * rows.
Having RowTag as Variant (16 bytes) * rows would be huge memory consumption.

Update released.

Internal improvement concerning divider drag of the last row or col. (or can be said bugfix also)

The last col (or last row) could only be dragged from within the grid (green area) and not from outside of the grid. (red area)
Attachment 162675

Bugfix released to yesterday update. Sorry for that. :sick:

The other minor internal improvement is also related to divider drag:
If a cell is not wide enough to consider the full divider spacings then it is now more fine-graned allocated.
Example:
the fixed cell in the middle is 2px. Previously the divider spacing (DIVIDER_SPACING_DIP = 2px) was allocated full for left and right (or top and bottom) side, thus overriding one side. Resulting that when clicking on 1st px is same as 2nd px, left col (or top row) was dragged.
The improvement now checks if the cell is capable to consider full spacing. If not then just divide the area into two.
If the fixed cell in the middle would be 3px (not even) then a remainder would exist and this will be just put to right (or bottom) side. (equal to MSFlexGrid control behavior)
Attachment 162723
I think that's it and no more issues should arise concerning divider drag..

Hi, my first post here, so excuse the silly questions :p, but I have a (old) application which is Visual C++ / MFC and uses the MSflexgrid active X control that I've migrated to VS2017. I was not sure if the Exe ver or ActiveX Control would work in this environment? So I tried to install the active X object and can put into the toolbox in VS2017, but when trying to add to my form I get an error (cannot instantiate or similar)... So my questions: Is it currently only possible to use this object in VB6 (i tested there and it works). Or will it work in other environments (VS 2017 - currently not working or I do something incorrectly?). If only VB6 what is the difficulty to make this usable in VS2017 or is it even possible? The main reason I was looking for an update is the MSflexgrid causes much flicker in my application which runs off a fast timer (< 100ms). I can't find a way to get rid of this flicker easily and hoped your control would be better for this since it has been updated and give the programmer more control over what is happening....
Thanks for any help you can provide, have a nice day. :)

PS - i attached the msflexgrid.h and .cpp if that would be interesting for anyone to view

Hi Krool,

Excellent work as usual, so thanks for this gift to the community.

I've been working with your control for a project published here, and I had a question that I hope you might take a look at (no rush of course):

Is there any way to ensure the last column always takes up the available width of the control after taking into account the width of the previous columns? If not, is this a feature you might consider? The VSFlexGrid control has an ExtendLastCol property for this, and I use it frequently.

Thanks a lot, and Happy New Year!

Quote:

---

Originally Posted by jpbro

Is there any way to ensure the last column always takes up the available width of the control after taking into account the width of the previous columns? If not, is this a feature you might consider? The VSFlexGrid control has an ExtendLastCol property for this, and I use it frequently

---

Yes, ok. It says:
Returns or sets whether the last column should be adjusted to fit the control's width.
This property only affects painting. It does not modify the ColWidth property of the last column.

What does that mean? If the ColWidth is not modified (only painting) what will hit-testing report? Please try to report all details as I have no vsFlexGrid at hand.
Thanks

Thanks for considering the ExtendLastCol feature request, and Happy New Year! Sorry I took so long to reply, I've been quite sick with the flu for a few days (feeling much better today, thankfully).

I do find the VSFlexGrid decision re: column width to be a bit strange, but maybe others will have a good explanation. Personally I think it would make more sense to return the actual column width after extending it.

That said, I did run a little test and here are the results:

Attachment 164397

The main takeaway is that even though the ColWidth property returns the originally set value of 920 twips, the control seems to use the full column width in every other way (mouse over, drawing text, etc...)

Hope that helps, but please let me know if you need me to run any other tests.

Thanks!

Can this be used in Excel/VBA? Are there step by step instructions? Apologies if I'm missing something. Thank you!

Quote:

---

Originally Posted by southmark

Can this be used in Excel/VBA? Are there step by step instructions? Apologies if I'm missing something. Thank you!

---

Yes, you can. But only the OCX version and office 32-bit.

Quote:

---

Originally Posted by Krool

Yes, you can. But only the OCX version and office 32-bit.

---

Thanks for the reply.

Office 32 bit (under Program Files x86)
Copied OLEGuid.tlb into the windows system directory.
Ran regsvr32 on the ocx (but it failed).
Tried to download the VB6 Register TypeLib Utility.zip file but the zip appears corrupted (from http://www.vbaccelerator.com/home/VB...b_Utility.html)
Added references to the tlb and ocx in the vba editor but did not see the control in the toolbox (additional controls)

Where am I going wrong please?

AFAIK you don't need the TLB when using the OCX.

What error code did you get when you tried to register the OCX? Did you attempt to register it in an elevated command prompt?

Right. You don't need the tlb.
Copy the OCX to SysWow64 folder and run cmd as administrator and cd to SysWow64 and regsvr32 it.

Quote:

---

Originally Posted by Krool

Right. You don't need the tlb.
Copy the OCX to SysWow64 folder and run cmd as administrator and cd to SysWow64 and regsvr32 it.

---

'The module "VBFLXGRD12.OCX": was loaded but the call to DllRegisterServer failed with error code 0x80004005.'

I did right-click the command prompt and run as administrator.
Thank you.

I was able to register the ocx control successfully.
I can add it to the pallete and to a form in Excel.
However, when I try to run that form I am now seeing:

Run-time error '50003'.
Unexpected error.

When I clear that dialog I get another one:

License information for this component was not found. You do not have an appropriate license to use this functionality in the design environment.

Help appreciated :-)

Quote:

---

Originally Posted by southmark

I was able to register the ocx control successfully.
I can add it to the pallete and to a form in Excel.
However, when I try to run that form I am now seeing:

Run-time error '50003'.
Unexpected error.

When I clear that dialog I get another one:

License information for this component was not found. You do not have an appropriate license to use this functionality in the design environment.

Help appreciated :-)

---

I could replicate the issue and update released. Please re-download the OCX.

Also please ensure to delete the VBFLXGRD12.exd file in:

Code:

---

C:\Documents and Settings\[YOUR USERNAME]\Application Data\Microsoft\Forms
C:\Users\[YOUR USERNAME]\AppData\Local\Temp\VBE

---

Quote:

---

Originally Posted by Krool

I could replicate the issue and update released. Please re-download the OCX.

Also please ensure to delete the VBFLXGRD12.exd file in:

Code:

---

C:\Documents and Settings\[YOUR USERNAME]\Application Data\Microsoft\Forms
C:\Users\[YOUR USERNAME]\AppData\Local\Temp\VBE

---

---

Working in Windows 10, thank you! I look forward to trying it out.

More a FYI, in Windows XP regsvr32 returns "VBFLXGRD12.OCX is not an executable file and no registration helper is registered for this filetype"

Quote:

---

Originally Posted by southmark

Working in Windows 10, thank you! I look forward to trying it out.

More a FYI, in Windows XP regsvr32 returns "VBFLXGRD12.OCX is not an executable file and no registration helper is registered for this filetype"

---

Do you use the 32-bit regsvr32 in SysWow64 folder?
That solution is coming when I put your message to google..
On the other side this means you have windows xp x64?

Quote:

---

Originally Posted by Krool

Do you use the 32-bit regsvr32 in SysWow64 folder?
That solution is coming when I put your message to google..
On the other side this means you have windows xp x64?

---

Windows 10, syswow64, works. My Windows XP is a 32-bit VirtualBox VM. I've also tried a couple of (physical) 64-bit Windows 7 machines, where I'm getting the 'The module "VBFLXGRD12.OCX": was loaded but the call to DllRegisterServer failed with error code 0x80004005.' message.

Quote:

---

Originally Posted by southmark

Windows 10, syswow64, works. My Windows XP is a 32-bit VirtualBox VM. I've also tried a couple of (physical) 64-bit Windows 7 machines, where I'm getting the 'The module "VBFLXGRD12.OCX": was loaded but the call to DllRegisterServer failed with error code 0x80004005.' message.

---

Did you start cmd as admin ? (Run as administrator)

PERFORMANCE QUESTION

I have a problem that I can't really describe very well, but I'll try:

Let's say I have 10.000 rows in a grid, 4 cols.
It is super fast to fill.
Then I fill the same grid with 100 rows only.
This takes quite long.
I already inspected my code to see what the bottleneck could be, nothing special found so far.

I have the _feeling_ that the effect is related to the 'destroy a lot of classes is slow' problem in VB6.
Can that be?
And if so, is there a way around it?

Quote:

---

Originally Posted by Karl77

PERFORMANCE QUESTION

I have a problem that I can't really describe very well, but I'll try:

Let's say I have 10.000 rows in a grid, 4 cols.
It is super fast to fill.
Then I fill the same grid with 100 rows only.
This takes quite long.
I already inspected my code to see what the bottleneck could be, nothing special found so far.

I have the _feeling_ that the effect is related to the 'destroy a lot of classes is slow' problem in VB6.
Can that be?
And if so, is there a way around it?

---

There are no classes, so no problem for that like in ListView (without VirtualMode).

Though it would make a difference between 1x = .Rows set 100 vs. 100x .AddItem.
Also it makes a slight difference when first setting rows and then cols.
The row increase is more performant than increase cols. That's due to the fact that the 2d struct internally is done with two arrays in combination instead of one array. But that's sbsolutely necessary.
So better first set the cols and then mess around with rows.

(PERFORMANCE QUESTION)

Quote:

---

There are no classes, so no problem for that like in ListView (without VirtualMode).

---

You are completely right with all you said.
There is no performance issue with the VBFlexGrid.

I have found the bottleneck in my code now.
Sorry for asking too early.

Again, VBFlexGrid is super fast!

Quote:

---

Originally Posted by Krool

Did you start cmd as admin ? (Run as administrator)

---

Hi Krool, sorry for the late reply - I went on holiday. I do appreciate your feedback.

Yes - as admin. There seems to be a group policy on the Windows 7 machines that prevents the installation but I don't have permissions to view it.

1.
Update, convenient CellClick and CellDblClick event included.

2.
Open question relating to an behavior change in the user interaction:

Currently the behavior and user interaction is equal to the MS(H)FlexGrid.
However, I do find the keyboard user interaction very cumbersome in SelectionMode ByRow or ByCol.

Example:
You have SelectionMode ByRow and more columns than the screen allows to display at once.
So a horizontal scrollbar is displayed. Fine, the only way to scroll horizontal is by mouse.
Wouldn't it be better to allow the left and right keys to scroll horizontal ? (like in the ListView control)

Of course it would be better. (also "analog" when ByCol)
But there are two optinos of how I could implement it:
A: Just implement the new behavior
B: Provide a new "ExtendedUI" or "CompatibilityMode" property (other naming ideas?) to determine if the control should be forced to match MSFlexGrid or to allow user interaction enhancements. (maybe possible other behavior changes in future)

The problem I do see with option A is that maybe somebody in their app already noticed this lack and filled this with own code in the key events to allow scrolling horizontal by key inputs.
Then with a next update of option A (in case an app fills the lack) is that suddenly with left and right keys the control would scroll twice in SelectionMode ByRow or ByCol.

That's why I would personally prefer option B.
But I want to be sure and await possible feedbacks about this approach.

convenient CellClick and CellDblClick event included.

This is a very convenient function! In the past, you had to write a function to get cell events, but now you don't need it.

Thank you!

Quote:

---

Originally Posted by Krool

1.
Update, convenient CellClick and CellDblClick event included.

2.
Open question relating to an behavior change in the user interaction:

Currently the behavior and user interaction is equal to the MS(H)FlexGrid.
However, I do find the keyboard user interaction very cumbersome in SelectionMode ByRow or ByCol.

Example:
You have SelectionMode ByRow and more columns than the screen allows to display at once.
So a horizontal scrollbar is displayed. Fine, the only way to scroll horizontal is by mouse.
Wouldn't it be better to allow the left and right keys to scroll horizontal ? (like in the ListView control)

---

Move focus (focused cell) in selected row to Left or Right in result of horizontal scrolling when selection mode is ByRow.

Quote:

---

Originally Posted by Krool

1.
Update, convenient CellClick and CellDblClick event included.

---

The Click event of Farpoint Spread and my Spread is like this:

Code:

---

Private Sub fpSpread1_Click(ByVal Col As Long, ByVal Row As Long)

End Sub

---

Quote:

---

Originally Posted by Krool

2.
Open question relating to an behavior change in the user interaction:

Currently the behavior and user interaction is equal to the MS(H)FlexGrid.
However, I do find the keyboard user interaction very cumbersome in SelectionMode ByRow or ByCol.

Example:
You have SelectionMode ByRow and more columns than the screen allows to display at once.
So a horizontal scrollbar is displayed. Fine, the only way to scroll horizontal is by mouse.
Wouldn't it be better to allow the left and right keys to scroll horizontal ? (like in the ListView control)

Of course it would be better. (also "analog" when ByCol)
But there are two optinos of how I could implement it:
A: Just implement the new behavior
B: Provide a new "ExtendedUI" or "CompatibilityMode" property (other naming ideas?) to determine if the control should be forced to match MSFlexGrid or to allow user interaction enhancements. (maybe possible other behavior changes in future)

The problem I do see with option A is that maybe somebody in their app already noticed this lack and filled this with own code in the key events to allow scrolling horizontal by key inputs.
Then with a next update of option A (in case an app fills the lack) is that suddenly with left and right keys the control would scroll twice in SelectionMode ByRow or ByCol.

That's why I would personally prefer option B.
But I want to be sure and await possible feedbacks about this approach.

---

I just tested your VBFlexGrid. When "SelectionMode = FlexSelectionModeByRow", the Focused Cell is always in the first column (column A). IMO, this is unreasonable and should allow the user to select different active cell in the current row.

If the above problem is solved, then moving the active cell with the key left-arrow or right-arrow and causing horizontal scrolling is the best solution.

(The RowMode of Farpoint Spread is also not convenient, I improved it.)

I assume the vbFlexGrid also has the MouseRow and MouseCol properties.
These contain the current Row/Col position for the mouse pointer location.

Quote:

---

Originally Posted by dreammanor

The Click event of Farpoint Spread and my Spread is like this:

Code:

---

Private Sub fpSpread1_Click(ByVal Col As Long, ByVal Row As Long)

End Sub

---

I just tested your VBFlexGrid. When "SelectionMode = FlexSelectionModeByRow", the Focused Cell is always in the first column (column A). IMO, this is unreasonable and should allow the user to select different active cell in the current row.

If the above problem is solved, then moving the active cell with the key left-arrow or right-arrow and causing horizontal scrolling is the best solution.

(The RowMode of Farpoint Spread is also not convenient, I improved it.)

---

You suggest even changing the col when ByRow selection mode?
But then the whole row does not look like full selected. Or the drawing routine needs to be adjusted so that the full row looks selected. You basically mean a mix of Free and ByRow, right?
However, option A or B?
I think for such a big behavior change a new ExtendedUI property would be needed?

Quote:

---

Originally Posted by Krool

You suggest even changing the col when ByRow selection mode?
But then the whole row does not look like full selected. Or the drawing routine needs to be adjusted so that the full row looks selected. You basically mean a mix of Free and ByRow, right?
However, option A or B?
I think for such a big behavior change a new ExtendedUI property would be needed?

---

I mean, when a single row is full selected (in Row-Mode), the Focused Cell (Active Cell) is allowed to move left and right in this row, but the row is still selected (except for the Focused Cell, other cells are still blue backcolor and white forecolor).

Quote:

---

Originally Posted by dreammanor

I mean, when a single row is full selected (in Row-Mode), the Focused Cell (Active Cell) is allowed to move left and right in this row, but the row is still selected (except for the Focused Cell, other cells are still blue backcolor and white forecolor).

---

I understood it this way. However you agree another property is needed to control this behavior?

Quote:

---

Originally Posted by Krool

I understood it this way. However you agree another property is needed to control this behavior?

---

There is no need to add a property for a small behavior change. My suggestion is to add an enum value to SelectionMode, such as: FlexSelectionModeBySingleRow or FlexSelectionModeByRowEx or FlexSelectionModeByRowEnhanced, among which FlexSelectionModeBySingleRow makes more sense and more valuable.

Quote:

---

Originally Posted by dreammanor

There is no need to add a property for a small behavior change. My suggestion is to add an enum value to SelectionMode, such as: FlexSelectionModeBySingleRow or FlexSelectionModeByRowEx or FlexSelectionModeByRowEnhanced, among which FlexSelectionModeBySingleRow makes more sense and more valuable.

---

Maybe "FlexSelectionModeByRowFree"
Beside that I would also like to improve behavior for the "old" selection modes.
It cannot be that horizontal scrolling is not possible by cursor keys in SelectionByRow.
Therefore I may add a "CompatibilityMode" property to allow certain behavior improvements or to enforce full behavior synchronicity to not break old code base. (As such default value will be True)
In future other behavior change might be covered as well by that property.
What you mean?

Quote:

---

Originally Posted by Krool

Maybe "FlexSelectionModeByRowFree"
Beside that I would also like to improve behavior for the "old" selection modes.
It cannot be that horizontal scrolling is not possible by cursor keys in SelectionByRow.
Therefore I may add a "CompatibilityMode" property to allow certain behavior improvements or to enforce full behavior synchronicity to not break old code base. (As such default value will be True)
In future other behavior change might be covered as well by that property.
What you mean?

---

Most of Grid doesn't have such "FlexSelectionModeByRow". As we suggested, A focused Cell (ActiveCell) can be changed by arrows is the common behaviour.

removed

Quote:

---

Originally Posted by Krool

Maybe "FlexSelectionModeByRowFree"
Beside that I would also like to improve behavior for the "old" selection modes.
It cannot be that horizontal scrolling is not possible by cursor keys in SelectionByRow.
Therefore I may add a "CompatibilityMode" property to allow certain behavior improvements or to enforce full behavior synchronicity to not break old code base. (As such default value will be True)
In future other behavior change might be covered as well by that property.
What you mean?

---

In Farpoint Spread and my Spread, there are not only the SelectionMode (SelectBlockOptions, which is more powerful than the SelectionMode of VBFlexGrid) property, but also the OperationMode property, whose values are: OperationModeNormal, OperationModeRead, OperationModeRow, OperationModeSingle, OperationModeMulti, OperationModeExtended.

When OperationMode=OperationModeRow, the spread is in single-row selection mode, which is a very useful mode. That's why I recommend adding an enum value FlexSelectionModeBySingleRow to your VBFlexGrid.

If you want to add a property, I suggest you add the OperationMode property instead of CompatibilityMode. The name CompatibilityMode is too abstract and can be confusing to the users.

Quote:

---

Originally Posted by Krool

A: Just implement the new behavior
B: Provide a new "ExtendedUI" or "CompatibilityMode" property (other naming ideas?) to determine if the control should be forced to match MSFlexGrid or to allow user interaction enhancements. (maybe possible other behavior changes in future)

The problem I do see with option A is that maybe somebody in their app already noticed this lack and filled this with own code in the key events to allow scrolling horizontal by key inputs.
Then with a next update of option A (in case an app fills the lack) is that suddenly with left and right keys the control would scroll twice in SelectionMode ByRow or ByCol.

That's why I would personally prefer option B.
But I want to be sure and await possible feedbacks about this approach.

---

My vote is for Option A. Implement the new behavior and do not add any new property.
If there are two or three VB6 programmers in the world that added code to fix that bug of the origonal FlexGrids and they decide to replace the controls with your Flex version, if they are lucky they'll read somewhere about the new behaviour and remove their fixing code (unlikely to happen) and if not, they at some point will notice the strange behavior and will realize that they must remove their fixing code because your control doesn't have the bug.

Adding new properties for things like this is confusing for the majority of people that never knew about the bug.
For example I use FlexGrids since many years ago but I never realized about this bug.

Because, let's see:
Lets suppose that the CompatibilyMode is False by default.
All the people that will use your Flex version will have the bug, unless they read somewhere that they must switch that property to True. Then 99.9% of the people will have the bug as the original had because almost nobody reads such things.
On the other hand, if the CompatibilityMode is True by default, the problem will be for the two or three in the whole world that wrote code to fix that bug (but just in the case that these 2 or 3 find your control and decide to replace the old ones with yours). Because the same thing: nobody reads about such things.
And in the case that it happens to some final users, what would be the "big problem"? It is only that with the keyboard the user will scroll two rows instead of one.
If it happens that might be one program goes out with that "problem", perhaps three or four final users will notice the weirdness of the scroll with the keyboard and decide to use the mouse instead.