VBFlexGrid Control (Replacement of the MSFlexGrid control)

Quote:

---

Originally Posted by Eduardo-

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.

---

Good arguments of how it works in the pactice.. Only in a perfect world it would work. :D

So, I improved then with today's update (when SelectionMode is ByRow/ByCol) the cursor key navigating. (also when shift or ctrl key is concerned)
No new property is included. It's just as is.

This update is not a real bugfix, but rather a compatibility fix in regard to MSFlexGrid.

In VBFlexGrid and MSFlexGrid the CellLeft/CellTop property returns the real X/Y coord of an cell.
However, for CellWidth/CellHeight the behavior was different.
The VBFlexGrid returned the real CX/CY values whereas the MSFlexGrid has an offset of -1 for each.

Reason is that the CellWidth/CellHeight are designed to be used in combination with placing a TextBox on a cell. With that -1 offset it looks better.
So in order to be compatible I also made now the -1 offset.
Of course there is then the fact that a row or col with an real height/width of 0 (not visible) will return a negative width. (-1)
But MSFlexGrid is doing the same so..

Bugfix in FormatString property.

When no alignment prefix for a column was specified (no '<', '^' or '>') then FlexAlignmentGeneral should have been used instead FlexAlignmentLeftCenter.

Now with FlexAlignmentGeneral it equals MSFlexGrid behavior.

Further bugfix. This time CellWrapBehavior property was affected.
The cursor keys move the focus accordingly in the grid and skips hidden or zero height/width rows/cols.
However, that "skip movement" did not work for CellWrapBehavior when the first or last scrollable (non-fixed) rows/cols were hidden or zero height/width.
That's now fixed.

undefined Code:

Dim k As Long
For k = 0 To Me.VBFlexGrid1.Cols - 1
Debug.Print "Debug.Print ColIndex= " & k & "   GetColKeyByIndex =  " & Me.VBFlexGrid1.ColKey(k)
Next  
'Debug.Print ColIndex= 0   GetColKeyByIndex =
'Debug.Print ColIndex= 1   GetColKeyByIndex =
'Debug.Print ColIndex= 2   GetColKeyByIndex =
'Debug.Print ColIndex= 3   GetColKeyByIndex =
'Debug.Print ColIndex= 4   GetColKeyByIndex =
'Debug.Print ColIndex= 5   GetColKeyByIndex =
'Debug.Print ColIndex= 6   GetColKeyByIndex =
'Debug.Print ColIndex= 7   GetColKeyByIndex =
'Debug.Print ColIndex= 8   GetColKeyByIndex =
'Debug.Print ColIndex= 9   GetColKeyByIndex =
'Debug.Print ColIndex= 10   GetColKeyByIndex =
'Debug.Print ColIndex= 11   GetColKeyByIndex =
'Debug.Print ColIndex= 12   GetColKeyByIndex =
'Debug.Print ColIndex= 13   GetColKeyByIndex =
'Debug.Print ColIndex= 14   GetColKeyByIndex =
'Debug.Print ColIndex= 15   GetColKeyByIndex =
'Debug.Print ColIndex= 16   GetColKeyByIndex =
'Debug.Print ColIndex= 17   GetColKeyByIndex =
'Debug.Print ColIndex= 18   GetColKeyByIndex =
'Debug.Print ColIndex= 19   GetColKeyByIndex =

Debug.Print "Debug.Print ColIndex= " & k & " GetColKeyByIndex = " & Me.VBFlexGrid1.ColKey(k)=Null ?

Quote:

---

Originally Posted by smileyoufucn

undefined Code:

Dim k As Long
For k = 0 To Me.VBFlexGrid1.Cols - 1
Debug.Print "Debug.Print ColIndex= " & k & "   GetColKeyByIndex =  " & Me.VBFlexGrid1.ColKey(k)
Next  
'Debug.Print ColIndex= 0   GetColKeyByIndex =
'Debug.Print ColIndex= 1   GetColKeyByIndex =
'Debug.Print ColIndex= 2   GetColKeyByIndex =
'Debug.Print ColIndex= 3   GetColKeyByIndex =
'Debug.Print ColIndex= 4   GetColKeyByIndex =
'Debug.Print ColIndex= 5   GetColKeyByIndex =
'Debug.Print ColIndex= 6   GetColKeyByIndex =
'Debug.Print ColIndex= 7   GetColKeyByIndex =
'Debug.Print ColIndex= 8   GetColKeyByIndex =
'Debug.Print ColIndex= 9   GetColKeyByIndex =
'Debug.Print ColIndex= 10   GetColKeyByIndex =
'Debug.Print ColIndex= 11   GetColKeyByIndex =
'Debug.Print ColIndex= 12   GetColKeyByIndex =
'Debug.Print ColIndex= 13   GetColKeyByIndex =
'Debug.Print ColIndex= 14   GetColKeyByIndex =
'Debug.Print ColIndex= 15   GetColKeyByIndex =
'Debug.Print ColIndex= 16   GetColKeyByIndex =
'Debug.Print ColIndex= 17   GetColKeyByIndex =
'Debug.Print ColIndex= 18   GetColKeyByIndex =
'Debug.Print ColIndex= 19   GetColKeyByIndex =

