Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
...
The LinkLabel is a different story, but there is no way I can see to have a Center Alignment.
So I guess you need to "manually" center it with line breaks and spaces.
Thanks for the reply.
I wasn't hopeful with the LabelW queston. I was checking the LinkLabel in VS 2017 Form and there is center alignment so I tried my luck. Guess the only way for me now to adopt Win10 GUI is to bite the bullet and go UWP and accept the fact that I can only target Win10 and later.
Re: CommonControls (Replacement of the MS common controls)
Update released.
Included the ShowTips property in the CoolBar control and the corresponding ToolTipText property of a Band.
RBS_TOOLTIPS style is not working (according to MSDN "not yet supported"), so it was necessary to create a own internal tool tip control.
The "hot region" for showing the ToolTipText is the caption/icon area in a Band.
Re: CommonControls (Replacement of the MS common controls)
This post - http://www.vbforums.com/showthread.p...=1#post5160309 - of mine, in the related ActiveX thread, is with regard to some problems encountered by me while using the RichTextBox control of the 'MS Common Controls Replacement' project. I realised today that there is not much activity in the related ActiveX thread. Hence, I am now re-posting my aforesaid reply-post in this thread, hereunder. Hope thats okay, Krool and others. Kindly please help.
First and foremost, thanks a ton to Krool for this wonderful effort. This is absolutely marvelous and it is pretty exciting to go through the various aspects of this project (Replacement of the MS common controls). Though I am interested in all the controls, as of now, my primary interest is on the RichTexBox. So, I started experimenting with it and I encountered some problems.
I am listing the problems below along with a code snippet to illustrate the problems. Please note that I am new to this forum and this is the first time I am writing here. So, in case I have not followed any protocols related to posting, kindly bear with me and please do guide me for later posts. Also, in case I have understood things completely wrongly about one or more aspects of either the RichTextBox control of this project or of this project itself and that is the reason for me facing the following problems, then kindly correct my understanding and kindly guide me as to what to do to set right the following problems.
Problems:
1. When I set some string (e.g. "a") for a RichTexBox control (say, named 'rtb1') and then compare the text with the same string (i.e. if rtb1.text = "a"), the comparison does not return true. Also, adding some string to the end of 'rtb1' results in characters not present in the string getting added (and displayed). I found that space in the original string was always getting replaced by a character whose Unicode value was U2000 (Decimal - 8192). Same with other characters, as far as I observed. A specific character (say 'a') was always getting replaced by one other specific character.
2. 'Len' and 'Instr' consider "VbCrLf"s fully whereas 'SelStart' and 'Find' ignore the Lf in "VbCrLf"s. Because of this, inconsistencies arise.
The code below illustrates what happens because of the above two problems. It needs a Form with a CommandButton (Command1) and a RichTextBox (named 'rtb1')
Code:
Private Sub Command1_Click()
Dim s As String
s = " a " & vbCrLf & vbCrLf & " ab"
rtb1.Text = s
If rtb1.Text = s Then
MsgBox "yes"
End If
MsgBox "Length = " & Len(rtb1.Text) '10 is displayed
rtb1.SelStart = Len(rtb1.Text)
MsgBox "Selstart = " & rtb1.SelStart '8 is displayed
MsgBox "Instr b = " & InStr(rtb1.Text, "b") '10 is displayed
MsgBox "Find b = " & rtb1.Find("b") '7 is displayed
rtb1.Text = rtb1.Text & s 'characters not present in string 's' get added (and displayed)
End Sub
Note-1:
After working on "problem 1" for around 6 hours - to find its cause and a possible solution, I finally set right the problem at my end by introducing a line of code in the following function of 'RichTextBox.ctl'.
Code:
Private Function StreamStringOut(ByRef Value As String, ByVal Flags As Long) As Long
I added the following line
Code:
Value = Left$(Value, Len(Value))
after the line
Code:
Value = RtfStreamStringOut()
in the aforesaid 'StreamStringOut' function.
I am not at all suggesting that the inclusion of the above line of code is the right thing to do. I am just mentioning what I did so that it can serve as a tip to Krool or any other member to find out the right thing to be done, eventually.
Note-2:
As of now, I do need VbCrLf in my programs. So, I would be happy if the eventual solution does consider VbCrLf fully so that it is consistent with the behavior of the normal RichTextBox (RICHTX32.OCX component, I mean).
Note-3:
I have tested with the latest version of the ocx control (1.4.11). My system is Windows 7, 64-bit.
A few queries now:
1. The links in the RichTextBox are not clickable. I have to set some property on or off to make them clickable? If so, what is that property? If not, is anything planned for making the links clickable in future?
2. The normal RichTextBox wraps text around even if horizontal scroll bar is set. The RichTextBox of this project wraps text around only when the horizontal scroll bar is not set. Can the RichTextBox of this project also made to wrap text around even if horizontal scroll bar is set?
Re: CommonControls (Replacement of the MS common controls)
Update released. (Thanks to softv)
Originally Posted by softv
Problems:
1. When I set some string (e.g. "a") for a RichTexBox control (say, named 'rtb1') and then compare the text with the same string (i.e. if rtb1.text = "a"), the comparison does not return true.
There was indeed an error in the RtfStreamCallbackStringOut and RtfStreamStringIn function in the RichTextBoxBase.bas module.
Fix in RtfStreamCallbackStringOut
Code:
ReDim Preserve StreamStringOut(0 To (StreamStringOutUBound + BytesRequested - 1)) As Byte
Fix in RtfStreamStringIn
Code:
ReDim StreamStringIn(0 To (StreamStringInLength - 1)) As Byte
The Byte array is zero-based so the string was then in fact 11 bytes long for a 5 char (10 bytes) string.
However, Len() still reports 10, but comparison did not return true as 11 bytes vs 10 bytes. That's why your workaround with Value = Left$(Value, Len(Value)) "solved" the issues as it cut of the 1 byte at the end. But now the error is solved at the root cause.
The other issues concerning the 'SelStart' and 'Find' I don't have a solution. I have no influence of what EM_EXGETSEL/EM_EXSETSEL or EM_FINDTEXTEX does.
Re: CommonControls (Replacement of the MS common controls)
Krool, I've said it before but I'll say it again. You're INCREDIBLE to maintain this code to the level you do. I maintain substantial pieces of code myself, but I typically get paid for it. It's all GPLv3 open source, but I still get paid for improvements. On the beneficent side, I do try to throw generic chunks of it out onto these forums as often as I can when it seems appropriate.
But what you've done here is truly remarkable.
Best Regards,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Re: CommonControls (Replacement of the MS common controls)
Just some thoughts regarding the InStr() and Find() not returning same value. Using the exact code 3 posts up and in IDE using the standard RTF ocx (not this project's RTF control), those functions do NOT return the same value. However, Len() and SelStart() do.
I don't know what version VB's standard RTF is, but have read that RTF standards v1 used CrLf (internally) for /par markers and v2 uses Lf (internally). This appears to be the reason for the differences in this project's RTF? And if tested, if you added this text: "0123456789" & vbCrLf, 10 times, Len() should be 10 characters longer than SelStart after SelStart=Len()
Note that when rtf is converted to standard text, /par is converted to CrLf. Am unsophisticated test is setting the control's text to: "a" & vbLF. Len() returns 3 not 2. Hence Len() which works on non-rtf returning more characters than SelStart which works on rtf.
Last edited by LaVolpe; Apr 17th, 2017 at 08:54 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: CommonControls (Replacement of the MS common controls)
Thanks for your very prompt multiple action (fixing the error at its root and also releasing a new update immediately), Krool. Great!
This project is a phenomenal work, not only because of the complexity involved but for the immense benefit it is providing as well. 1000s of developers must be getting benefited through this work and as a consequence, millions of end-users must be getting benefited too. In that way, what a monumental contribution to the world society!
Well, reg. 'SelStart' and 'Find', I will try to do something similar to what I did for "problem 1". If I succeed, I will share the lines of code here so that, if at all possible, you can give an eventual solution for the issues concerning 'SelStart' and 'Find' also.
I will also try to study more about EM_EXGETSEL/EM_EXSETSEL and EM_FINDTEXTEX.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by LaVolpe
Just some thoughts regarding the InStr() and Find() not returning same value. Using the exact code 3 posts up and in IDE using the standard RTF ocx (not this project's RTF control), those functions do NOT return the same value.
Actually, I had tested that same code at my end too, with the standard rtf ocx. I tested it again at my end after reading your above observation. Find() returned/returns the expected value (9), which is one lesser than the value (10) returned by InStr(). So, with standard rtf ocx, Find() does work correctly at my end, right? Kindly advise. My richtx32.ocx version is 6.1.97.82.
Re: CommonControls (Replacement of the MS common controls)
Hi Kroll,
Congratulations for your effort, first of all!!!
There's no alternative for mscomctl.ocx 64bit and I'm struggling to find a solution for that since Microsoft doesn't seem to care. Could your replacement project be compiled for 64bit?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by dan_p
Hi Kroll,
Congratulations for your effort, first of all!!!
There's no alternative for mscomctl.ocx 64bit and I'm struggling to find a solution for that since Microsoft doesn't seem to care. Could your replacement project be compiled for 64bit?
Thanks and kind regards,
Dan
If you can find a 64bit VB6 compiler, Krool will make it happen!
Re: CommonControls (Replacement of the MS common controls)
Update released.
All internal tooltips are now as top-most. (effects all controls that have a internal tooltip control)
When the tooltip was created by the common control itself it will be changed via SetWindowPos HWND_TOPMOST, otherwise (own tooltip) WS_EX_TOPMOST will be simply added on CreateWindowEx.
I think it is not "unusual" to set the tooltip window as top-most, there are many tutorials/examples that suggest in doing so to ensure that the tooltip will always be shown.
Reason that it could not be displayed would be for example when the form window is set to top-most, then the tooltip is displayed behind it. Now it will display correctly in that scenario.
Re: CommonControls (Replacement of the MS common controls)
Label problem:
Place 2 labels on a form, both the same font and fontsize.
1 standard label
1 Krool label
Then execute this:
Code:
With Label1
.AutoSize = True
.Caption = "abcdefg"
Debug.Print "Label1: ", .Width
End With
With LabelW1
.AutoSize = True
.Caption = "abcdefg"
Debug.Print "Labelw1: ", .Width
End With
The labels both appear correct, their width is ok.
But the widths are different numbers:
The width is 71 pixels.
Screen.TwipsPerPixelX is 12.
71 x 12 = 852
Something is wrong so far...
Next effect:
When I execute the code the second time, the width is 852 for both labels.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
The labels both appear correct, their width is ok.
But the widths are different numbers:
When I execute the code the second time, the width is 852 for both labels.
When you set a new caption, then in LabelW a UserControl.Refresh is done. The effective autosizing is done in the UserControl_Paint event as there is a hDC available which is necessary for a DrawText DT_CALCRECT.
However, it seems there is a "lag" from UserControl.Refresh to effective UserControl_Paint, kind of a PostMessage "effect". It is not immediately.
I have no idea for the moment of how to solve it. Of course a "Call UserControl_Paint" instead of "UserControl.Refresh" seems to solve the issue, but actually that is not "allowed", or?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Of course a "Call UserControl_Paint" instead of "UserControl.Refresh" seems to solve the issue, but actually that is not "allowed", or?
With a windowless control, you need the host to initiate the paint event since it is what sends the UC a clipped hDC to draw on. The delay you are seeing is likely between your Refresh call, VB getting that call, and then deciding when to initialize a paint.
One workaround in this case is to resize the control after setting the caption, when AutoSize is active. If you opt for this, it should be employed in the AutoSize property also when setting it to True.
Code:
Public Property Let Caption(ByVal Value As String)
...
If Me.AutoSize Then
UserControl.Extender.Width = UserControl.Extender.Width + Screen.TwipsPerPixelX \ 2 + 1
Else
Me.Refresh
End If
...
This should force VB to call a repaint immediately, before your property returns, and the resizing above doesn't matter because your AutoSize will resize the control anyway. Just a thought. Personally, I don't necessarily like using TwipsPerPixelX as the offset because that can be quite large if the container's scalemode is say vbInches. A better approach would be to determine the container's scalemode. TwipsPerPixelX is likely the largest unit which should guarantee a resize. If scalemode was twips and we increased size by just +1, no resize event occurs.
Another workaround is to invalidate the rect of your usercontrol within the host and force a redraw via API. But that may be more difficult for windowless controls than the suggestion above.
Edited: The downside is that when a border is visible, you may see a flash between the resizing. Maybe the Extender left,top should be used in an Invalidate call after all. But you'll have to find the container's hWnd because your control's container could feasibly be another windowless usercontrol (no hWnd to be used with RedrawWindow)
Last edited by LaVolpe; Apr 20th, 2017 at 05:12 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by LaVolpe
But you'll have to find the container's hWnd because your control's container could feasibly be another windowless usercontrol (no hWnd to be used with RedrawWindow)
FYI, windowless controls cannot be controls containers per se and this makes ContainerHwnd property always available I guess.
Btw, this project needs a github repo since long time ago (and probably has been suggested numerous times already).
Re: CommonControls (Replacement of the MS common controls)
FYI, windowless controls cannot be controls containers per se
Actually, that's the only type of control a windowless control can contain. I'm just not sure (have never tried it) if a VB windowless UC can have the ControlContainer property set to True and be assigned as a container for another windowless control that way. However, while the UC is being designed, this is doable with/without the ControlContainer property. I sure hope my memory is good here; not near a VB box prove myself wrong
Edited: Just a follow up now that I have access to VB again. I created a windowless, transparent, UC and simply placed Krools LabelW inside it & set its backstyle to transparent. When that UC was placed on a form, both the UC & LabelW remained transparent. But your 2nd point appears to 100% valid: The LabelW control reported the UC's container hWnd as its own ContainerHwnd. But, subclassing was a bit messed up in that scenario.
Last edited by LaVolpe; Apr 21st, 2017 at 12:46 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: CommonControls (Replacement of the MS common controls)
Update released for the LabelW control. (thanks to Karl77 to bring this issue up)
It got now two internal improvements.
Explanation/Solution:
The first improvement concerns the AutoSize property when the Alignment is <> Left and/or the VerticalAlignment is <> Top.
Now the glitch as can be seen in the screen below will not happen anymore.
This was solved by making an "InvalidateRect .ContainerHwnd, RC, 1" after the resizing and reposition of the control, where RC is the old bounding rectangle.
The second improvement concerns also the AutoSize property. Problem was that after property returns the new state is not reflected immediately, because we needed to wait for a UserControl_Paint to occur in order to do the resizing and reposition. (auto sizing)
That issue was solved by modifying the Refresh method as following:
Code:
Public Sub Refresh()
If LabelAutoSizeFlag = False Then
UserControl.Refresh
Else
Dim RC As RECT
With UserControl
RC.Left = .ScaleX(.Extender.Left, vbContainerPosition, vbPixels)
RC.Top = .ScaleY(.Extender.Top, vbContainerPosition, vbPixels)
RC.Right = RC.Left + .ScaleWidth
RC.Bottom = RC.Top + .ScaleHeight
InvalidateRect .ContainerHwnd, RC, 1
UpdateWindow .ContainerHwnd
' In UserControl_Paint the bounding rectangle will be invalidated again.
' That's why two times UpdateWindow is necessary.
UpdateWindow .ContainerHwnd
End With
End If
End Sub
So only when LabelAutoSizeFlag is True the redrawing is done immediately. (and thus the auto sizing)
And that is necessary to have the new bounding dimensions set before the property returns in order to work with.
However, when LabelAutoSizeFlag is False the normal .Refresh method is used as no immediate redraw is necessary and also not wanted.
Because else when you set 10x Caption in a row it would be redrawn 10x, but with UserControl.Refresh it will be consolidated to 1x redraw, which is common behavior all over to improve performance.
So in fact when you have AutoSize set to True and change the Caption 10x it will be redrawn 10x. But in that special case it is actually wanted because maybe you want to check on each Caption change the resulting Width etc.
Re: CommonControls (Replacement of the MS common controls)
Krool thanks for so much hard work.
One little change/addition I made to the
PPImageListImages.CommandInsert routine
to save some user drudgery:
Code:
Dim Path As String, FileNames() As String
Dim OpenFileDialog As CommonDialog
Set OpenFileDialog = New CommonDialog
With OpenFileDialog
.Flags = CdlOFNExplorer Or CdlOFNPathMustExist Or CdlOFNFileMustExist Or CdlOFNAllowMultiSelect
.MaxFileSize = .MaxFileSize * 5000
.Filter = "All Picture Files|*.ICO;*.CUR;*.BMP;*.GIF;*.JPG|Icons & Cursors (*.ICO;*.CUR)|*.ICO;*.CUR|Bitmaps (*.BMP;*.DIB)|*.BMP;*.DIB|GIF Images (*.GIF)|*.GIF|JPEG Images (*.JPG)|*.JPG|All Files (*.*)|*.*"
.DialogTitle = "Select Picture"
.InitDir = GetSetting("VBCCR14", "ImageList", "File", App.Path)
End With
If OpenFileDialog.ShowOpen = True Then
With OpenFileDialog
If InStr(.FileName, vbNullChar) <> 0 Then
Path = Left$(.FileName, .FileOffset - 1)
If Not Right$(Path, 1) = "\" Then Path = Path & "\"
FileNames() = Split(Mid$(.FileName, .FileOffset + 1), vbNullChar)
Else
Path = Left$(.FileName, .FileOffset)
ReDim FileNames(0) As String
FileNames(0) = .FileTitle
End If
End With
If Not Path = vbNullString Then
SaveSetting "VBCCR14", "ImageList", "File", Path
Last edited by VBClassic04; Apr 22nd, 2017 at 07:15 AM.
Re: CommonControls (Replacement of the MS common controls)
is there a way to manipulate the width of the combo/list box scrollbar?
not sure this is the right place for this question, but it would sure be a very useful addition to the controls.
thanks
Re: CommonControls (Replacement of the MS common controls)
Textbox, small problem
This is an optical problem, no complaints about the functionality.
When the CCBorderStyleSingle is set, the control loses the upper horizontal line of the border.
It is ok when the textbox doesn't have the focus.
To retrace:
Start a fresh VB.
Add the Krool controls.
Set the font of the Form1 to Segoe UI, 11.
Place a textbox on the form.
Copy and paste this textbox, create a control array.
Set the borderstyle CCBorderStyleSingle to the copied textbox.
Run.
Click into the textbox that has CCBorderStyleSingle.
Now you should see this:
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
Textbox, small problem
This is an optical problem, no complaints about the functionality.
When the CCBorderStyleSingle is set, the control loses the upper horizontal line of the border.
It is ok when the textbox doesn't have the focus.
To retrace:
Start a fresh VB.
Add the Krool controls.
Set the font of the Form1 to Segoe UI, 11.
Place a textbox on the form.
Copy and paste this textbox, create a control array.
Set the borderstyle CCBorderStyleSingle to the copied textbox.
Run.
Click into the textbox that has CCBorderStyleSingle.
Now you should see this:
I cannot replicate the problem, at least on win 7.
Somebody else has this issue?
Re: CommonControls (Replacement of the MS common controls)
When the TextBoxW height is not "tall" enough. Depending on the height, either the top border or both top and bottom border do not show. The solution is to set the height tall enough.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
When the TextBoxW height is not "tall" enough. Depending on the height, either the top border or both top and bottom border do not show. The solution is to set the height tall enough.
Tested on Win7.
But normally that should not appear as the edit has its margin from border to content. The content should be clipped then.
Re: CommonControls (Replacement of the MS common controls)
Only when CCBorderStyleSingle is applied and the TextBoxW is not "tall" enough. I just did some quick sample. Actually don't have to create a control array. Also no need to be Segoe UI.
Re: CommonControls (Replacement of the MS common controls)
Earlier I ran the project from the IDE. I just compiled and run the exe. Now no need to have the focus. Note in the screenshot, the focus is on the left.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chenfrank_1
Hello Krool ,
Thanks for offer the CommonControls. That I can use controls in Unicode.
Something need to help.
I use the "Listview" control, attachment show we can change the subItem data when we click the data.
And double Click the data to show some dialog to choose.
How to do that ? Need your help.
Thanks
Your image shows kind of a flex grid control and not a ListView control.
The ListView control is intended to represent data and not to edit data, thus without additional custom code there is no sub item edit available out of the box.
Just wanted to reply to this update regarding the .FilterIndex property - I can confirm now that in my original scenario which had the problem, the issue is now fixed. I substituted the most recent VBCCR14 in place of what we had been using (VBCCR12) and the problem was resolved. Thanks!
Re: CommonControls (Replacement of the MS common controls)
Update released.
Improved the "DPI Awareness" in the controls.
The pixel dimensions of the StdPicture objects were retrieved via UserControl.ScaleX/Y and vbHimetric/vbPixel.
According to LaVolpe's latest addition in his "Being DPI Aware" Tutorial he reported that VB's ScaleX/Y is broken on exocit or very large DPI settings.
And indeed, in my testings a 16x16 icon got reported 17x17 at 175% DPI.
With the new included internal functions CHimetricToPixel_X/Y in Common.bas the correct value 16x16 will be retrieved. (16x16 is just an example)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Update released.
Improved the "DPI Awareness" in the controls.
The pixel dimensions of the StdPicture objects were retrieved via UserControl.ScaleX/Y and vbHimetric/vbPixel.
According to LaVolpe's latest addition in his "Being DPI Aware" Tutorial he reported that VB's ScaleX/Y is broken on exocit or very large DPI settings.
And indeed, in my testings a 16x16 icon got reported 17x17 at 175% DPI.
With the new included internal functions CHimetricToPixel_X/Y in Common.bas the correct value 16x16 will be retrieved. (16x16 is just an example)
AFAIK the problem is that VB handles the TwipsPerPixelX/Y for the screen (unlike the printer object) with integers, so if the actual value of TwipsPerPixelX/Y is not an integer, there will be problems.
At 96 DPI: for Windows it is 100%, there are 15 TwipsPerPixelX/Y, an integer.
At 120 DPI: for Windows it is 125%, there are 12 TwipsPerPixelX/Y, an integer.
At 144 DPI: for Windows it is 150%, there are 10 TwipsPerPixelX/Y, an integer.
The following preset option that Windows has is 192 DPI, 200%, and the TwipsPerPixelX real value for that is 7.5, a non integer, and there are problems in VB at that DPI setting because VB threat the TwipsPerPixelX/Y as being 7 (or 8, i don't remember now how it rounds).
At 175%, it is 168 DPI, and the value for TwipsPerPixelX/Y is 8.5714285714285714285714285714286, a non integer, probably rounded to 9 in VB. And there will be problems at that DPI in VB.
The problems are not limited to the ScaleX/Y functions and the Screen.TwipsPerPixelsX/Y properties, the position and size of the controls that VB handles automatically are also affected.
For high DPI that can work on VB, we need to chose an integer for TwipsPerPixelX/Y, for example:
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Eduardo-
The problems are not limited to the ScaleX/Y functions and the Screen.TwipsPerPixelsX/Y properties, the position and size of the controls that VB handles automatically are also affected.
I know. The size will be "corrected" already within UserControl_Resize. In a way that afterwards .ScaleWidth etc. will report correct.
That point with himetric conversion was only an additional issue.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
I know. The size will be "corrected" already within UserControl_Resize. In a way that afterwards .ScaleWidth etc. will report correct.
That point with himetric conversion was only an additional issue.
Yes, you can make the controls to work properly on non integer TwipsPerPixelsX/Y values and that's very nice, and for some projects it will be a solution, but in most cases VB still won't work properly, because it will position and size the forms wrongly, and if the program uses Screen.TwipsPerPixelsX/Y to position controls (or for other purposes) it will report a wrong value. Also ScaleX/Y of the forms will fail.
Unfortunately, we'll need a fix on VB itself to solve that.
Re: CommonControls (Replacement of the MS common controls)
I just want to put out a question in the room.
Shall my new VBFlexGrid (almost completed) be included in this project or separated as initially intended to be?
Reason for my struggle is that it would fit perfectly in the architecture of this project, but did it separate because of the size and complexity.
However, who cares if the VBCCR15.OCX will be 4.4 MB or 5.6 MB?
Thanks
Re: CommonControls (Replacement of the MS common controls)
Congratulations, Krool. I am extremely interested in your new VBFlexGrid.
I have used the Farpoint Spread control for many years. IMO, the new VBFlexGrid should be separated into a independent control, because the Grid control is too complicated, the size of a fully functional Grid control will eventually reach 2-5M, or even greater.
In addition, separating VBFlexGrid as a stand-alone control makes it easier for users to use it.
Look forward to seeing your new control as soon as possible.
Added:
The size of the VBFlexGrid is not a problem. However, the VBFlexGrid is a new control, when it is a separated OCX, it will be more convenient to debug, correct errors and add new features. At the same time, it won't affect the original VBCCR controls.
Of course, if the VBFlexGrid is integrated into a single file, there are other benefits.
Last edited by dreammanor; May 8th, 2017 at 05:03 AM.