Re: CommonControls (Replacement of the MS common controls)
The Type Mismatch errors don't seem to be happening in the demo project. I should also clarify it's only an issue in the IDE. It's never given that error or crashed while running, either from VB or compiled.
If I had to guess, the 'type mismatch' is related to the fact that OLEGuids.IPerPropertyBrowsingVB and OLEGuids.IPerPropertyBrowsing are both being used- and if it's me only... I'll look for something not explicitly typed to OLEGuids but I also have olelib.IPerPropertyBrowsing that has a different set of methods. However it's not in use anywhere and everything in your project is explicitly typed as OLEGuids.IPer.. so not sure how such a conflict would arise. Why these three all have a different set of methods is bothersome...
Code:
Private Sub ReplaceIPPB(ByVal This As OLEGuids.IPerPropertyBrowsing)
If VTableSubclassPPB Is Nothing Then Set VTableSubclassPPB = New VTableSubclass
If VTableSubclassPPB.RefCount = 0 Then
VTableSubclassPPB.Subclass ObjPtr(This), VTableIndexPPBGetDisplayString, VTAbleIndexPPBGetPredefinedValue, _
AddressOf IPPB_GetDisplayString, 0, _
Private Function IPPB_GetDisplayString(ByVal This As Object, ByVal DispID As Long, ByVal lpDisplayName As Long) As Long
Dim ShadowIPerPropertyBrowsingVB As OLEGuids.IPerPropertyBrowsingVB
[..]
Set ShadowIPerPropertyBrowsingVB = This 'type mistmatch
Last edited by fafalone; Jun 3rd, 2015 at 03:13 AM.
The solution is already implemented into the controls. ("LoadLibrary("shell32.dll")", etc.)
The InitVisualStyle method is located in VisualStyles.bas.
I had this problem also once and the reason was by one specific control. Maybe you can trial and error and look if it still crashes when you remove the controls except one and so on... So you run-trough all controls and trace the source of the problem.
Re: CommonControls (Replacement of the MS common controls)
Thanks, the only time it happens for my existing project (10+ years old) was 2 days ago when we included the VBCCR11.OCX. And we only use the TreeView from this OCX, on 1 form, of over 5 dozen forms. The crash occurs at an End statement. The situation is that we must use the VBCCR11.OCX TreeView to provide access to the 100's of program we have in the QMC Program Suite. See QMC.net. Thanks so much, Paul
FYI: The new MS supplied ComCtl32/TreeView does not work any more with the functionality we and many others need (and as seen on many forums) and is not compatible with any past releases (since 1997). Right now it is only the TreeView they have changed making this a complete MS Mess. With the way they do it provides no work around. You cannot put the required ComCtl32 in the System32 or W[/B][/B]OW folders and over write the new MS ComCtl32 since it affects IE and other programs. And when the old ComCtl32 is placed in rhe APP.PATH it will not register (programs still use the new new ComCtl32). Please help...
Re: CommonControls (Replacement of the MS common controls)
Did and it works great now... What about the Node Click Event, does it exist for the TreeView with your Controls? Thanks, so much. (How can I repay you for this? You are invaluable for sure!!!)
Re: CommonControls (Replacement of the MS common controls)
What demo, all I have found are 2 versions of the OCX? I am using VBCCR11.OCX which is a zip. The only demo I have found is for a MDI ToolBar... Can you please tell me wher the TreView DEMO is? Thanks, Paul
Re: CommonControls (Replacement of the MS common controls)
But anyway, I get 4 events in my program with your Control: DragDrop, DragOver, GotFocus, and LostFocus. That's It, No Mas. Nothing of what you show... ??? Re, Paul
C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter
There's just no reason to use garbage like InputBox. - jmcilhinney
The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
I could create a event in response to TVN_DELETEITEM. However, there is no notification when a node is being added...
Oh, if you did, I just wanted to know what messages you intercepted. I have an inherited TreeView in .Net where I added events for the addition and deletion of nodes but its not perfect. There was no real direct message for these events so I had to get a bit clever but the solution has a couple nuances.
C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter
There's just no reason to use garbage like InputBox. - jmcilhinney
The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Please provide your code. Does this also happen when using the StdEXE-ListView?
No, the original control (MSComctlLib.ListView) that was replaced did not have this issue.
I've attached the event handlers and properties. I did observe that when the run-time error happens, it does not hit the trace message at the beginning of OLEStartDrag event handler. It seems like something is happening even before that. When I debug, the application crashes after this error and I get a memory reference exception.
Last edited by vb6rocks; Jun 10th, 2015 at 12:40 PM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by vb6rocks
No, the original control (MSComctlLib.ListView) that was replaced did not have this issue.
I've attached the event handlers and properties. I did observe that when the run-time error happens, it does not hit the trace message at the beginning of OLEStartDrag event handler. It seems like something is happening even before that. When I debug, the application crashes after this error and I get a memory reference exception.
In my tests the OLEStartDrag event fires w/o any run-time error.. (W2K, WinXP and Win7 tested)
By StdEXE-ListView I did not mean the MSComctlLib.ListView, rather I mean my ListView control. (non-OCX, can be found in the Demo project) Can you test if there is the same issue?
Do you also use the latest VBCCR11.OCX version? (revision number)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
In my tests the OLEStartDrag event fires w/o any run-time error.. (W2K, WinXP and Win7 tested)
By StdEXE-ListView I did not mean the MSComctlLib.ListView, rather I mean my ListView control. (non-OCX, can be found in the Demo project) Can you test if there is the same issue?
Do you also use the latest VBCCR11.OCX version? (revision number)
I've not been able to reproduce the issue in the Demo project. However, as you can see, the implementations are different in both cases. It's not clear what is causing the issue.
I was able to reproduce the run-time error on the latest version of VBCCR11.OCX (Revision 32).
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by vb6rocks
I've not been able to reproduce the issue in the Demo project. However, as you can see, the implementations are different in both cases. It's not clear what is causing the issue.
I was able to reproduce the run-time error on the latest version of VBCCR11.OCX (Revision 32).
Additionally, I was able to identify that the following line (in red) in VBCCR11 is what is causing the run-time error (Overflow):
Private Sub UserControl_OLEStartDrag(Data As DataObject, AllowedEffects As Long)
If ListViewDragIndex > 0 Then
If ListViewHandle <> 0 Then
Dim P(0 To 1) As POINTAPI, RC As RECT
GetCursorPos P(0)
ScreenToClient ListViewHandle, P(0)
SendMessage ListViewHandle, LVM_GETITEMPOSITION, ListViewDragIndex - 1, ByVal VarPtr(P(1))
SendMessage ListViewHandle, LVM_GETVIEWRECT, 0, ByVal VarPtr(RC)
ListViewDragOffsetY = (P(1).Y - P(0).Y) + RC.Top
ListViewDragOffsetX = (P(1).X - P(0).X) + RC.Left
End If
If PropOLEDragMode = vbOLEDragAutomatic Then
Dim Text As String
Text = Me.FListItemText(ListViewDragIndex, 0)
Data.SetData StrToVar(Text & vbNullChar), CF_UNICODETEXT
Data.SetData StrToVar(Text), vbCFText
AllowedEffects = vbDropEffectMove Or vbDropEffectCopy
End If
End If
RaiseEvent OLEStartDrag(Data, AllowedEffects)
If AllowedEffects = vbDropEffectNone Then ListViewDragIndex = 0
End Sub
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by vb6rocks
Additionally, I was able to identify that the following line (in red) in VBCCR11 is what is causing the run-time error (Overflow):
Private Sub UserControl_OLEStartDrag(Data As DataObject, AllowedEffects As Long)
If ListViewDragIndex > 0 Then
If ListViewHandle <> 0 Then
Dim P(0 To 1) As POINTAPI, RC As RECT
GetCursorPos P(0)
ScreenToClient ListViewHandle, P(0)
SendMessage ListViewHandle, LVM_GETITEMPOSITION, ListViewDragIndex - 1, ByVal VarPtr(P(1))
SendMessage ListViewHandle, LVM_GETVIEWRECT, 0, ByVal VarPtr(RC)
ListViewDragOffsetY = (P(1).Y - P(0).Y) + RC.Top
ListViewDragOffsetX = (P(1).X - P(0).X) + RC.Left
End If
If PropOLEDragMode = vbOLEDragAutomatic Then
Dim Text As String
Text = Me.FListItemText(ListViewDragIndex, 0)
Data.SetData StrToVar(Text & vbNullChar), CF_UNICODETEXT
Data.SetData StrToVar(Text), vbCFText
AllowedEffects = vbDropEffectMove Or vbDropEffectCopy
End If
End If
RaiseEvent OLEStartDrag(Data, AllowedEffects)
If AllowedEffects = vbDropEffectNone Then ListViewDragIndex = 0
End Sub
Another difference when compared to the demo is that in our case we are doing a drag and drop on controls that are in different forms. (The demo project has both the controls in the same form.)
We are using your library extensively for Unicode support and it has been very beneficial so far.
Update: We were able to identify the root cause of the run-time error. It was caused by one of the long variables (RC.Top/ RC.Left) getting set to it's max value (2147483647) and the addition operation caused an Overflow exception.
Last edited by vb6rocks; Jun 10th, 2015 at 12:33 PM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by vb6rocks
Additionally, I was able to identify that the following line (in red) in VBCCR11 is what is causing the run-time error (Overflow):
Private Sub UserControl_OLEStartDrag(Data As DataObject, AllowedEffects As Long)
If ListViewDragIndex > 0 Then
If ListViewHandle <> 0 Then
Dim P(0 To 1) As POINTAPI, RC As RECT
GetCursorPos P(0)
ScreenToClient ListViewHandle, P(0)
SendMessage ListViewHandle, LVM_GETITEMPOSITION, ListViewDragIndex - 1, ByVal VarPtr(P(1))
SendMessage ListViewHandle, LVM_GETVIEWRECT, 0, ByVal VarPtr(RC)
ListViewDragOffsetY = (P(1).Y - P(0).Y) + RC.Top
ListViewDragOffsetX = (P(1).X - P(0).X) + RC.Left
End If
If PropOLEDragMode = vbOLEDragAutomatic Then
Dim Text As String
Text = Me.FListItemText(ListViewDragIndex, 0)
Data.SetData StrToVar(Text & vbNullChar), CF_UNICODETEXT
Data.SetData StrToVar(Text), vbCFText
AllowedEffects = vbDropEffectMove Or vbDropEffectCopy
End If
End If
RaiseEvent OLEStartDrag(Data, AllowedEffects)
If AllowedEffects = vbDropEffectNone Then ListViewDragIndex = 0
End Sub
Is the same happening when you use the Std-Exe ListView?
If yes, what are the debug values? Maybe the var type 'Long' for ListViewDragOffsetX/Y is not sufficient..
EDIT: Ok you figured out that the RC.Top / RC.Left values (in fact LVM_GETVIEWRECT) are set to its max value and of course causing an Overflow exception. Try to declare ListViewDragOffsetX/Y as Double instead of Long. Does this solves the issue?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Is the same happening when you use the Std-Exe ListView?
If yes, what are the debug values? Maybe the var type 'Long' for ListViewDragOffsetX/Y is not sufficient..
EDIT: Ok you figured out that the RC.Top / RC.Left values (in fact LVM_GETVIEWRECT) are set to its max value and of course causing an Overflow exception. Try to declare ListViewDragOffsetX/Y as Double instead of Long. Does this solves the issue?
Yes, technically, using Double would solve the problem. In our case, we just added a check to see if RC.Top is > max value, if yes, then set ListViewDragOffsetY to max value instead of doing an addition operation. This solved the problem for us. We'll wait for you to provide a fix for your library and in the interim, we'll use this solution, thanks.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by dz32
is this in source control anywhere?
The source code for the ActiveX Controls are not public.
But the code for the Std-EXE Controls (located in the ComCtlsDemo project) are public. These are also with the latest features as the ActiveX Control project will be updated rarely. (Until now only two versions; 1.0 and 1.1)
Only bugfixes will be updated to the existing ActiveX Control versions, as this does not break binary compatibility.