Debug.Print "Debug.Print ColIndex= " & k & " GetColKeyByIndex = " & Me.VBFlexGrid1.ColKey(k)=Null ?

---

And what?

Quote:

---

Originally Posted by dreammanor

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.

---

I want to come back to this topic.
On 02-Mar-2019 I fixed some cumbersome behavior already for ByRow/ByCol selection mode in regard to scrolling with the arrow keys.

I would like to add a selection mode where the active cell (focused cell) can be changed by the arrow keys within that "full row/col selection".
However, I want to keep that behavior for ByRow/ByCol that changing the focused cell is not possible. To maintain compatibility to MSFlexGrid. That's why I need new enum values for SelectionMode or another property controlling it.

So how to name it the best? You suggested to add something like "FlexSelectionModeBySingleRow". But SingleRow sounds for me like the current ByRow behavior (where focused cell cannot be moved both directions) and not the new behavior ?

Maybe "FlexSelectionModeFreeByRow" ? That would sound for me like the desired behavior, a mix of Free and ByRow combined into one.
It would work like FlexSelectionModeFree, but just drawing the full row (or full column) as selected.

Please forgive me for not speaking English. Content can only be sent using Google Translate.
Problem: The value cannot be obtained normally through the ColKey property
Is this my method problem or bug?

FlexSelectionModeByRowExtended Or FlexSelectionModeByRowEx

FlexSelectionModeByColumnExtended Or FlexSelectionModeByColumnEx

Quote:

---

Originally Posted by smileyoufucn

Problem: The value cannot be obtained normally through the ColKey property
Is this my method problem or bug?

---

Your usage is wrong. See below illustration how it can be used.

Code:

---

Private Sub CommandTest_Click()
Dim Col As Long
Col = 5
MsgBox VBFlexGrid1.ColKey(Col) ' will return blank
VBFlexGrid1.ColKey(Col) = "my key"
MsgBox VBFlexGrid1.ColIndex("my key") ' will return 5
MsgBox VBFlexGrid1.ColIndex("my key") ' will return again 5
MsgBox VBFlexGrid1.ColKey(Col) ' will return 'my key'
End Sub

---

Quote:

---

Originally Posted by dreammanor

FlexSelectionModeByRowExtended Or FlexSelectionModeByRowEx

FlexSelectionModeByColumnExtended Or FlexSelectionModeByColumnEx

---

Thanks. However, I think will gonna stick to wording 'FlexSelectionModeFreeByRow' and 'FlexSelectionModeFreeByColumn'.
I do find correct wordings quite important and feel that this would express the behavior more exactly instead of Extended.

Quote:

---

Originally Posted by Karl77

Is there an edit function in the works?

---

Update released. Now the in-cell editing functionality is finally implemented.

The new AllowUserEditing property determines if the start of the edit is handled automatically.
It will then be start automatically when:
- F2 key
- Space key
- Keystroke/typing
- Double click

It can also be started by code using the StartEdit method, even if AllowUserEditing is False.

The edit will end when:
- Losing focus
- Escape key
- Return key
- Tab/ShifTab key (meaningful only when TabBehavior <> Controls; otherwise it's just a LostFocus)
- Navigation key (four Arrow keys, PageUp, PageDown, Home and End keys)

The edit can also be ended by code using the CancelEdit or CommitEdit method.
CancelEdit discard the changes whereas CommitEdit saves the changes.

There are several read-only run-time properties:
- hWndEdit As Long
- EditRow As Long
- EditCol As Long
- EditReason As FlexEditReasonConstants
- EditCloseMode As FlexEditCloseModeConstants

And following run-time properties which are not read-only:
- EditText As String
- EditMaxLength As Long
- EditSelStart As Long
- EditSelLength As Long
- EditSelText As String

The chart below will illustrate the flow of the various events:

Attachment 167489

To note is that when invoking by code the CommitEdit event that the ValidateEdit event is still triggered.
Inside ValidateEdit you can force validation by again calling CommitEdit even when Cancel parameter should be True.
Or calling CancelEdit inside ValidateEdit when the Cancel parameter is True to just discard the changes and not to keep in edit mode.
Also to note is that EditQueryClose event will not be called in case of LostFocus.

Sample usage included in the demo project. (UserEditingForm.frm)

Are you sure that the keys Home and End should end the edit mode?
I don't know if it's the standard behavior but seems strange to me. Imo these keys should put the cursor in the start/end of the text.

Just my 0.02€

Quote:

---

Originally Posted by Carlos Rocha

Are you sure that the keys Home and End should end the edit mode?
I don't know if it's the standard behavior but seems strange to me. Imo these keys should put the cursor in the start/end of the text.

Just my 0.02€

---

That is the case. Only when the caret is on specific position it will end edit mode.
If needed it can be prohibited in EditQueryClose event.

Quote:

---

Originally Posted by Krool

That is the case. Only when the caret is on specific position it will end edit mode.
If needed it can be prohibited in EditQueryClose event.

---

Perfect, thank you :)

I suggest using pure Owner-Draw usercontrol instead of using CreateWindowEx from VBFlexGridWndClass. We know you have all technoques and skiils to do so.
IMO,I hate mouse moving scrollbar but not updating Grid.

Quote:

---

Originally Posted by DaveDavis

