-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
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
My first thought is that it's better to have everything in a single file.
Let's try to find the pros and cons:
Pros:
1) Everything in a single file/reference, is simpler.
2) Easier to find for people that don't know that it is available out there.
3) The file size is not a problem nowadays (at least in most of cases, perhaps 99%).
Cons:
1) To have everything together increase the number of types available. I mean, for example, one reason I don't like to use ADO is because I'm used to declare String variables as Dim a as str[and press Space or Enter] and it becomes Dim a as String, but having a reference to ADO it becomes Dim a as Stream, and I need to navigate down for several types to find String.
The point is that having unused Types is not good for intellisense.
Others?
-
Re: CommonControls (Replacement of the MS common controls)
I would prefer a single file solution as well.
When fixes like the last DPI issue are solved, then the grid inherits the changes automatically.
Separate solutions are more work to maintain.
---
The OCX is not small anyway.
I personally don't care about the file size, but it is important nowadays as well.
We can always use and strip the EXE version to optimize the overall file size.
---
A new Grid control is definitely a very good thing.
I use the MSFLEXGRID for too many years now.
It lacks some very basic functionality, but it is 'easy' to implement it (edit, sorting etc.).
But the appearance is fixed: Scrollbars, fixed columns...
Eager to play with the new control!
Karl
-
Re: CommonControls (Replacement of the MS common controls)
Edit: The size of the VBCCR 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.
Whether it is a separated OCX or integrated into a single file, it isn't a big problem. The most exciting thing is that Krool's new VBFlexGrid is almost completed. :)
-
Re: CommonControls (Replacement of the MS common controls)
I'm quite curious to see what the VBFlexGrid has to offer.
For years I'm using the vsFlexGrid from ComponentOne and I really really like it.
-
Re: CommonControls (Replacement of the MS common controls)
You are great, all this AND a Grid, A1.
I vote for a single file, for the reasons you have suggested
thank you so much
-
Re: CommonControls (Replacement of the MS common controls)
Hi Krool, from my point of view having a single OCX to manage in development and deployment is preferable. And I agree, an extra 1 MB plus or minus is not important.
Since it seems that managing the code is also easier from your side of things, and you do all this work graciously than that is also something to be optimized for!
Dave
-
Re: CommonControls (Replacement of the MS common controls)
I would expect the VBGrid to ultimately be a seperate OCX.
1 Question - how API compatible with the flexgrid will it be?
Also - just like to point out you've single handedly:
- Replaced all VB's Common Controls with updated Unicode Compatible replacements
- Made Multithreading easy in VB
- Will have replaced the flexgrid (arguably the most used control beyond the common controls)
All open source... Quite epic as far as classic VB goes.
Cheers!
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
DEXWERX
I would expect the VBGrid to ultimately be a seperate OCX.
1 Question - how API compatible with the flexgrid will it be?
I tend to the separate solution again. (again :) )
Since updates are isolated. Own thread for community etc.
What you mean API compatible?
Like an old fashioned dll control?
The control itself is an own registered window. But the interface is all tru the UserControl container properties and method. There will be no separate message based 'interaction'.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I tend to the separate solution again. (again :) )
Since updates are isolated. Own thread for community etc.
What you mean API compatible?
Like an old fashioned dll control?
The control itself is an own registered window. But the interface is all tru the UserControl container properties and method. There will be no separate message based 'interaction'.
I just meant, are your VBGrid's properties and methods going to be the same as an MSHFlexGrid?
Regards,
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
DEXWERX
I just meant, are your VBGrid's properties and methods going to be the same as an MSHFlexGrid?
Regards,
Yes, of course. It will be an replacement where not much code needs to be changed. Of course limitation and bugfixes will be removed and new features added.
-
Re: CommonControls (Replacement of the MS common controls)
Krool,
before your gift comes out, could you please look again at #1382?
Thank you.
Karl
-
Re: CommonControls (Replacement of the MS common controls)
I think I've found an incompatibility to the old intrinsic Controls (whilst updating an older Project at work, which had
quite some amount of Forms - by just replacing "Begin VB.TextBox " with "Begin VBCCR14.TextBoxW " same for CommandButtons -
... all done in a Replace-loop over all *.frm Files, just to lift-up the old TextBoxes and CommandButtons to Unicode-awareness)
That worked well enough - the Project loaded just fine after that.
The only problem (currently) seems to be, that Validate-Events are not raised, when a Mouse-triggered Focus-Change happens
from any Control - to another CCR14-Control... (on the "any Control" that is)...
Mouse-triggered FocusChanges to older Intrinsic-Controls work fine though and *do* trigger the Validate-Event in a CCR14-Control,
which is about to loose the Focus.
TabKey-based Focus-Changes work fine (as in: "they always trigger the Validate-Events on CCR14-Controls")
Also Form.ValidateControls seems to work the same way as with the Intrinsics (triggering a response in the currently focused CCR14-Control).
It's (as said) only the problem with MouseBased-FocusChanges.
Here's an example (please place the appropriate CCR14-Controls like listed in the snippet below on an otherwise empty Form)
Code:
Option Explicit
Private Sub TextBoxW1_Validate(Cancel As Boolean)
Debug.Print "TextBoxW1_Validate"
End Sub
Private Sub TextBoxW2_Validate(Cancel As Boolean)
Cancel = True
Debug.Print "TextBoxW2_Validate (Cancel set to True)"
End Sub
Private Sub ComboBoxW1_Validate(Cancel As Boolean)
Debug.Print "ComboBoxW1_Validate"
End Sub
Private Sub CommandButtonW1_Click()
Unload Me 'we should not reach this, when the Focus was sitting within TextBoxW2
End Sub
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
On Error GoTo 1
Me.ValidateControls 'this seems to work correcly (same as with intrinsics)
1 If Err.Number = 380 Then Cancel = 1
End Sub
Olaf
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Schmidt
I think I've found an incompatibility to the old intrinsic Controls (whilst updating an older Project at work, which had
quite some amount of Forms - by just replacing "Begin VB.TextBox " with "Begin VBCCR14.TextBoxW " same for CommandButtons -
... all done in a Replace-loop over all *.frm Files, just to lift-up the old TextBoxes and CommandButtons to Unicode-awareness)
That worked well enough - the Project loaded just fine after that.
The only problem (currently) seems to be, that Validate-Events are not raised, when a Mouse-triggered Focus-Change happens
from any Control -
to another CCR14-Control... (on the "
any Control" that is)...
Mouse-triggered FocusChanges
to older Intrinsic-Controls work fine though and *do* trigger the Validate-Event in a CCR14-Control,
which is about to loose the Focus.
TabKey-based Focus-Changes work fine (as in: "they always trigger the Validate-Events on CCR14-Controls")
Also Form.ValidateControls seems to work the same way as with the Intrinsics (triggering a response in the currently focused CCR14-Control).
It's (as said) only the problem with MouseBased-FocusChanges.
Here's an example (please place the appropriate CCR14-Controls like listed in the snippet below on an otherwise empty Form)
Code:
Option Explicit
Private Sub TextBoxW1_Validate(Cancel As Boolean)
Debug.Print "TextBoxW1_Validate"
End Sub
Private Sub TextBoxW2_Validate(Cancel As Boolean)
Cancel = True
Debug.Print "TextBoxW2_Validate (Cancel set to True)"
End Sub
Private Sub ComboBoxW1_Validate(Cancel As Boolean)
Debug.Print "ComboBoxW1_Validate"
End Sub
Private Sub CommandButtonW1_Click()
Unload Me 'we should not reach this, when the Focus was sitting within TextBoxW2
End Sub
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
On Error GoTo 1
Me.ValidateControls 'this seems to work correcly (same as with intrinsics)
1 If Err.Number = 380 Then Cancel = 1
End Sub
Olaf
Thank you.
I could replicate this problem, but only in the OCX version.
The Std-EXE version works fine.
The problem lies in the WM_MOUSEACTIVATE handlers in the controls.
It seems the OCX has a problem with:
Code:
Screen.ActiveForm.ValidateControls
I suppose replacing it with
Code:
UserControl.Parent.ValidateControls
could probably fix this issue. (But that fix would not work when mouseactivating from a form control to a nested control in another UserControl)
I will investigate soon further.
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
It seems the OCX has a problem with:
Code:
Screen.ActiveForm.ValidateControls
Yes, because Screen.ActiveForm returns a reference to the active form (when there is any) of the current project, the OCX, not of the client project.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I could replicate this problem, but only in the OCX version...
Yep, that's what we're using here...
Before you might undertake a recompilation, there's another thing with
TextBoxes that we made use of in our old Forms - it's the DataChanged-Property,
which (in case of the TextBoxW-replacements) never seems to be set (when content
is changed that is different from the "initial Form-Designer-Value").
We also have detected a Bug in the TreeView, which on Node-Deletes (which contain Children)
does not seem to delete the Children, not updating the "Count" properly - and then later
(whilst collapsing/re-expanding Nodes) will run into an error.
In case you cannot reproduce that Tree-behaviour easily, I'd be happy to provide an example...
(a collegue of mine discovered that, and we don't have a "reduced test-case" prepared yet).
Regards,
Olaf
-
Re: CommonControls (Replacement of the MS common controls)
a github would be convenient for bug tracking, version control and for others to supply patches. *nudge*
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
DEXWERX
a github would be convenient for bug tracking, version control and for others to supply patches. *nudge*
Yep.
@Krool
Just coming in from my colleague again... (sorry for just throwing that stuff out "as it happens", but maybe it's easy to fix along with the other things)
- the "DataChanged-Prop-not-set"-thingy seems not only restricted to TextBoxW, but also to CheckBoxW and OptionButtonW
- the FrameW does not contain a "HelpContextID"-Property (as the VB-original)
The latter one would probably break compatibility with the OCX-TypeLib (or the Manifest) -
but it'd be nice to have in the long run.
As said, this all came up in our "simple replace-test" we undertook (just replacing the ProgIDs in the VB *.frm Files)
on a larger (older) VB6-App - it's surprising how well that worked out, aside from these small "glitches" I've reported
(which came up when running some of the "upgraded" Forms in question).
Regards,
Olaf
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Eduardo-
Yes, because Screen.ActiveForm returns a reference to the active form (when there is any) of the current project, the OCX, not of the client project.
Yes. Thus I need to abandon the Screen.ActiveForm.
I have found a way to solve a nested UserControl in another UserControl, however this solution goes only one deep. So nesting 2x times would not work. But for now this would be a good hotfix and solves nearly all scenarios. Again, only if somebody is nesting like crazy it won't work. :-)
Code:
If TypeOf UserControl.Parent is VB.Form Then
UserControl.Parent.ValidateControls
Else
UserControl.ParentControls(0).Parent.ValidateControls
End If
So I think I will implement that solution soon for the moment until something better comes up.
-
Re: CommonControls (Replacement of the MS common controls)
courtesy of Vlad (wqweto)
takes advantage of the fact that UserControls all derive from the UserControl interface, even though they don't respond to a
QI for _UserControl. It seems that VB nicely skips the QI when it thinks it's assigning between the same interfaces.
I would have come up with this eventually. :)
Of course the assumption is that if the parent is not a Form, its a UserControl...
This may not work if it's not hosted on a Form!
Code:
Private Property Get ParentForm() As Form
Dim oTopParent As Object
Dim oUserControl As UserControl
Set oTopParent = Extender.Parent
Set oUserControl = AsUserControl(oTopParent)
Do While Not oUserControl Is Nothing
If oUserControl.Parent Is Nothing Then
Exit Do
End If
Set oTopParent = oUserControl.Parent
Set oUserControl = AsUserControl(oTopParent)
Loop
Set ParentForm = oTopParent
End Property
Private Function AsUserControl(oObj As Object) As UserControl
Dim pControl As UserControl
If TypeOf oObj Is Form Then
'--- do nothing
Else
Call CopyMemory(pControl, ObjPtr(oObj), 4)
Set AsUserControl = pControl
Call CopyMemory(pControl, 0&, 4)
End If
End Function
This doesn't seem to fix if a ComboboxW gets the focus?
although my patch was a bit hurried.
-
Re: CommonControls (Replacement of the MS common controls)
Update released. Thanks DexWerx for the code to get the parent form of the UserControl, regardless of how deep it is nested.
I have found the bug with the CausesValidation not working on mouse activation quite urgent. (though it concerns effectively only the OCX, however)
The OCX version is therefore also updated.
In the Common.bas module the following new function is included:
Code:
Public Function GetUserControlParentForm(ByVal Parent As Object) As VB.Form
If Parent Is Nothing Then Exit Function
If TypeOf Parent Is VB.Form Then
Set GetUserControlParentForm = Parent
Else
On Error Resume Next
Dim UserControl As VB.UserControl, TempObj As VB.UserControl
CopyMemory TempObj, ObjPtr(Parent), 4
Set UserControl = TempObj
CopyMemory TempObj, 0&, 4
Do While Not UserControl Is Nothing
If TypeOf UserControl.Parent Is VB.Form Then
Set GetUserControlParentForm = UserControl.Parent
Exit Do
Else
CopyMemory TempObj, ObjPtr(UserControl.Parent), 4
Set UserControl = TempObj
CopyMemory TempObj, 0&, 4
End If
Loop
On Error GoTo 0
End If
End Function
Of course the GetUserControlParentForm function will return Nothing in case the UserControl is sited on:
- Internet Explorer
- Excel, Word etc. (VBA)
- VB.PropertyPage
But when GetUserControlParentForm is used with an error handler then they should be no harm actually.
In this case then .ValidateControls will not be invoked.
However, it would be good to make this work also with VB.PropertyPage as .ValidateControls is supported on it.
But I was not able to get it done...
If somebody finds a way please let me know. :)
I will then extend the function and might rename it from 'GetUserControlParentForm' As VB.Form to 'GetUserControlTopParent' As Object.
In the meantime it then stays like this.
Quote:
Originally Posted by
DEXWERX
This doesn't seem to fix if a ComboboxW gets the focus?
It does fix the ComboBoxW as well.
PS:
I do not forget the other open issues, which are: :bigyello:
- TextBoxW CCBorderStyleSingle border draw problem on certain conditions.
- "DataChanged-Prop-not-set" on TextBoxW, CheckBoxW and OptionButtonW
- FrameW does not contain a "HelpContextID"-Property
- Bug in the TreeView, which on Node-Deletes (which contain Children) does not seem to delete the Children, not updating the "Count" properly
-
Re: CommonControls (Replacement of the MS common controls)
EDIT:
I found a solution to get the VB.PropertyPage. But that cannot be wrapped in a single function as a 'GetUserControlTopParent' As Object does not work. It must be set explicitly to VB.PropertyPage.
So the function 'GetUserControlParentForm' will stay as currently is, instead the code in the UserControl itself will be enhanced.
So the solution would be as following: (will be implemented soon)
Code:
On Error Resume Next
With UserControl
If .Extender.CausesValidation = True Then
InProc = True
GetUserControlParentForm(.Parent).ValidateControls
If Err.Number = 91 Then
Err.Clear
Dim PropertyPage As VB.PropertyPage, TempObj As VB.PropertyPage
CopyMemory TempObj, ObjPtr(.Parent), 4
Set PropertyPage = TempObj
CopyMemory TempObj, 0&, 4
PropertyPage.ValidateControls
End If
InProc = False
If Err.Number = 380 Then
WindowProcControl = MA_NOACTIVATEANDEAT
' ...
EDIT2:
if a UserControl is nested in another UserControl and sited on a VB.PropertyPage. In that case it don't work.
Thus beside 'GetUserControlParentForm' an additional function 'GetUserControlParentPropertyPage' is needed that walks up the UserControl chain first.
Luckily there is no chain on VB.PropertyPage. :)
Final solution will come soon.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
I have renamed 'GetUserControlParentForm' to 'GetUserControlTopParent'.
This is now the final solution to retrieve the top parent VB.Form of a UserControl:
Code:
Public Function GetUserControlTopParent(ByVal ParentControls As VBRUN.ParentControls) As VB.Form
If ParentControls.Count = 0 Then Exit Function
If TypeOf ParentControls(0) Is VB.Form Then
Set GetUserControlTopParent = ParentControls(0)
Else
Dim OldParentControlsType As VBRUN.ParentControlsType
OldParentControlsType = ParentControls.ParentControlsType
ParentControls.ParentControlsType = vbExtender
If TypeOf ParentControls(0) Is VB.VBControlExtender Then
ParentControls.ParentControlsType = vbNoExtender
Dim UserControl As VB.UserControl, TempUserControl As VB.UserControl
CopyMemory TempUserControl, ObjPtr(ParentControls(0)), 4
Set UserControl = TempUserControl
CopyMemory TempUserControl, 0&, 4
Dim TempParentControlsType As VBRUN.ParentControlsType
Do
With UserControl
If .ParentControls.Count = 0 Then Exit Do
If TypeOf .ParentControls(0) Is VB.Form Then
Set GetUserControlTopParent = .ParentControls(0)
Exit Do
Else
TempParentControlsType = .ParentControls.ParentControlsType
.ParentControls.ParentControlsType = vbExtender
If TypeOf .ParentControls(0) Is VB.VBControlExtender Then
.ParentControls.ParentControlsType = vbNoExtender
CopyMemory TempUserControl, ObjPtr(.ParentControls(0)), 4
Set UserControl = TempUserControl
CopyMemory TempUserControl, 0&, 4
.ParentControls.ParentControlsType = TempParentControlsType
Else
.ParentControls.ParentControlsType = TempParentControlsType
Exit Do
End If
End If
End With
Loop
End If
ParentControls.ParentControlsType = OldParentControlsType
End If
End Function
It is now safe in every scenario.
Because, before if the parent was not a VB.Form it was "assumed" to be a UserControl.
And this resulted in a crash when the Control is sited on a non-VB6 environment, e.g. VBA, IE etc. (tested)
Now trough the ParentControls it is possible to test if the Parent supports VB.VBControlExtender.
Because every UserControl implements this, thus instead of "assuming", we now know for sure it is a UserControl. (Thus CopyMemory is safe)
This check is repeated in the iteration for safety, because if the top parent is a VB.PropertyPage, it would cast the PropertyPage as UserControl...
So if it goes up the UserControl chain and detects the top parent is not a VB.Form and there is no further UserControl it will exit and return Nothing. (e.g. in case the top parent would be a VB.PropertyPage)
However, unfortunately there is no way to check if the top parent is a VB.PropertyPage or not. (if not a VB.Form of course)
So, they will be no support for VB.PropertyPage. (of course only for .ValidateControls)
An workaround would be to replace TextBoxW again to TextBox in every PropertyPage in the OCX version. (like it is in the Std-EXE version)
Of course if somebody would use the OCX in their PropertyPage the problem for mouse activation and validation would be there again...
-
Re: CommonControls (Replacement of the MS common controls)
@Krool: There is no need to manually call `ValidateControl` when UC's in-place activation is implemented correctly IMHO. The internet floating IPAO implementation (based on `OLE Guid and interface definition` typelib) has this bug you are experiencing that I've been researching in the past. On my controls (hosting API created hwnds) I'm currently using something like this for API ctl WM_SETFOCUS handler (see pvSetFocus)
Code:
Private Type RECT
Left As Long
Top As Long
Right As Long
Bottom As Long
End Type
Private Type IPAOHookStruct 'IOleInPlaceActiveObjectHook
lpVTable As Long 'VTable pointer
IPAOReal As IOleInPlaceActiveObject 'Un-AddRefed pointer for forwarding calls
TBEx As ITranslateAccelerator 'Un-AddRefed native class pointer for making Friend calls
ThisPointer As Long
End Type
Private m_IPAOHookStruct As IPAOHookStruct
Private m_bMouseActivate As Boolean
Private Sub pvSetFocus()
Dim pOleObject As IOleObject
Dim pOleInPlaceSite As IOleInPlaceSite
Dim pOleInPlaceFrame As IOleInPlaceFrame
Dim pOleInPlaceUIWindow As IOleInPlaceUIWindow
Dim PosRect As RECT
Dim ClipRect As RECT
Dim FrameInfo As OLEINPLACEFRAMEINFO
On Error Resume Next
Set pOleObject = Me
Set pOleInPlaceSite = pOleObject.GetClientSite
If Not pOleInPlaceSite Is Nothing Then
pOleInPlaceSite.GetWindowContext pOleInPlaceFrame, pOleInPlaceUIWindow, VarPtr(PosRect), VarPtr(ClipRect), VarPtr(FrameInfo)
'Get in-place frame and make sure it is set to our in-between
'implementation of IOleInPlaceActiveObject in order to catch
'TranslateAccelerator calls
If m_IPAOHookStruct.ThisPointer <> 0 Then
If Not pOleInPlaceFrame Is Nothing Then
pOleInPlaceFrame.SetActiveObject m_IPAOHookStruct.ThisPointer, vbNullString
End If
If m_bMouseActivate Then
pOleObject.DoVerb OLEIVERB_UIACTIVATE, 0, pOleInPlaceSite, 0, UserControl.hWnd, VarPtr(PosRect)
End If
End If
End If
End Sub
The difference w/ your current impl (besides `ThisPointer` holding naked pointer As Long and correspondingly tweaked typelib) as far as I can see is that on `m_bMouseActivate` flag I'm calling `DoVerb OLEIVERB_UIACTIVATE` at which point control validation takes place (must be). I'm certainly not calling `ValidateControls` on top container manually and just confirmed that `Validate` is raised on source control both on keyb and mouse activation of such IPAO impl in UC.
cheers,
</wqw>
-
Re: CommonControls (Replacement of the MS common controls)
@wqweto awesome. Thanks for clearing that up.
It's great to have people with so much experience with user controls helping out.
-
Re: CommonControls (Replacement of the MS common controls)
Thanks wqweto.
Unfortunately does 'DoVerb OLEIVERB_UIACTIVATE' not solve the problem. It is actually only a SetFocus command to the UserControl.
That 'DoVerb OLEIVERB_UIACTIVATE' does actually the same as in my WM_SETFOCUS handler:
Code:
Case WM_SETFOCUS
If wParam <> UserControl.hWnd Then SetFocusAPI UserControl.hWnd: Exit Function
If I do remove the WM_MOUSEACTIVATE handler, then the validation is working the "native good way".
However, in order to have full functionaly I need to handle WM_MOUSEACTIVATE. (reason why see example below)
Just do the following test in the CheckBoxW control:
Remove the WM_MOUSEACTIVATE handler. Now when you click on it the check is not set, only when you click again.
Only when I remove the 'DoVerb OLEIVERB_UIACTIVATE' (or SetFocusAPI UserControl.hWnd) in the WM_SETFOCUS handler the check is set on the first click.
But then you have the issue of wrong TabIndex, ActiveControl not new one etc.
So my conclusion is now that I keep the infrastructure as it is.
Maybe at some point I manage to get the VB.PropertyPage to work. (manual .ValidateControls in WM_MOUSEACTIVATE)
-
Re: CommonControls (Replacement of the MS common controls)
Update released. (quite important when using the TreeView control)
Now the child node objects of a TreeView are removed when removing a parent node object.
Thus the 'Nodes.Count' property returns the correct number after a parent node removal.
Furthermore there was a minor error in the ListView control related to the filter edit. (UseColumnFilterBar = True)
When the user clicks in a filter the whole text will be selected.
If the user now clicks again at a specific character the caret will be positioned to that character. (this was not working before)
And some other minor internal improvements.
Quote:
Originally Posted by
Schmidt
We also have detected a Bug in the TreeView, which on Node-Deletes (which contain Children)
does not seem to delete the Children, not updating the "Count" properly - and then later
(whilst collapsing/re-expanding Nodes) will run into an error.
The "Count" problem is now solved. It should also fix the "then later" problem. However, please check.
Quote:
Originally Posted by
Schmidt
FrameW does not contain a "HelpContextID"-Property (as the VB-original)
The problem is that the HelpContextID property is only available when the UserControl has the 'CanGetFocus' property to True.
In case of the FrameW control this is not wanted. The Frame shouldn't be allowed to get focus.
That's why I do not have a solution for this problem..
Quote:
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:
Attachment 147067
I now could replicate the problem. (according to chosk's example)
However, the normal VB.TextBox control does also have the same "glitch" in that scenario.
So I am afraid that this is a MS bug. (?)
Quote:
Originally Posted by
Schmidt
there's another thing with TextBoxes that we made use of in our old Forms - it's the DataChanged-Property,
which (in case of the TextBoxW-replacements) never seems to be set (when content
is changed that is different from the "initial Form-Designer-Value").
I did a quick test with the VB.Data control and an access DB.
When the record is loaded into the TextBoxW control the DataChanged property returns False. If I now change the text it returns True.
So in my understanding it does work. (?)
Edit: You can also try to use the TextBoxW.Modified property. (of course you need to set it to False manually after you load the data - as initial value)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
The "Count" problem is now solved. It should also fix the "then later" problem. However, please check.
I've checked, but it doesn't seem to work "fully" yet (tested with a larger Tree in one of our Forms -
will try to post a reduced example for that...).
Currently it looks, as if only the "first-level-children" will be removed - but not in a fully recursive manner -
as said, will try to post more details on that later...
Quote:
Originally Posted by
Krool
The problem is that the HelpContextID property is only available when the UserControl has the 'CanGetFocus' property to True.
In case of the FrameW control this is not wanted. The Frame shouldn't be allowed to get focus.
That's why I do not have a solution for this problem..
In that case, a "manually applied" (explicitely coded) HelpContextID-Property might help (altough probably
breaking the BinComp or the SxS-manifest then - but for the next version it might worth a try)...
Then managing the F1-KeyPress yourself inside FrameW (when it got "EnterFocus"-state) - and then
delegating to the usual "Show-Help"-API-Call manually as well.
Quote:
Originally Posted by
Krool
I did a quick test with the VB.Data control and an access DB.
When the record is loaded into the TextBoxW control the DataChanged property returns False. If I now change the text it returns True.
So in my understanding it does work. (?)
Edit: You can also try to use the TextBoxW.Modified property. (of course you need to set it to False manually after you load the data - as initial value)
The DataChanged-Prop seems related to DataBinding, but this is only *one* case where it applies -
because it works (and is used by us) also without any DataBindings in some Forms...
The behaviour is (quite similar to your .Modified-Prop), that the "initial FormDesigner-Value" of a Control
will not cause the DataChange-Prop to go to True (when the Form is loading) - so far so good...
However, *any* change of a Controls-Content that follows (be it "programmatically" or "by User-Input"),
will set (in the VB.TextBox) the DataChanged-Prop to True - though one can "reset" it to False again after e.g.
a "programmatical change" which was a "desired one" (e.g. when filled from a DB on Form-Load).
The following Example shows the differences we stumbled over (all without any DataBinding)
The Form needs:
- a Timer1
- a Text1 and a Label1 from VBs intrinsics
- a TextBoxW1 and a LabelW1 from the CCR14-OCX
Code:
Private Sub Form_Load()
Timer1.Interval = 100
Text1.Text = "Initial-Value": Debug.Print "Text1: "; Text1.DataChanged
TextBoxW1.Text = "Initial-Value": Debug.Print "TextBoxW1: "; TextBoxW1.DataChanged
'after setting the .Text-Prop programmatically, we reset the Flag (to be able to see new changes)
Text1.DataChanged = False
TextBoxW1.DataChanged = False
End Sub
Private Sub Timer1_Timer()
Label1.Caption = Text1.DataChanged
LabelW1.Caption = TextBoxW1.DataChanged
End Sub
From your description it sounds as if your TextBoxW.Modified Property shows the desired behaviour
(working the same way as the .DataChanged-Prop in the old TextBox) - but since we currently "just replace the ProgID"
in a loop over all our *.frm Files, it would be nice when the two (.Modified and .DataChanged) would be "synchronized".
Thanks for working on fixing these things with such a short response-time BTW...
Olaf
-
Re: CommonControls (Replacement of the MS common controls)
Ok, here the promised example for the Tree-Node-Remove-Problem (I'm already using the recent CCR14 version) -
accompanied by another issue with AutoSized-LabelWs which "freshly came in" from my colleagues:
The Form needs 3 freshly dropped Controls, all in their "virginal, unchanged state":
VB.Label1, VBCCR14.LabelW1, and a VBCCR14.TreeView1
Code:
Private Sub Form_Load()
With TreeView1
.Nodes.Add , , "Node_0", "Node_0"
.Nodes.Add "Node_0", TvwNodeRelationshipChild, "Node_0_0", "Node_0_0"
.Nodes.Add "Node_0_0", TvwNodeRelationshipChild, "Node_0_0_0", "Node_0_0_0"
.Nodes.Add "Node_0_0", TvwNodeRelationshipChild, "Node_0_0_1", "Node_0_0_1"
.Nodes.Add "Node_0", TvwNodeRelationshipChild, "Node_0_1", "Node_0_1"
.Nodes.Add "Node_0_1", TvwNodeRelationshipChild, "Node_0_1_0", "Node_0_1_0"
.Nodes.Add "Node_0_1", TvwNodeRelationshipChild, "Node_0_1_1", "Node_0_1_1"
Debug.Print "NodeCount should be 7:"; .Nodes.Count
.Nodes.Remove "Node_0" '<- now we remove the Root-node
Debug.Print "NodeCount should be 0:"; .Nodes.Count
End With
With Label1
Debug.Print .Name; ".Width, initial AutoSize False: "; .Width
.Font.Name = "Arial"
.Font.Size = 10
.Caption = "Some Text"
.AutoSize = True
Debug.Print .Name; ".Width, after AutoSize True: "; .Width
.Caption = "Some more Text"
Debug.Print .Name; ".Width, after Caption-Change: "; .Width
End With
With LabelW1
.WordWrap = False '<- just to match with the VB.Label Default
Debug.Print .Name; ".Width, initial AutoSize False: "; .Width
.Font.Name = "Arial"
.Font.Size = 10
.Caption = "Some Text"
.AutoSize = True
Debug.Print .Name; ".Width, after AutoSize True: "; .Width
.Caption = "Some more Text"
Debug.Print .Name; ".Width, after Caption-Change: "; .Width
End With
End Sub
HTH
Olaf
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Quote:
Originally Posted by
Schmidt
I've checked, but it doesn't seem to work "fully" yet (tested with a larger Tree in one of our Forms -
will try to post a reduced example for that...).
Currently it looks, as if only the "first-level-children" will be removed - but not in a fully recursive manner
Oh yes, of course a recursion needs to be done to get all children on each level.
This should be now fixed, please check again.
Quote:
Originally Posted by
Schmidt
another issue with AutoSized-LabelWs which "freshly came in" from my colleagues:
This kind of issue we had "already" and was solved.
However, when doing this in Form_Load it seems to not work. (else when Form is displayed this does already work)
Your other points are noted and will be checked soon.
Thanks Olaf for your reports anyhow, such a project 1:1 replacement conversion is always a good "trial of fire" test. :)
-
Re: CommonControls (Replacement of the MS common controls)
I have detected a major important bug that needs to be fixed!
Right ahead: I do have a solution in mind for this, later more.
1. Start a fresh Std-EXE project
2. Load VBCCR14.OCX components (or Std-EXE CommonControls, doesn't matter)
3. Put first a TextBoxW1 and then a CommandButtonW1 on Form1.
4. Add new Form (as Form2)
5. Put a TextBoxW1 and a TextBoxW2 on Form2.
6. put following code in Form1:
Code:
Private Sub CommandButtonW1_Click()
Form2.Show vbModal
End Sub
Private Sub Form_Load()
CommandButtonW1.Default = True
End Sub
7. Run project -> when on TextBoxW1 press Return key -> Form2 will be shown modally -> now press right arrow key
The IOleInPlaceActiveObject seems to stuck on Form1 when Form2 is shown modally, thus the accelerator keys are not trapped in Form2 on the TextBoxW controls, resulting that instead of moving the caret on right arrow key the other TextBoxW2 is focused instead.
The solution in mind is when ActivateIPAO is called on a new Form then re-subclass the VTable for IOleInPlaceActiveObject with a new ObjectPointer from Form2, this way it is not "stuck" on Form1.
However, that solution is still in process and I need some time to find an optimal way. However, I do already want to make this bug public.
What I do also find interesting is when "clicking" (by mouse) CommandButtonW1 the issue is not happening.
Only when invoking by return key (via Default) the problem seems to appear. (I have a clue, but not sure..)
Did somebody else already encountered this bug? Or is this new?
Can everybody reproduce it?
EDIT: On modeless Form2 this bug is of course not happening
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Quote:
Originally Posted by
Krool
However, unfortunately there is no way to check if the top parent is a VB.PropertyPage or not. (if not a VB.Form of course)
So, they will be no support for VB.PropertyPage. (of course only for .ValidateControls)
Now VB.PropertyPage is supported for .ValidateControls (CausesValidation; mouse activation) when a Control is sited on such a VB.PropertyPage.
There was indeed no VB native way to check if the top parent is a VB.PropertyPage or not. (TypeOf)
However, with a manual IUnknown.QueryInterface for IPropertyPage it is possible to check for it.
The 'GetUserControlTopParent' in Common.bas is removed and replaced by a generic 'GetTopUserControl' function.
That generic GetTopUserControl function will return the current UserControl if there is no "upper" UserControl, else it will walk the chain up to the final UserControl.
It is intended that such a generic function is placed in Common.bas as it can be used for many other purposes.
Included 'VTableInterfaceSupported' function in VTableHandle.bas. This is a generic function that will do a IUnknown.QueryInterface on a given IID (as String) and returns a Boolean if it is supported or not.
Included 'ComCtlsTopParentValidateControls' function in ComCtlsBase.bas. This is a specific wrapper function that will do following:
Code:
Public Sub ComCtlsTopParentValidateControls(ByVal UserControl As Object)
With GetTopUserControl(UserControl)
If TypeOf .Parent Is VB.Form Then
Dim Form As VB.Form
Set Form = .Parent
Form.ValidateControls
Else
Const IID_IPropertyPage As String = "{B196B28D-BAB4-101A-B69C-00AA00341D07}"
If VTableInterfaceSupported(.Parent, IID_IPropertyPage) = True Then
Dim PropertyPage As VB.PropertyPage, TempPropertyPage As VB.PropertyPage
CopyMemory TempPropertyPage, ObjPtr(.Parent), 4
Set PropertyPage = TempPropertyPage
CopyMemory TempPropertyPage, 0&, 4
PropertyPage.ValidateControls
End If
End If
End With
End Sub
So in each control it is just enough to make a 'Call ComCtlsTopParentValidateControls(Me)' and test for error code 380.
-
Re: CommonControls (Replacement of the MS common controls)
This set of controls would be 100% complete for me if it could have:
> TreeView with columns (would need extending with columns and subitems for each node) - currently I use this but there are a few issues and keeping just one set of controls up to date and in the same place makes like easier
> COM control (never expect this to happen, but I don't get on with MSCOMM and I hate dragging the ocx around)
and then I would never need anything else :D
Keep up the amazing work!
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Sam_
This set of controls would be 100% complete for me if it could have:
> TreeView with columns (would need extending with columns and subitems for each node) - currently I use
this but there are a few issues and keeping just one set of controls up to date and in the same place makes like easier
> COM control (never expect this to happen, but I don't get on with MSCOMM and I hate dragging the ocx around)
and then I would never need anything else :D
Keep up the amazing work!
I don't know what "COM control" means. Krool has released the pre-compiled VBCCR14.OCX:
http://www.vbforums.com/showthread.p...55#post5129155
-
Re: CommonControls (Replacement of the MS common controls)
Sam_ is referring to an alternative of the MSCOMM component which is used for accessing (serial) COM ports.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Issue described on post #1431 is now solved.
The OCX is also updated, except the change concerning the default value of the WordWrap property for the LabelW control.
This will be respected only in a future OCX release.
-
Re: CommonControls (Replacement of the MS common controls)
Can listview set the height of each item?
-
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
Please refer to my message #1363 and your reply message #1364 (related to the RichTextBox control).
With respect to the solution you provided to fix one error at it's root cause, what happens now is that whenever my RichTextBox control (say, rtb1) becomes empty (i.e. having no text), the following error occurs:
"Subscript out of range"
The above-mentioned error occurs at the following line:
Code:
ReDim StreamStringIn(0 To StreamStringInLength - 1) As Byte
This is because 'StreamStringInLength' is 0.
So, at my end, I am keeping your old lines of code itself (i.e. without adding '-1') and hence I am still resorting to use my following line of code:
Code:
Value = Left$(Value, Len(Value))
I, in fact, have one more line of code before the above line to tackle the issues related to VbCrLf. It is as follows:
Code:
Value = Replace(RtfStreamStringOut(), vbCrLf, vbCr)
So far, everything has been working smoothly at my end with my above two lines of code. But, I would love to hear from you as to whether there is any other solution to fix the error at it's root cause.
Best of all wishes to you, ever, for your wonderful work!
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
softv
Please refer to my message #1363 and your reply message #1364 (related to the RichTextBox control).
With respect to the solution you provided to fix one error at it's root cause, what happens now is that whenever my RichTextBox control (say, rtb1) becomes empty (i.e. having no text), the following error occurs:
"Subscript out of range"
Oops. Thank you.
Update released.
Fix was following change in RichTextBoxBase.bas:
Code:
Public Sub RtfStreamStringIn(ByVal Value As String)
StreamStringInLength = LenB(Value)
Erase StreamStringIn()
If StreamStringInLength > 0 Then
ReDim StreamStringIn(0 To (StreamStringInLength - 1)) As Byte
CopyMemory StreamStringIn(0), ByVal StrPtr(Value), StreamStringInLength
End If
StreamStringInPos = 0
End Sub
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Schmidt
by another issue with AutoSized-LabelWs which "freshly came in" from my colleagues:
Code:
Private Sub Form_Load()
With Label1
Debug.Print .Name; ".Width, initial AutoSize False: "; .Width
.Font.Name = "Arial"
.Font.Size = 10
.Caption = "Some Text"
.AutoSize = True
Debug.Print .Name; ".Width, after AutoSize True: "; .Width
.Caption = "Some more Text"
Debug.Print .Name; ".Width, after Caption-Change: "; .Width
End With
With LabelW1
.WordWrap = False '<- just to match with the VB.Label Default
Debug.Print .Name; ".Width, initial AutoSize False: "; .Width
.Font.Name = "Arial"
.Font.Size = 10
.Caption = "Some Text"
.AutoSize = True
Debug.Print .Name; ".Width, after AutoSize True: "; .Width
.Caption = "Some more Text"
Debug.Print .Name; ".Width, after Caption-Change: "; .Width
End With
End Sub
I pointed out this issue now.
The problem is certainly that the auto sizing feature is dependent on the UserControl_Paint event, which is not being fired during Form_Load.
Only solution which come into my mind is to remove the auto size calculation in UserControl_Paint and do it in a separate routine with a memory DC.
I think that little overhead is reasonable and certainly the intrinsic Label control must be doing something similar..
So I think that problem is worth solving in the near future.