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.Quote:
Originally Posted by ChenLin
Printable View
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.Quote:
Originally Posted by ChenLin
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:
Because the row number will be the same before and after sorting. But the actual row information is moved.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
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 Krool
Because for columns a string representation is better (e.g. field name) whereas by rows a number representing fits better (e.g. primary key)Quote:
Originally Posted by DaveDavis
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!
Yes, ok. It says:Quote:
Originally Posted by jpbro
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!
Yes, you can. But only the OCX version and office 32-bit.Quote:
Originally Posted by southmark
Thanks for the reply.Quote:
Originally Posted by Krool
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.
'The module "VBFLXGRD12.OCX": was loaded but the call to DllRegisterServer failed with error code 0x80004005.'Quote:
Originally Posted by Krool
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 :-)
I could replicate the issue and update released. Please re-download the OCX.Quote:
Originally Posted by southmark
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
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?Quote:
Originally Posted by southmark
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 Krool
Did you start cmd as admin ? (Run as administrator)Quote:
Originally Posted by southmark
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).Quote:
Originally Posted by Karl77
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)
You are completely right with all you said.Quote:
There are no classes, so no problem for that like in ListView (without VirtualMode).
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!
Hi Krool, sorry for the late reply - I went on holiday. I do appreciate your feedback.Quote:
Originally Posted by Krool
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!
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
The Click event of Farpoint Spread and my Spread is like this:Quote:
Originally Posted by Krool
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.Quote:
Originally Posted by Krool
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.
You suggest even changing the col when ByRow selection mode?Quote:
Originally Posted by dreammanor
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 Krool
I understood it this way. However you agree another property is needed to control this behavior?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.Quote:
Originally Posted by Krool
Maybe "FlexSelectionModeByRowFree"Quote:
Originally Posted by dreammanor
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.Quote:
Originally Posted by Krool
removed
Quote:
Originally Posted by Krool
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.
My vote is for Option A. Implement the new behavior and do not add any new property.Quote:
Originally Posted by Krool
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.