I suggest using pure Owner-Draw usercontrol instead of using CreateWindowEx from VBFlexGridWndClass. We know you have all technoques and skiils to do so.
IMO,I hate mouse moving scrollbar but not updating Grid.

---

The problem is that UserControl is an ANSI window so user input chars are not unicode.
For mouse moving scrollbar and not updating grid. What you mean? Doesn't ScrollTrack property set to True resolve this?

Quote:

---

Originally Posted by Krool

The problem is that UserControl is an ANSI window so user input chars are not unicode.

---

Input Chars is done by your TextBoxW which is unicode.

Quote:

---

Originally Posted by Krool

For mouse moving scrollbar and not updating grid. What you mean? Doesn't ScrollTrack property set to True resolve this?

---

oops, I ignored this property. But the scrollbar has strange behavior. I tested in UserEditingForm. It's very obvious, you can reproduce.

Quote:

---

Originally Posted by DaveDavis

Input Chars is done by your TextBoxW which is unicode.

---

The grid itself also receives input chars, even if there is no default processing. you could catch KeyPress with unicode chars to make your own incremental search or whatever. (As example)

Edit: or bigger example. The grid receives first input char to start editing and forwards the first char to the TextBox. If the grid window is not unicode this would be not possible to enter first char as unicode

Quote:

---

Originally Posted by Krool

Edit: or bigger example. The grid receives first input char to start editing and forwards the first char to the TextBox. If the grid window is not unicode this would be not possible to enter first char as unicode

---

We can subclass IME as olaf did.

Quote:

---

Originally Posted by Krool

Update released. Now the in-cell editing functionality is finally implemented.

The new AllowUserEditing property determines if the start of the edit is handled automatically.
It will then be start automatically when:
- F2 key
- Space key
- Keystroke/typing
- Double click

It can also be started by code using the StartEdit method, even if AllowUserEditing is False.

The edit will end when:
- Losing focus
- Escape key
- Return key
- Tab/ShifTab key (meaningful only when TabBehavior <> Controls; otherwise it's just a LostFocus)
- Navigation key (four Arrow keys, PageUp, PageDown, Home and End keys)

The edit can also be ended by code using the CancelEdit or CommitEdit method.
CancelEdit discard the changes whereas CommitEdit saves the changes.

There are several read-only run-time properties:
- hWndEdit As Long
- EditRow As Long
- EditCol As Long
- EditReason As FlexEditReasonConstants
- EditCloseMode As FlexEditCloseModeConstants

And following run-time properties which are not read-only:
- EditText As String
- EditMaxLength As Long
- EditSelStart As Long
- EditSelLength As Long
- EditSelText As String

The chart below will illustrate the flow of the various events:

Attachment 167489

To note is that when invoking by code the CommitEdit event that the ValidateEdit event is still triggered.
Inside ValidateEdit you can force validation by again calling CommitEdit even when Cancel parameter should be True.
Or calling CancelEdit inside ValidateEdit when the Cancel parameter is True to just discard the changes and not to keep in edit mode.
Also to note is that EditQueryClose event will not be called in case of LostFocus.

Sample usage included in the demo project. (UserEditingForm.frm)

---

I quickly tested the cell editing functionality, which is a good start.

(1) The characters position change (offset to the left) after entering the edit mode.
(2) Maybe you could add a property EditPermanent to make the grid always in the edit state.
(3) In addition, when the cell editing functionality is added, you should probably allow users to control the movement of the edit-box via vbKeyReturn and vbKeyTab or other keys.

Quote:

---

Originally Posted by DaveDavis

But the scrollbar has strange behavior. I tested in UserEditingForm. It's very obvious, you can reproduce.

---

I see. I didn't notice this on Windows 7 as there the scrolling is done on the focused window, whereas on Windows 10 the scrolling is done under the window from the mouse pointer.
I will fix this asap.

Regarding the grid window. I don't see the issue with VBFlexGridWndClass. At least then I have full control of everything. Just my opinion.

Update released.

Quote:

---

Originally Posted by DaveDavis

But the scrollbar has strange behavior. I tested in UserEditingForm. It's very obvious, you can reproduce.

---

That's now fixed. The edit window position/size is now updated when scrolling while in edit mode.

http://krool.mooo.com/Data/VBForums/...teEditRect.gif

Quote:

---

Originally Posted by dreammanor

(1) The characters position change (offset to the left) after entering the edit mode.

---

Should be doable to adjust this little offsets with EM_SETMARGINS. I will take a look soon.

Quote:

---

Originally Posted by dreammanor

(2) Maybe you could add a property EditPermanent to make the grid always in the edit state.

---

You could handle EnterCell or RowColChange event to manually call .StartEdit.

Quote:

---

Originally Posted by dreammanor

(3) In addition, when the cell editing functionality is added, you should probably allow users to control the movement of the edit-box via vbKeyReturn and vbKeyTab or other keys.

---

I didn't get it. Please explain again.
The enter key will end edit mode, except when using shift, ctrl or alt key while pressing enter key. Doing so will insert a line break. Do you mean that?

Quote:

---

Originally Posted by Krool

That's now fixed. The edit window position/size is now updated when scrolling while in edit mode.

---

Scrollbar still has problem which is hard to describe. In UserEditngForm, You can reproduce by clicking middle of VScrollbar (.ScrollTrack = True), thumb jumps to bottom. Look like Thumb size is too small as usual meanings the scrollbar algorithm is different with C# GridView control.

I tested and found that in windows server 2012 and windows 2017 system, mouse scrolling is invalid after entering edit mode.

Attachment 167581

Quote:

---

Originally Posted by Krool

I didn't get it. Please explain again.
The enter key will end edit mode, except when using shift, ctrl or alt key while pressing enter key. Doing so will insert a line break. Do you mean that?

---

When in the Editing-Permanent state, pressing the Return or Tab key will move the active editing cell to the next column of the current row, or the next row of the current column.

Quote:

---

Originally Posted by ChenLin

I tested and found that in windows server 2012 and windows 2017 system, mouse scrolling is invalid after entering edit mode.

Attachment 167581

---

What you mean with invalid? You can't scroll with left button clicks on scrollbar?
For mousewheel for example in some windows version it's scrolling focused window vs. on other the windows version it's scrolling the window under the pointer.(WindowFromPoint so to say)

Quote:

---

Originally Posted by dreammanor

When in the Editing-Permanent state, pressing the Return or Tab key will move the active editing cell to the next column of the current row, or the next row of the current column.

---

When the TabBehavior property is <> Controls you could replicate the editing permament manually.
However, there is no ReturnBehavior and WantReturn property yet. If that would be there you could build your own editing permanent style by code.

Quote:

---

Originally Posted by dreammanor

(1) The characters position change (offset to the left) after entering the edit mode.

---

That cosmetic issue is now resolved by internally using EM_SETMARGINS upon edit window creation. Thanks.

Quote:

---

Originally Posted by dreammanor

FlexSelectionModeByRowExtended Or FlexSelectionModeByRowEx

FlexSelectionModeByColumnExtended Or FlexSelectionModeByColumnEx

---

I'm still hesitating to just add enums for SelectionMode. Maybe I want to add other modes later on like in vsFlexGrid. (ListBox style selection etc.)

Therefore I suggest to add another property called 'SelectionUnit'.

Code:

---

Public Enum FlexSelectionUnitConstants
FlexSelectionUnitCell = 0
FlexSelectionUnitFullRow = 1
FlexSelectionUnitFullColumn = 2
End Enum

Returns/sets a value indicating which type of unit is used for selections in the flex grid.

---

So FlexSelectionUnitCell would mean that the selection is really based on the range of .Row/.Col and .RowSel/.ColSel

Whereas FlexSelectionUnitFullRow/FlexSelectionUnitFullColumn would mean to extend the selection to full rows/columns regardless of .RowSel/.ColSel.
Only .Row/.Col would be taken into account for "displaying" (drawing) full selection on row/column.
.RowSel/.ColSel can still be used; but are controlled then by SelectionMode.

What do you think?

Example:
- Having .SelectionMode set to 'Free' and .SelectionUnit to 'FullRow'
- .Rows is 100 and .Cols is 100
- .Row is 1 and .RowSel is 2
- .Col is 1 and .ColSel is 2
-> Two full row selection would be drawn even if Col and ColSel are not spanning the whole set of columns. (100)

If you add the OperationMode property, things are easily solved:

Code:

---

Enum SelectBlockOptionsConstants
    SelectBlockOptionsNone = 0
    SelectBlockOptionsColumns = 1
    SelectBlockOptionsRows = 2
    SelectBlockOptionsBlocks = 4
    SelectBlockOptionsSheet = 8
    SelectBlockOptionsAll = 15
End Enum

Enum OperationModeConstants
    OperationModeNormal = 0
    OperationModeRead = 1
    OperationModeRow = 2
    OperationModeSingle = 3
    OperationModeMulti = 4
    OperationModeExtended = 5
End Enum

---

The next OCX version is still not released..
So I took the chance to change the 'interface' of the BeforeEdit event. The Row/Col params are now ByRef instead of ByVal.
This gives an app more flexibility, if necessary. Or in other words, maybe an unecessary limitation was just removed.

I have found something.

In the Demo project set AllowBigSelection = False, and set AllowSelection = False in the IDE.
Start the project.
Scroll down the grid by mouse wheel.

Place the mouse on the fixed row.
Press and hold the left button.

The grid begins to scroll.
I can't imagine that is intended.
Or?

Quote:

---

Originally Posted by Karl77

I have found something.

In the Demo project set AllowBigSelection = False, and set AllowSelection = False in the IDE.
Start the project.
Scroll down the grid by mouse wheel.

Place the mouse on the fixed row.
Press and hold the left button.

The grid begins to scroll.
I can't imagine that is intended.
Or?

---

That's intended. :)
However, you can change with following code block the behavior which I think you want to have:

Code:

---

Private Sub VBFlexGrid1_BeforeMouseDown(ByVal Button As Integer, ByVal Shift As Integer, ByVal X As Single, ByVal Y As Single, Cancel As Boolean)
With VBFlexGrid1
.HitTest X, Y
If .HitResult = FlexHitResultCell Then
    If .HitCol > (.FixedCols - 1) And .HitRow < .FixedRows Then
        .Row = .TopRow
        .Col = .HitCol
        Cancel = True
    End If
End If
End With
End Sub

---

Update released.

Added enum FlexSelectionModeFreeByRow and FlexSelectionModeFreeByColumn in the SelectionMode property.
It's like a mix between FlexSelectionModeFree and FlexSelectionModeByRow or FlexSelectionModeByColumn.

How to easily achieve multiple choices? For example, drag the mouse to select the row, press CTRL to select the row that is not continuous, and press SHIFT to select the continuous row.
And can get which rows are selected.

Quote:

---

Originally Posted by ChenLin

How to easily achieve multiple choices? For example, drag the mouse to select the row, press CTRL to select the row that is not continuous, and press SHIFT to select the continuous row.
And can get which rows are selected.

---

The vsFlexGrid has a 'ListBox' style selection mode. Which is like 'ByRow' but supports multiselection. Selected rows can be retrieved via an .RowSelected property.
I might include something similar in future.

Update released.

Internal restructuring for drawing. The average performance boost in my tests were about 20%.

The 1.2 OCX will not be updated by this restructuring, because soon the new 1.3 version will be anyway released.

Hi Krool:

If you press the following settings after the update, it will not display properly:
VBFlexGrid1.FixedCols = 0
VBFlexGrid1.MergeCells = FlexMergeCellsFree
VBFlexGrid1.MergeCol(3) = True


This means that VBFlexGrid1.FixedCols = 0 and VBFlexGrid1.MergeCells cannot be set at the same time. This is the latest version, and the previous version is still normal.


Attachment 168285

Quote:

---

Originally Posted by ChenLin

Hi Krool:

If you press the following settings after the update, it will not display properly:
VBFlexGrid1.FixedCols = 0
VBFlexGrid1.MergeCells = FlexMergeCellsFree
VBFlexGrid1.MergeCol(3) = True


This means that VBFlexGrid1.FixedCols = 0 and VBFlexGrid1.MergeCells cannot be set at the same time. This is the latest version, and the previous version is still normal.


Attachment 168285

---

Thanks for reporting. It's kinda normal that after a restructuring new bugs appear. ;)
Update released. Now it should be all fine.

Update released.

Included the EditDropDownList run-time property to enrich the in-cell editing functionality.

The EditDropDownList may be set at the BeforeEdit event, either to vbNullstring (default; off) or to a string each item separated by pipe characters. ("|")
It works similar to the ComboList Property of the vsFlexGrid.
However, I don't use the ComboBox class. I rely on the edit window and extended the combo functionality as can be seen at following screen:
Attachment 168399

So everything works as normal with just some additional windows. The dropdown button is a Static control with SS_OWNERDRAW and SS_NOTIFY which can't get focus. So the edit window will not get destroyed by a lost focus.
The actual dropdown window is a ComboLBox class window with WS_POPUP style. It also don't receive focus and can't be activated, it just "captures" the mouse and key inputs.

Depending on how the EditDropDownList property is set it imitates a "Dropdown Combo" or "Dropdown List" style ComboBox.
"Dropdown List": (Edit window with ES_READONLY; DroppedDown immediately)

Code:

---

EditDropDownList = "ListItem 1|ListItem 2"

---

"Dropdown Combo": (Edit window unchanged; certain behavior adjustments)

Code:

---

EditDropDownList = "|ListItem 1|ListItem 2"

---

The additional EditDroppedDown run-time property can programmatically expand or collapse the dropdown list by code. In normal cases not needed.

Updated released.

The following point now got removed from the "List of incompatibilities in relation to the MSFlexGrid control"

Code:

---

- Fixed cell(s) without cell(s). (e.g. FixedRows = 1 and Rows = 1)

---

Thus at run-time it is now supported to have following code with the possibility where RecordCount is 0:

Code:

---

VBFlexGrid1.Rows = VBFlexGrid1.FixedRows + RecordCount

---

Thus the FixedRows is equal of Rows, having no scrollable rows in fact. (when RecordCount was 0)

The same applies of course for the cols.

This was one of the last steps before I release the next OCX version. I just wait for a while awaiting possible bug reports before I deploy the 1.3 OCX version.

Update related to 13-May-2019 update. (renamings)

Sorry for this inconvenience caused but I still had the chance to rename something before next OCX, so I did. :)

Following run-time properties got renamed:
EditDropDownList -> ComboList
EditDroppedDown -> ComboDroppedDown
hWndEditButton -> hWndComboButton
hWndEditList -> hWndComboList

This way everything related to the drop-down list has the prefix "Combo" and everything related to the text box has the prefix "Edit".
Doing this way it's cleaner seperated.

Included ComboCount/ComboItem/ComboIndex run-time properties helping to interact with the drop-down list during edit.

Included ComboDropDown/ComboCloseUp event. (like in a normal ComboBox)

Included ColComboList run-time property. It works similar to the ComboList property, except it applies to entire columns.
If both are defined then ComboList has precedence over ColComboList. (ComboList > ColComboList)

If were me, I prefer to name them like this:

ComboEditable
ComboButtonWnd
ComboListWnd

Quote:

---

Originally Posted by dreammanor

If were me, I prefer to name them like this:

ComboEditable
ComboButtonWnd
ComboListWnd

---

OK, I would propose following renamings then:
ComboList -> ComboEditable
ColComboList -> ColComboEditable
ComboItem -> ComboList
ComboCount -> ComboListCount
ComboIndex -> ComboListIndex

hWndComboButton and hWndComboList I want to keep as I used always the prefix "hWnd"... for such things, also in VBCCR.

Update released.

Final renamings now again..

ComboList -> ComboEditable
ColComboList -> ColComboEditable
ComboItem -> ComboList
ComboCount -> ComboListCount
ComboIndex -> ComboListIndex

The ComboEditable features comes in two flavor. Either as DropDownCombo or as DropDownList. The DropDownCombo already implemented auto selecting as the user types. However, the DropDownList now also supports incremental search as you type. So in both modes you can just start editing by typing, below image illustrates:

http://krool.mooo.com/Data/VBForums/...omboSearch.gif

Update released.

bugfix concerning right-to-left and the combo button and combo list for the in-cell editing window.

Also the combo button window is now being hot-tracked and drawn accordingly.
For this I have a open question:

Currently the combo button is drawn via DrawFrameControl with the old grayish look even when theming is enabled.
Should I keep it like this? It would fit in the overall look of the grid control?
Or use uxtheme and draw proper dropdown button ? (CP_DROPDOWNBUTTON with CBXS_DISABLED, CBXS_HOT, CBXS_NORMAL, CBXS_PRESSED)

http://krool.mooo.com/Data/VBForums/...onHotTrack.gif

Quote:

---

Originally Posted by Krool

Or use uxtheme and draw proper dropdown button ? (CP_DROPDOWNBUTTON with CBXS_DISABLED, CBXS_HOT, CBXS_NORMAL, CBXS_PRESSED)

---

I'd use uxtheme internally - but would also raise an event to the outside, to give the user a chance to ownerdraw this thing,
in case the Button shall be used for ones own Cell-Dialogue-PopUps or something (which is not a ComboDropDown)...

Event OwnerDrawCellButton(hDC, Width, Height, State)

The hDC:
- represents the "rectangular button-canvas-area to draw to"
- it could be pre-filled with the internal rendering (in case the user does not want to overdraw it completely, but just wants to "add little indicator-drawings")
- it should be properly clipped and translated (so that its origin is at 0,0)

Olaf

I think I would add a Style property that could set all the colors, border (flat or not and the thickness) to some predefined settings.
And add another property named VisualStyles that could set the colors to the Windows theme when is set to True (the same that you already did for other controls). And also set the border, line colors and such according to the theme.

About the drop down buttons:
When the user clicks a drop down button, I would raise an event and allow to cancel the display of the Combo list (adding a Cancel parameter ByRef) and then allow to handle the operation "manually", for example showing a custom form with some custom rules (and may be validations).
That would give much power to what can be done.

Quote:

---

Originally Posted by Eduardo-

When the user clicks a drop down button, I would raise an event and allow to cancel the display of the Combo list (adding a Cancel parameter ByRef) and then allow to handle the operation "manually", for example showing a custom form with some custom rules (and may be validations).
That would give much power to what can be done.

---

Yep, that was my thought behind the OwnerDrawEvent for this Button (to be able to signalize, "that other things will pop-up or drop-down").

And in case the "regular DropDown-List" is shown -
is this already a separate instance of the GridControl itself which hosts the Item-Listing?

If not, I would switch to that behaviour - since this allows (in the vsFlex) to render MultiColumn-DropDownLists
(when an appropriate MultiColumn-DataSource-Container was prepared beforehand)

Olaf

I think it also would worth checking what other grids controls do, I mean mostly commercial controls (may be even for other languages).
To see if there is any standard in how they do the things.
For this feature and for any feature with which the Flex grid is improved/added.

Along with the "styles" another feature that is nice sometimes to have is the ability to set alternate colors for the rows.
The property could be named perhaps AlternateRowsBackColor or AlternatingRowsBackColor.
In case you decide to implement predefines "styles" it could be part of what is preset.
This helps the user to visually follow the rows when the grids are wide without going up or down to a wrong row.

PS: the 'Printscreen To Clipboard' button in your demo doesn't work, the .Picture property returns just a 1x1 bitmap with a black pixel.

Quote:

---

Originally Posted by Eduardo-

Along with the "styles" another feature that is nice sometimes to have is the ability to set alternate colors for the rows.
The property could be named perhaps AlternateRowsBackColor or AlternatingRowsBackColor.
In case you decide to implement predefines "styles" it could be part of what is preset.
This helps the user to visually follow the rows when the grids are wide without going up or down to a wrong row.

PS: the 'Printscreen To Clipboard' button in your demo doesn't work, the .Picture property returns just a 1x1 bitmap with a black pixel.

---

There is already a 'BackColorAlt' property.
Thanks about the printscreen bug advise. Will check soon.

Quote:

---

Originally Posted by Eduardo-

About the drop down buttons:
When the user clicks a drop down button, I would raise an event and allow to cancel the display of the Combo list (adding a Cancel parameter ByRef) and then allow to handle the operation "manually", for example showing a custom form with some custom rules (and may be validations).
That would give much power to what can be done.

---

Good idea. Will include a Cancel parameter in the ComboDropDown event.

Quote:

---

Originally Posted by Schmidt

I'd use uxtheme internally - but would also raise an event to the outside, to give the user a chance to ownerdraw this thing,
in case the Button shall be used for ones own Cell-Dialogue-PopUps or something (which is not a ComboDropDown)...

Event OwnerDrawCellButton(hDC, Width, Height, State)

---

That sounds easier than providing a ton of properties to control customized extra wishes. Will check soon.

Quote:

---

Originally Posted by Krool

There is already a 'BackColorAlt' property.

---

Ah OK, very good.

Quote:

---

Originally Posted by Eduardo-

the 'Printscreen To Clipboard' button in your demo doesn't work, the .Picture property returns just a 1x1 bitmap with a black pixel.

---

Update released. Fixed.

Quote:

---

Originally Posted by Eduardo-

I think it also would worth checking what other grids controls do, I mean mostly commercial controls (may be even for other languages).
To see if there is any standard in how they do the things.
For this feature and for any feature with which the Flex grid is improved/added.

---

The vsFlexGrid seems to have an alias in their ComboList property.

Translated to VBFlexGrid this would mean following:
If the ComboEditable (or ColComboEditable) is either "..." or "|..." then a pop-up button is shown, else a drop-down button.
The difference between "..." and "|..." is that the first one would be read-only edit window and the second one a normal edit window.
Clicking on the pop-up button would fire an CellButtonClick event.

I think that's a good approach, no?

Quote:

---

Originally Posted by Krool

OK, I would propose following renamings then:
ComboList -> ComboEditable
ColComboList -> ColComboEditable
ComboItem -> ComboList
ComboCount -> ComboListCount
ComboIndex -> ComboListIndex

hWndComboButton and hWndComboList I want to keep as I used always the prefix "hWnd"... for such things, also in VBCCR.

---

If it is not set in stone already, I would like to say that I don't agree with those changes.
These property names are not intuitive for what they are or they do, at least to me.

I was trying to figure how to use them and what each one does, and to compare to the vsFlexGrid... (in order to form an opinion to answer your last message)

Why at least not to stick to the names already used by vsFlexGrid?

About to set the style of the dropdown button, the "standard" options would be arrow down (like a combobox), horizontal ellipsis, and not it is becoming popular also the vertical ellipsis used by Google (mostly in Android, but also in Google Chrome for Windows): ⁝

Also, here I found documentation of the vsFlexGrid, it could be useful.

VBFlexGrid1.Col = 0
VBFlexGrid1.Row = 1
VBFlexGrid1.ColSel = VBFlexGrid1.Cols - 1
VBFlexGrid1.RowSel = VBFlexGrid1.Rows - 1

These codes can select the specified line. What if you cancel the selection of one line or all(Other lines remain selected)?

Quote:

---

Originally Posted by Eduardo-

If it is not set in stone already, I would like to say that I don't agree with those changes.
These property names are not intuitive for what they are or they do, at least to me.

I was trying to figure how to use them and what each one does, and to compare to the vsFlexGrid... (in order to form an opinion to answer your last message)

Why at least not to stick to the names already used by vsFlexGrid?

About to set the style of the dropdown button, the "standard" options would be arrow down (like a combobox), horizontal ellipsis, and not it is becoming popular also the vertical ellipsis used by Google (mostly in Android, but also in Google Chrome for Windows): ⁝

Also, here I found documentation of the vsFlexGrid, it could be useful.

---

As long as the 1.3 OCX is not released I can change names. However, the names used by the vsFlexGrid are also not always intuitive.

We can agree for the in-cell editing drop-down functionality the prefix "Combo" should be used.
A normal ComboBox has a List, ListCount and ListIndex property.
So in order to assume the same output the grid's properties are then ComboList, ComboListCount and ComboListIndex.
In order to enable the drop-down functionality the property ComboEditable (or ColComboEditable) is used.
If it's empty the combo is not used, else it contains the strings used for populating the list. (separated by pipe chars)
So in fact the ComboEditable works like the ComboList property in vsFlexGrid. But I don't find ComboList intuitive, as the List property in a ComboBox returns a item by a given index.

Quote:

---

Originally Posted by ChenLin

VBFlexGrid1.Col = 0
VBFlexGrid1.Row = 1
VBFlexGrid1.ColSel = VBFlexGrid1.Cols - 1
VBFlexGrid1.RowSel = VBFlexGrid1.Rows - 1

These codes can select the specified line. What if you cancel the selection of one line or all(Other lines remain selected)?

---

The VBFlexGrid (same as MSFlexGrid) does not support multi-selection blocks. It's either single or all.
What might be added in future is a special SelectionMode 'ListBox' which can work in conjunction with a RowSelected property to allow partial selections by rows. (like a ListBox can do)

Quote:

---

Originally Posted by Schmidt

is this already a separate instance of the GridControl itself which hosts the Item-Listing?

---

What do you mean exactly?

Quote:

---

Originally Posted by Schmidt

I'd use uxtheme internally

---

Done.

Quote:

---

Originally Posted by Krool

As long as the 1.3 OCX is not released I can change names. However, the names used by the vsFlexGrid are also not always intuitive.

We can agree for the in-cell editing drop-down functionality the prefix "Combo" should be used.
A normal ComboBox has a List, ListCount and ListIndex property.
So in order to assume the same output the grid's properties are then ComboList, ComboListCount and ComboListIndex.
In order to enable the drop-down functionality the property ComboEditable (or ColComboEditable) is used.
If it's empty the combo is not used, else it contains the strings used for populating the list. (separated by pipe chars)
So in fact the ComboEditable works like the ComboList property in vsFlexGrid. But I don't find ComboList intuitive, as the List property in a ComboBox returns a item by a given index.

---

I totally agree, vsFlexGrid's Combo* property names are not intuitive either. My point was that the people will have only one set of unintuitive properties and not two.

I'll tell you my experience: yesterday (or may be the day before), I downloaded your control to take a look to what you have added lately. I remembered you have been working in the editing feature, so I wanted to check it.
Then I went to the middle of the property window and looked for a property with "E", something like "Editable", "Edit*" . I found nothing. Then I looked really quicky to see if I saw any property name that can be for editing and I found nothing. I opened the property pages, again navigated all the pages and took a quick look to all the properties, but I found nothing that could be intended for editing.
I thought "it is still not implemented in this version".

After that, I downloaded the vsFlexGrid to study some things. I went to the "E" and found the property "Editable".

After a while, reading here this thread I found that the property was named "AllowUserEditing", that seems fine now that I think... but I didn't find it at first.

Another thing that I noticed is that your property is Boolean whilst the vs has two options for editing. From their names it seems that one is by keyboard and the other by mouse. But in practice I didn't find a difference.

Another difference that I found is that with the vbFlexGrid you require double click to enter the edit mode whilst the vs enters the edit mode with just one click.
I think it would be nice to have both options.

With the vs one Enter keystroke over a cell means to enter the Edit mode. With yours I didn't find a way to enter the edit mode with the keyboard.

In regard to property names. I see it is difficult to find good property names for these properties.
After thinking a bit, an option could be:

Editable (or EditMode) with three options: no, simple click, double click
EditDropList or EditDropPipedList or EditModeList or EditModePipedList
EditDropListCount or EditModeListCount
EditDropListIndex or EditModeListIndex

After considering, I think I prefer:

EditMode
EditModeList (but still considering EditModePipedList)
EditModeListCount
EditModeListIndex

That's my opinion.

Quote:

---

Originally Posted by Eduardo-

After a while, reading here this thread I found that the property was named "AllowUserEditing", that seems fine now that I think... but I didn't find it at first.

---

The intention about "AllowUserEditing" is that it enables the end-user to initiate editing by keyboard or mouse.
It is however always possible to start editing by code, even if AllowUserEditing is False.
Having a Editable property would sound that even by code it's not possible..

Quote:

---

Originally Posted by Eduardo-

Another difference that I found is that with the vbFlexGrid you require double click to enter the edit mode whilst the vs enters the edit mode with just one click.
I think it would be nice to have both options.

With the vs one Enter keystroke over a cell means to enter the Edit mode. With yours I didn't find a way to enter the edit mode with the keyboard.

---

It's possible to start editing by keystroke.

It has following starting modes: (in bold the ones for keyboard)

FlexEditReasonCode = 0
FlexEditReasonF2 = 1
FlexEditReasonSpace = 2
FlexEditReasonKeyPress = 3
FlexEditReasonDblClick = 4

It is easy to enhance it so editing can be started by an return key:

Code:

---

Private Sub VBFlexGrid1_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyReturn Then VBFlexGrid1.StartEdit
End Sub

---

Or to allow a simple click, instead of double click:

Code:

---

Private Sub VBFlexGrid1_CellClick(ByVal Row As Long, ByVal Col As Long, ByVal Button As Integer)
If Row >= VBFlexGrid1.FixedRows And Col >= VBFlexGrid1.FixedCols Then VBFlexGrid1.StartEdit Row, Col
End Sub

Private Sub VBFlexGrid1_BeforeEdit(Row As Long, Col As Long, ByVal Reason As FlexEditReasonConstants, Cancel As Boolean)
If Reason = FlexEditReasonDblClick Then Cancel = True
End Sub

---

As you see there is a set of standard implementation, but it's easy to change it.

Update released.

For the namings I made now following decision:

Removed ComboEditable/ColComboEditable property as it got now replaced by two new properties.

The two new properties are:
ComboMode/ColComboMode As FlexComboModeConstants
ComboItems/ColComboItems As String

The ComboMode property is defining the combo functionality mode:
- FlexComboModeNone -> No combo button, normal editing
- FlexComboModeDropDown -> Allows to modify by drop-down list only (edit field is read-only)
- FlexComboModeEditable -> Allows to modify by edit field and drop-down list, some specific behavior.

The ComboItems property defines the list items to be used for the drop-down list. (each item seperated by "|")

It is possible to have ComboMode <> FlexComboModeNone and ComboItems = "". This results then in a drop-down list with no items.

This architecture is more clear and doesn't requires cumbersome aliases for the string property that defines the drop-down list.

Also it is then easier to include new modes, e.g. FlexComboModePopUp.
FlexComboModePopUp would be just a combo button without any drop-down list. (Thus ComboItems would be ignored)
In FlexComboModePopUp the combo button would then be a normal button with ellipsis ("...")

Again, doing this way no aliases are necessary and gives better understanding even without reading any documentation. Because it is really cumbersome without reading any documentation or the demo project to know what aliases would be necessary to have a specific mode, like the vsFlexGrid do.